RTOS/TM4C1294NCPDT: Link state callback stops getting called after multiple ethernet disconnects/reconnects - NC_setLinkHook()

That print statement happens if there is no IP address bound (among other things):

    /* Check for misconfiguration */
    if( !hIF || !IPDst || IPDst==0xFFFFFFFF || !IPSrc )
    {
        DbgPrintf(DBG_ERROR,"LLIGenArpPacket: Illegal ARP Attempt - Check Configuration");
        return;
    }

S D said:

Network Removed: If-1:192.168.1.52

This might be the cause. Are you removing the IP address from the system?

Steve

Hi Steve,

Thanks for the reply.

Yes I am removing the IP address whenever I lose link state. This is so that if the device changes networks, it can get a new IP address if necessary.

Is there anything I should be watching for when trying to allow the device to switch IP addresses when changing networks?

--Subhash

EDIT:

It's probably worth explaining what I am trying to accomplish...
I'm trying to write firmware that supports a customer configuring either a static IP or using DHCP. Which option is used can be decided on boot by checking EEPROM.
The device needs to be able to switch between networks and so must be able to handle and recover from network disconnection/re-connection events.

I was provided some example code by another TI person awhile ago that showed how to use CfgAddEntry and CfgRemoveEntry to add/remove static IP addresses and reset the DHCP so that it could handle switching between different networks and getting new IP addresses.

Hi SD,

Perhaps you need to clear/delete the ARP cache prior to removing the IP address? Should not DHCP be capable to reassign a new IP to the same MAC at the switch? Perhaps it is not necessary to remove the IP on link state changes since DHCP server IP lease manager will ignore the cached MAC and assign a new IP on the clients new VLAN/network.

On the PC via a command prompt type ARP -d. LWIP 1.4.1 not sure where the ARP table resides in memory. Yet how could the Swedish institute of technology not make such possible in LWIP given it's huge tasking.

7-23 See that was silly comment as the Sysbios NDK shell is handling device function calls in your application. Recently tested LWIP1.4.1 with Sysbios and it actually worked seamlessly with IOT application calls but couldn't say how effective the IP subnet changes are/were. For what it's worth Sysbios was assigned a task that launched the LWIP Ethernet client on command.

Hey Steven,

I still need help with this if you can spare the time.

The other thing that I've found is that if I remove and re-add DHCP, sometimes it will never acquire a new IP address again until a full reboot of the chip occurs. Restarting the NDK doesn't help. Restarting the DHCP service doesn't either. And this is on a wired network with a working DHCP server. I believe all these issues are related to my trying to correctly support switching between networks. If you can provide any guidance on this, I would really appreciate it. I've spent a couple of weeks reading through the NDK docs, the forums, trying different things...

Thanks,
Subhash

Hi Subhash,

My apologies for the late response. Let's see what we can figure out here.

S D said:

I'm still seeing "LLIGenArpPacket: Illegal ARP Attempt - Check Configuration" occasionally. This time it happened when I was trying to switch between two different DHCP networks.

The print statement that this is coming from is:

DbgPrintf(DBG_ERROR,"LLIGenArpPacket: Illegal ARP Attempt - Check Configuration");

Note the "DBG_ERROR" present at the beginning. This is actually a threshold that's used as follows:

1. To filter the trace
   1. For example, you could configure the stack to filter only DbgPrintf trace messages that are labeled "DBG_ERROR". Any other threshold levels (e.g. DBG_INFO) would be ignored.
2. To close down the stack
   
   1. The DbgPrintf() function can be used as a way to abort with an error message.
   2. This works similarly to the above, in that you set the threshold for message types that you want to cause to shut the stack down.
   3. The default behavior is to shut down the stack on "DBG_ERROR" messages.
   4. This is configurable in your *.cfg file via 'Global.debugAbortLevel'

So, what's happening here is you're hitting this ARP error case and it has an error message with its threshold set to DBG_ERROR, which means "shut down the stack"/"abort". The author deemed this to be a fatal error.

However, looking at he code, I'm not convinced that it actually is (fatal). So, I think what you should try is to change the abort level so that DGB_ERROR messages will not cause the stack to shut down. You can do this by adding the following *.cfg code to your file (adding at the end of the file is fine):

Global.debugAbortLevel = Global.DBG_NONE;

(Note that this will prevent any other DBG_ERROR level prints to *not* shut down the stack. I think this should be OK for now, though. Depending on how it all goes next, then we can decide if this needs to be handled differently. But, please be on the look out for other error messages).

S D said:

I removed the DHCP service and address using this example code: e2e.ti.com/.../439972

[...]

Should I only remove CFG entries during network open/close events after restarting the whole NDK?

You can call the CfgAdd/RemoveEntry() functions while the stack is up and running. So, you don't need to limit this to the start up/shut down of the stack.

The code you have found in the linked thread should be correct.

What context are you doing that in?

Reviewing the thread, I see you've tried a lot of different things. I think your original design of removing the IP address and then removing and re-adding the DHCP client service when the link goes down is the right way.

I think you should change your configuration as described above and then retry your test.

Steve