[En-Nut-Discussion] detecting an unplugged network cable

[Ulrich Prinz]

Hi!

Funny, I thought to open a new thread for some improvements on EMAC 
handling :)

> I assume this can be handled much better in that the DHCP is retriggered
> and just drop connections if - and only then - the host can't reestablish
> the former IP, because if it loose it's IP the connections technically
> can't be used anymore.

I thought about the problem a bit and have an opinion how to solve that 
all a bit more elegant but without blowing up the code to much.

>
> Ulrich is right that the PHY renegotiates the link and that the MAC
> has to be reconfigured to the new negoatian, but I don't consider this
> as a major problem unless the new link has different setup and I consider
> almost all upstream ports today to be 100M/FDX cpable.
>
But if you ask the PHY for what features have negotiated for the MAC 
setup you should ask the register of the actual established ones, not 
the possible ones :)

But to keep it simple:

I intend to add some NutEvents to the EMAC as this is something you 
might use or you might not. The EMAC has three major events:
1) EmacFailEvent
Posted at bootup, informs system about EMAC not ready to do anything.
Posted again on errors in EMAC/PHY system caused by stack errors, 
persistent disconnection and other big problems.

2) EmacConnectEvent
Posted if link is established, negotiated and ready for transmission.
Reposted if recovering from 1) or 3)

3) EmacDisconnectEvent
Posted immediately if link failed.

With this small toolset you should be able to handle IP setup on 
disconnect - reconnect conditions simply by running DHCP in a thread. It 
sleeps with timeouts on EmacConnectEvent. Timeout is needed for handling 
lease timeouts.
You may connect to EmacDisconnect Event to do fallback handling or you 
can start a timer to handle short interruptions without breaking all 
connections:
NutEventWait( EmacDisconnectEvent, NUT_WAIT_INFINITE);
rc = NutEventWait( EmacConnectEvent, 1000);
if (rc) {
   /* Connection has failed to long, stack is down! */
}
else {
   /* Fast enough, nothing to do */
}

Why that?
Now, if you have your EIR running as your alarm clock it might be 
uncomfortable (your boss might find other words) if the network had a 
dropout and you are not getting out of bed right in time.

With EmacConnectEvent, the EIR recoveres network connection.
With EmacFailEvent it switches from online radio to SD-Card or a simple 
Buzzer.

This is only an example. I guess it might be sort of dump if your 
serial-tcp/ip converter somewhere deep in the industry cabinet always 
needs a reboot if the network cable was put into another port of the 
switch or someone stumbled over it.

But one step after the other.
What I have in my code now is an EmacCtl() function that allowes polling 
of the EMAC/PHY state and it will be extended to allow some settings to 
be modified.
Step 2 is now to abstract PHY from EMAC and use one phy.c for all 
xyz_emac.c.
I cannot use _ioctl() for EMAC control as EMAC does not support FILE so 
I have no _fileno(). But EmacCtl() sounds to be fine for me.
Then I add the informational events.

For testing I rewrite the httpd example code to meet the new options and 
features. I'll add that one too with delivery of the emac updates.
Strong view on backwards compatibility is taken, until yet no change of 
old code is needed.

Ok, let me know your opinions.
And pleas give me an idea why the first ping after DHCP kills the 
system. If I first access the web page I can throw a adaptive ping for 
about 30s to the AT91 before it crashes. But adaptive means, that 
already 25000...32000 pings where handled correctly.

Best regards and good night
Ulrich