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

[ennut at thezachariasgroup.com]

   Harald and Ole,

  I don't think NutRegisterDevice should always succeed.

The help reference says the return value for 
NutRegisterDevice is defined as follows:
0 if the device has been registered for the first 
time and initialization was successful. The 
function returns -1 if any device with the same 
name had been registered previously, if the 
<mk:@MSITStore:C:\ethernut-4.4.0\nutoshelp.chm::/group__xg_device.html#g6e44357e76989d8e579d3f65bc3a2741>NUTDEVICE 
structure is invalid or if the device initialization failed.
If the link is not available then the 
initialization has failed and should be reflected in the return value.

If NutRegisterDevice always succeeded, how would 
one detect if the link were down or the cable was not plugged in?

I have a separate thread for ethernet 
connectivity and currently flash an led pattern 
to indicate that ethernet connectivity was not established.
This way the application isn't waiting on 
ethernet connectivity and can continue to operate 
and log data until the link is available.
This thread flashes patterns to indicate if it 
was configured by DHCP or if a static IP Address 
was used and when internet connectivity is established.



   Zack


At 06:57 AM 9/15/2008, you wrote:
>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         |
>|_____________________________________________________________|
>
>_______________________________________________
>http://lists.egnite.de/mailman/listinfo/en-nut-discussion