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

[Ole Reinhardt]

Hi!

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

For shure this only will solve the startup case. But this one is the
most annyoing one, if the application needs several minutes to timeout
during startup if no cable is connected.

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

This is exactly what I would suppose too. And at least on my linux
workstation this case is handled the same way. If you disconnect the
cable the interface will announce all assigned sockets to disconnect.

But this _only_ happens if the first hop, (the direct cable) is
disconnected, nut if the cable of a switch / router is disconnected. And
therefore I think NutOS should behave the same way. If the cable is
disconnected on a router the socket will survice this, if it is
reconnected again.

When connecting the cable again Linux produces some kind of callback
which will inform several services like dhcp, networking file systems
etc.

So in my opinion we will need two things:

On a cable disconnection:
	- We should bring all sockets to abort state and shut down the
          interface. This is exactly what linux does...
        - Call a callback to inform the application

On a cable connection:
	- Startup the interface again
	- Resend arp packets
	- Call a callback to inform the application 

Provide an API interface to query the current link state.

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

Right.

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

No I don't think we just can unblock waiting threads with jus a
callback. I definatly see the need to handle the disconnect event on
network / socket layer.

> > 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 :)

Right. How about solving both issues for the next NutOS version?

Regards,

Ole Reinhardt

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