I have an LPC1768 based platform running FreeRTOS v10.2.0, the FreeRTOS+TCP stack and some third party components that provide websocket and SNMP services.
From certain machines on the network I can ping the device and access the network services it provides. There are, however, other devices on the network that won’t connect to it. On my Windows 10 based laptop everything started to work once I manually added the device into Windows’ ARP table.
Monitoring the network using Wireshark, when the various computers and servers send an ARP request (opcode 1) then there is a reply (opcode 2) sent with the corresponding MAC address. When ARP requests are sent to the device then Wireshark shows no matching replies.
This is causing a problem as we need to be able to connect to the device from mobile phones and tablets where there isn’t an easy way to manipulate the ARP table.
I have tried setting a debugger breakpoint early in eARPProcessPacket() in FreeRTOS_ARP.c but it never triggered so it looks as though the requests aren’t making it that far up the stack.
Anyone got any ideas as to where to look next? Is there anything the network driver (NetworkInterface.c) needs to do to handle ARP requests?
If I understand correctly, some nodes on the network receive ARP replies
while others don’t. Are the nodes that don’t receive replies on the
other side of a router or switch that could be interfering?
I have run some more tests and frame capture with Wireshark and the results are odd…
If I clear the ARP cache on my iMac (sudo arp -a -d) or Linux server (ip -s -s neigh flush all) then I see the IP address for the device (192.168.10.162) being deleted. In Wireshark I see the ARP request from the iMac and Linux server IP addresses asking “Who has 192.168.10.162?” but never a reply from the device.
Interestingly, on the iMac and Linux server, a call to “arp -a” shows that the device has been redetected and it is listed by its FQDN presumably given to it by the DHCP server.
On a Windows machine, deleting the whole ARP cache works and I see all the requests in Wireshark but as there is no reply it doesn’t get added to the ARP cache.
The iMac, Windows laptop and device are all plugged into the same switch and the Linux server is a further switch away.
It appears that the device never responds to an ARP request but macOS and Linux seem to find another way to get that information to add it to the ARP table.
Hello Andy, does your LPC1768 device never receive ARP request?
Or, are there some devices that don’t see the requests?
Have you enabled receiving broadcasts (MAC address ff:ff:ff:ff:ff:ff) in the EMAC/PHY of the LPC1768?
Does the device receive UDP broadcast packets?
One nasty situation that I have encountered is when an OS starts assuming that the target device is on a different network, on my WiFi in stead of the LAN.
When you run Wireshark with a LPC1768 device connected, do you see a gratuitous ARP request about every 20 seconds?
Have you enabled receiving broadcasts (MAC address ff:ff:ff:ff:ff:ff) in the EMAC/PHY of the LPC1768?
This is the comment that led me to find the cause of the problem. When setting up the LPC1768’s Receive Filter Control Register the bits to accept multicast and multicast hash frames weren’t being enabled.
Enabling them has fixed the issue and the Windows laptop with a wired connection and my mobile phone, using WiFi, will now both connect to the device.