Could someone please help me with a problem I'm having with an RFID reader system that uses TCP/IP communication?
I have a system where an RFID reader reads some transponders, but I'm experiencing a series of timeouts that occur after the maximum time of 500 ms. I’m not an expert in Wireshark or TCP/IP communication, but based on my analysis, I haven’t seen any concrete evidence that the problem lies in the communication between the CPU and the reader. I’ve noticed some retransmissions and the occasional RST—could this be the cause of the timeouts I’m experiencing when reading these transponders?
I recorded the communication between the CPU (192.168.123.83) and the RFID reader (192.168.123.142), and the only interface between them is an industrial switch with PROFINET communication.
|CPU| <---PROFINET---> |SWITCH| <---ETHERNET---> |RFID (reader)|
I've attached the file to the Drive link below, in case anyone would like to take a look at it
WireShark file: https://1drv.ms/f/c/eff369258839971a/...
Where/how is the packet capture made? See the CaptureSetup of the Wireshark wiki.
Jasper's blog (https://blog.packet-foo.com/) has articles on packet capture and when to capture in multiple spots.
The goal is to see if the RFID reader is not responding or if it does and the packets are lost before they reach the cpu.
Thank you for the document. I’m capturing the data using a “Switch + Monitor Port” setup, where I’ve mirrored the port to which the RFID is connected to another port, to which I’ve connected Wireshark.
The system is simple: I have a CPU connected directly to the switch via PROFINET and an RFID connected to the same switch via Ethernet.
As I said, I’m no expert, but from what I’ve been able to analyze, the RFID isn’t failing to respond. However, I can’t say whether data is being lost between the two devices due to RSTs or retransmissions. If these alarms aren’t anything to worry about, I’ll know that either the CPU isn’t able to process the amount of data being exchanged or that the physical network path is compromised. Thank you.
Any idea why the source port (2002) on the cpu never changes?
I'll quit here - there are others with more knowledge of TCP.
Current versions of Wireshark support "TCP Conversation Completeness" (see 7.5. TCP Analysis section in the Wireshark User's Guide).
A display filter of
tcp.completeness == 1shows many attempted TCP sessions where the RFID does not respond. Was it too busy to respond or did it ignore theSYNor did it not receive theSYN?Going on a tangent here: I'm also seeing a lot of ARP broadcast traffic here. I've seen smaller devices (probably like yours) succumb to that amount of traffic. As an experiment you could setup a dedicated network with just the CPU and reader, without other network elements and see if it survives that. It might give a clue.