[En-Nut-Discussion] DHCP failure case update

[Joe Doubek]

I just wanted to post an update. I have tracked the DHCP failure to the
NicRxLanc thread. That thread calls NicStart(), which then calls
NicPhyConfig() which returns -1 after 10 seconds if it can't
autonegotiate. NicStart() then passes the error code back up to
NicRxLanc which doesn't check the error code and continues as though
autonegotiation completed successfully. 

I fixed it by having it retry every few seconds until autonegotiation
completes. In NicRxLanc:
 
NicStart(ifn->if_mac);

Becomes:

while(NicStart(ifn->if_mac) == -1) 
    NutSleep(5000);    

Maybe this would be a fix to roll into the build, any reasons not do
this? My device is a networkable stereo component that runs with or
without Ethernet plugged in. I wanted this fix so that as soon as
Ethernet was plugged in it would robustly come up on the network.



 

Joe Doubek | Embedded Systems Engineer
____________________________ 
Control4 
11734 South Election Road, Suite 200
Salt Lake City, UT 84020
United States
e. jdoubek at control4.com
w. www.control4.com
 

 

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Joe Doubek
Sent: Thursday, January 20, 2005 6:54 PM
To: en-nut-discussion at egnite.de
Subject: [En-Nut-Discussion] DHCP failure case


Hello all, I'm seeing some strange DHCP behavior and wanted to ping the
group about it. This is under 3.9.2 of NutOS, though I saw the same
thing under 3.4.2. I make a call to DhcpIfConfig() with a timeout of 0
to force it to wait forever for configuration. I've noticed that DHCP
never can recover if the network cable isn't plugged in for a few
minutes after the DHCP thread is started. Once the cable is plugged back
in I see discovers go out and offers come back but dhcp never sees them.
I tracked this back to NutUdpInput() calling NutUdpFindSocket(), which
in turn looks for a matching port in udpSocketList and in this case it
never finds one. I have confirmed I'm still seeing the incoming offers
on port 68 (sp->so_local_port in NutUdpFindSocket() contains port 68).
I've also confirmed NutUdpDestroySocket() is never being called before
it gets in this state. It seems as though the DHCP socket port gets
wiped in udpSocketList if the network cable is unplugged for a few
minutes while the DHCP thread is running. If the device is plugged into
a hub but with no DHCP server running it doesn't appear to be a problem.

 

Joe Doubek | Embedded Systems Engineer
____________________________ 
Control4 
11734 South Election Road, Suite 200
Salt Lake City, UT 84020
United States
e. jdoubek at control4.com
w. www.control4.com
 

 

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion