>If you have time, please look into any of Ethernet driver.
>There you will be able to see that certain device registers
>give you an indication of TX status. I want to know if that
>status is OK or not. Nothing more.
Agreed -- all of the Ethernet controllers I've seen made that
information available. The problem is that it's extremely
difficult (with current stack/driver designs) to get that
status info back up to the application. At the point where the
Tx failure status is known, the driver typically doesn't know
to whom the failed packet belongs.
>>Since there is no difference between a frame being transmitted
>>and not received and a frame not being transmitted, then you
>The difference is the status provided by Ethernet controller on
Right, but in either case, an application has to do the same
thing. If the action taken by the app is the same for two
cases, then it can be argued that it's not required that the
appliction know which case occured, only that one of them
Quote:>>anything. ACKs could still get lost even thought he Ethernet
>>board thinks they've been transmitted. Your protocol has to
>>deal with that.
>Totally agree. It has to, but surely it does not.
That's too bad.
Quote:>Anyway I do not care about that protocol. I did not design it.
>But I just want to distinguish two situations: packet is not
>sent because cable is removed from TP socket or broken; or
>packet is sent but get lost somewhere in hubs.
That information could, in theory, be passed back up to the
application, but it's a pretty * problem. The send() or
write() syscall returns as soon as the information has been
queued for transmit. At some point later in time, the Ethernet
driver notices that a transmit failed. Now there are two
1) The ethernet driver doesn't know who requested the packet
2) If it did, there isn't a well-defined way (other than a
signal) to inform an application of an asynchronous error
Quote:>In addition it would be nice to get to know how many collisions
>had been detected before packet is sent.
If you just want to query the state of the interface, that's a
considerably easier problem. Doing a cat on /proc/dev/net
shows fields for both collisions and carrier-faults (among
I don't know if there is a more direct API to get that info,
but open() and read() on /proc/net/dev/ should get you that
Grant Edwards grante Yow! Bo Derek ruined
at my life!