[En-Nut-Discussion] Network Link state on at91_emac and others

[Thiago A. Corrêa]

On Mon, Sep 15, 2008 at 1:01 PM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Ole Reinhardt wrote:
>> For me this does not make too much sense and I would like to change the
>> behavior a little bit so that NutRegisterDevice always succed, even if
>> there is no link.
>>
>> Would this be acceptable?
>
> To me it is acceptable.
>

This will only solve the initial state of the board initializing when
the cable os off. Not the case were the cable is unpluged with the
board running. IMHO the proper handling of that would be making all
sockets go to abort state, so reads and writes returns -1, which means
connection loss. It really doesn't matter to the application why, but
it's important for it to know that it has happened.

That's the behavior you see from windows applications, and I'm
guessing linux would be the same.

>>> Not really. It's an essential feature of TCP/IP to keep the connection
>>> established even during link loss. An optional "keepalive" extension can
>>> be used to detect this situation. But this is optional and not yet
>>> implemented in our stack.
>>>
>>> There are different views on this topic, because the initial intention
>>> of TCP/IP is sometimes not practicable in real world applications.
>>
>> Can you explain this a little more in detail?

PC OSes I've seen simply drop the connection the moment link loss is
detected. I suppose this is quite acceptable behavior, and that's what
most of our customers have been expected to happen.

> A simple example: If there is an established TCP connection (e.g.
> telnet) and someone pulls the cable and re-attaches the cable, then it
> is assumed, that the connection won't break and can continue without
> re-connect. See RFC1122, Chapter 4.2.3.6  TCP Keep-Alives
> http://tools.ietf.org/html/rfc1122#page-101

Probably the TCP layer sends the message and receive an imediate
transmission fail, so the 3 times count goes up imediatly.

> However, when used in security systems for example, users expect some
> kind of immediate alarm in case of a broken physical connection. In no
> case they would expect connections to continue without any notice,
> although this is the default TCP behavior.

Well, if TCP doesn't guarantee what they expect, then they are using
the wrong technology, there is no way around it. Even if it was
implemented on the nut, it would only work for the last mile of cable,
from the hub or router onwards, there are no guarantees.

> Further, most application programmers don't accept, that NutTcpReceive()
> will not return, if the Ethernet cable is pulled or the other end died.
> But that's how TCP is designed.

Yeah, one would expect an error return, as I mentioned above.

> Finally, I think that a registered callback in case of a link loss is
> the way to go. Then the application can decide whether to continue or to
> shut down the interface, which in turn will trigger DHCP, ARP, existing
> TCP connections etc. etc. In no case an Ethernet link loss should
> automatically trigger anything except this callback.

Would a callback be able to unblock threads waiting on NutTcpReceive?
I guess we would have to set sockets internally to abort state and
wake those threads, who should have their own checks for lost
connections and handle that.

>
>> I agree! Startup and shutdown of an interface is realy necessary and
>> missing. As well a good way for reconfiguration of an interface...
>
> Right. Changing the IP address, for example, requires to shut down the
> interface first.

That would be nice, and it's somewhat independent of the rest of the
discussion. One could work on that right away, regardless of what else
we must still decide IMHO :)

Kind regards,
     Thiago A. Correa