Hello All, I'm analyzing a large device network. One thing I come across are four devices (all from the same manufacturer) that constantly broadcasting the same gratuitous default IP ARP requests. They devices are all assigned to have a static IP (10.10.x.x) and the server is configured to use that static IP. When looking into the communication it seems to continue on the assigend open connection, although the ARP requests. Nevertheless the devices are constantly broadcasting the gratuitous request 169.254.24.7. Wireshark detects this as a conflict because they all use the same. I understand that normally this would indicate a device that lost it's connection and assigend to receive an IP from a DHCP server. The weird thing is communication seems to continue on the static assigned IP. I guess because the connection remains open so the server ignores the message? So my question is what can cause these broadcasts here and how or should we get rid of these broadcasts.
Above the communication between the server 10.10.0.3 and 10.10.10.234 with MAC 00:02:99:12:da:c5 asked 04 Dec '16, 08:49  RFMuser edited 04 Dec '16, 08:55 |
One Answer:
There are a number of reasons, why a system can have multiple IP addresses on the same network interface card. Quite scary: An interface could have an address, that is not even visible to the operating system. Here are a few possibilities: A voice VLAN Certain Voice over IP applications assign a separate VLAN for VoIP traffic. Depending on your capture configuration you may or may not see the VLAN tags. This depends on your hardware and the capture application. The network capture playbook on blog.packet-foo.com gives a lot of insight into the many wonders of network sniffing. Some really strange and misconfigured VPN client could also be a culprit. Unlikely in this case, as this would coincide with a loss of quality in your VoIP solution or a VPN malfunction (if you run one, that is). Still, it might be worth to check the advanced properties in your network card for VLANs. VMware, Virtual Box or another virtualization solution These software products can emulate a network interface card that is bridged. So basically, you detect two adapters, that are both assigned to the same physical interface. Each would demand it's own IP address. This scenario can occur if the virtual machine does not use it's network interface card or is misconfigured. Usually, the virtual network adapters would have a MAC address that relates to the virtualization software. While this scenario is possible, you would have spotted VMware or other MAC addresses. Intels Management Engine My favorite. And also the most likely explanation for the symptoms, that you observe. Most Intel processors (everything with vPro) come with Intel's management engine (ME for short). The ME is part of Intel's Active Management Technology (AMT). The ME has it's own coprocessor and uses the network interface card like a parasite. You can do a lot of miraculous things with the ME. Some tricks are a remote Windows installation, remote power on or power off, remote VNC even if the system is showing the blue screen of death. The traffic handled by the ME can be recorded with Wireshark on your local system. The ME has it's own TCP/IP stack. Just like any other IP stack, addresses can be static or dynamic. If Windows is happy with the address, the ME might not be. Check your hardware documentation how to get into the ME settings. Many systems react to Ctrl-P in an early boot phase. Feed the terms Intel, AMT and ME to your favorite search engine to get more details. Good hunting answered 05 Dec '16, 12:40  packethunter |
I'm going to guess it is a device bug. Suggest to contact the vendor.
I see probes as well as GARPs, which are both used in RFC 5227 for duplicate IP address detection. So I guess it's possible it is not a bug but some weird DupIP detection scheme, but looking at the timing, it does not appear so. Its from Apex, but don't know what products they make that use ModbusTCP so guessing it is some type of bridge or industrial automation device.
It looks like it's testing if another device is already using this IP and since no device answers it finally changes it's own to the default. Of-course the other devices do the same thing.
I will contacted the vendor but the first question is "are you experience comm problems" which I don't discover at the moment. But since we are analyzing the network and try to get rid of all the noise this would also fall in that category.
Am I correct that devices on the 10.10.x.x subnet ignoring the ARP broadcast and not updating their tables to this new IP since this is not in the their subnet?
Correct, these will be ignored. Technically, you might be able to filter them but you usually can't just block ARP - it's needed for subnet communication. You would have to try to block ARP with 169 series addresses. It's not nice behavior, but how much is there (i.e. pps)? Small amounts are usually harmless. However, it is usually best practice to minimize broadcast traffic on a network especially with embedded devices as they have less resources available to handle network load.