Hello everyone. I encountered an unusual issue with poor VNC access on a site I visited. The IT team assisted me, and after analyzing a Wireshark report, we discovered that data was being requested from the MAC address of the L33ER and broadcast out to the switch with a query for "who has 192.168.1.1". Surprisingly, the IP address it was requesting data from was actually its own. Despite eventually timing out and allowing the VNC connection, the performance is still subpar. The Ethernet radios have excellent signal strength, and I have not found any message instructions or Produce/Consume tags in the code. Can anyone provide hints on how to locate the source of this generated request within the PLC?
It is unlikely that a message would trigger an ARP request, as typically only devices within the I/O tree would do so. ARP requests themselves are not significant enough to impact performance, as they occur infrequently. In my situation, an ARP request of 44 bytes is sent approximately every 30 seconds. My suspicion is that there may be a device in the tree with the same IP address as the PLC. As an experiment, I inserted a generic module with the IP address matching my controller (192.168.1.10), prompting an ARP request to identify the owner of that address.
Is the VNC connection established once the self-ARP requests cease? Kindly provide a snapshot of the hardware tree for reference.
Here you are. It seems that the VNC can eventually establish a connection, particularly after the ARP process finishes.
The controller is not messaging itself but rather using a "Gratuitous ARP" probe to update connected switches and detect duplicate IP addresses on the LAN. Despite the great signal strength of the Ethernet radios, the statement "there's nothing wrong with the radios" is often questionable. Various factors can affect remote access performance, so it's important to not overlook a few ARP packets when using tools like Wireshark.
This feature is also utilized for identifying duplicate IP addresses. If Wireshark displays an ARP message stating "Tell 0.0.0.0," then a duplicate IP address has been detected.
It sounds like you might have a self-ARP issue where the PLC is constantly asking "who am I?". This could be the result of a programming glitch or a configuration error, causing constant unnecessary network traffic which slows down your VNC connection. Check your PLC configuration settings or update the firmware. Also, make sure there's no other device on your network using the same IP address to avoid IP conflicts. I'd also advise checking your router settings to ensure there's no redirect or loop that might cause such behavior.
It sounds like your PLC may have been programmed with a duplicate IP address or there's an IP conflict within your network. This could certainly cause your VNC connection to perform poorly as it's repeatedly trying to connect with the same IP address. One way to troubleshoot this might be to isolate the PLC and change its IP address to something unique within your network range. On the programming side, try using a network analyzer tool to pinpoint the problematic source code. You can also check if there is any sort of ARP request handling mechanism that might be inadvertently responding to its own requests. Additionally, ensure your network hardware firmware, such as switch or router, is updated to avoid any inconsistencies in handling network requests.
It sounds like you've got quite the mystery on your hands! Since the VNC connection is struggling despite good signal, it could be worth checking if there's a misconfiguration in the PLC's network settings or if it's inadvertently set to operate in a loopback mode. Have you looked into any scheduled tasks or events within the PLC that might be generating those requests? Sometimes, these issues can arise from unexpected network traffic caused by periodic diagnostics or logging functions. If possible, try capturing more granular traffic with Wireshark during those timeouts to see if you can isolate when those requests are happening—sometimes they can give you clues as to what process might be causing the slowdown.
It sounds like a frustrating situation! One possibility is that your PLC might be misconfigured, leading it to believe it needs to request info from its own address. Have you checked for any duplicate IPs on your network that could be causing confusion? Additionally, reviewing the PLC's communication settings and ensuring they're aligned with your network configurations could help streamline the connection. Sometimes, firmware updates can resolve underlying issues as well, so it might be worth checking if your PLC's software is up to date. Good luck!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: In this case, the issue could be related to a data request from the MAC address of the L33ER that is broadcast out to the switch, querying for its own IP address.
Answer: The issue was identified and analyzed by the IT team through a Wireshark report, which showed data being requested from the MAC address of the PLC and broadcast out to the switch.
Answer: To locate the source of the generated request within the PLC, one can investigate the PLC code for any message instructions or Produce/Consume tags that might be causing the issue.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.