network lockup caused by "Mobile IP Advertisement"

Embedded Devices
, , ,
1

Using NetOS 7.5 patched to latest, on CC-9P
Communicating with a host computer on a different subnet, via one or more Cisco switches, using TCP/IP.
After about 7.5 minutes, the device locks up. (Other units on the same subnet as the host computer work continuously for months, or even years!).
Network tracing has revealed the following sequence of events:

  1. Every 7.5 minutes, a network device (Cisco Switch, not necessarily the one our unit is plugged in to) generates a multicast (224.0.0.1) Mobile IP Advertisement packet.
  2. As soon as it receives the multicast packet, the unit responds with ARP request, “Who has 10.755.1.155? Tell 10.75.1.90”. This tells us that it does not have an entry in its ARP table for the network device that sent the Mobile IP Advertisement. The network device responds with an ARP response, “10.75.1.155 is at 00:b0:e1:53:74:b1”. So far nothing is out of the ordinary.
  3. The unit then resumes its communication with the host computer, but the next packet that it sends has its destination Ethernet address set to that of the network device, not the router. The network device cannot route the packet and responds with an ICMP Destination Unreachable packet. All subsequent packets from the waveguide switch controller to the host computer are routed the same way and communication is quickly lost.

In this particular case the workaround is to suppress the multicast packets, but that’s not always possible.

Has anyone else seen anything like this, or got ideas on how to resolve the problem properly?

(I think we’ve seen this problem a few times over the years, triggered by an inter-site link failing to the backup, but this is the first time anyone has been able to look in detail at the network traffic)

Mobile IP Advertisement packets are part of Mobile IP (IETF RFC 5944)

2

I suspect the multicast packet generated by Cisco switch is a router advertisement packet.
http://www.networksorcery.com/enp/protocol/icmp/msg9.htm

Netos is acting appropriately on it.
We released a patch for Netos that properly implements a function that allows disabling TCP stack acting on router advertisement packets. You’d have to call:
NAIpEnableIcmpRouterDiscovery(FALSE);

    NAIpEnableIcmpRouterDiscovery(FALSE);

The patch is implemented in:
NETOS75\src\bsp\commonnaip_global.c

The patch was made available via DigiESP package manager, so if you installed all the updates from there you should already have it.

3

Thankyou for prompt response. Looks extremely likely that this is the answer to the problem, but I’ll wait until its been tested before confirming for sure. Might take some time!

Can this routine be called early on in ApplicationStart(), or does it have to wait until the network is up?