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

[Harald Kipp]

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.


>> 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?

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

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.

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.

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.


> 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.

> 
> The logical consequence would be to alow multiple interfaces as well...

As for routing, I _hope_ that the current layout allows this.

> I don't have an overview about the different network drivers at all. Is
> there any effort done to implement some generic interface for all
> network drivers?

During my last evaluation I recognized, that 2 generic modules would 
make sense.

1. A general network interface, which handles general functions and 
passes hardware specific functions to the hardware driver.

2. A generic PHY module. The reason here is, that I recognized that 
Ethernet PHY are quite similar, even if integrated in the controller.

As usual, I wanted to make it right in one go and had to find out, that 
more effort is required than my spare time would allow. But that's my 
personal problem. I'd welcome "not so perfect" intermediate solutions as 
well.

Harald