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

[Ole Reinhardt]

Hi Harald,

> > - is it necessary to wait until autonegotiation is complete to do the
> >   nic reset?
> 
> It is not required to wait for a link.

So the main problems seems that the at91_emac driver tries two times to
reset the emac and to complete autonegotioation. If the link is not
established the emac_init function as well as NutRegisterDevice returns
with an error so the user can call NutRegisterDevice again.

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?

> You are right. Re-linking is done by the MAC automatically after 
> attaching the cable again.

Ok.

> > - What should correctly happen if a link loss is detected? From my
> >   understanding, this should be communicated up to the socket layer to
> >   abort the currently opened sockets and set the socket error
> >   appropriate, right?
> 
> 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?

> > - On the other hand this should perhaps influence the dhcp thread to
> >   request a new ip address after link establishment, right?
> 
> Similar to the above. At least a gratuitous ARP packet should be sent 
> and further action taken in case of duplicate address detection.

Right. In this case at least some kind of callback on a link loss /
reestablishment would be a good idea.

> > - Any further ideas / requirements?
> 
> I assume, that most problems can be solved by registering a callback. 
> Then the application can decide about further actions, like shutting 
> down the interface (in which case the socket layer _must_ be notified).

Right.

> > These functions are realy missing in NutOS, so I'd like to start a
> > discussion how to _correctly_ implement these features.
> 
> Fully agree. I started on this some time ago without any final result. 
> IMHO, the following should be done first:
> 
> 1. Implement functions for starting or shut down an interface.
> 2. Implementing an _ioctl() function in Ethernet drivers to control shut 
> down or start interface, query or set MAC address, registering a link 
> callback etc.

I agree! Startup and shutdown of an interface is realy necessary and
missing. As well a good way for reconfiguration of an interface... 

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

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?


-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |
|_____________________________________________________________|