0

Can anyone help me better understand what is going on here? I keep receiving "broken pipe" errors that say the connection is being reset by the peer. Also, I thought 192.168.114.30 was the client, but from my reading, the original SYN in a handshake is supposed to come from the server (and same with the RST, ACK). I'm sorry if this is an obvious answer. I've tried to do as much research as possible. Any help is greatly appreciated.

HERE IS A PICTURE OF THE DUMP

EDIT: I appreciate any answers and apologize for my lack of knowledge on the topic. I wanted to add the when querying the socket stats with the ss command, I do not see this server listed as it should be. Does this mean that the server is not listening to any ports? Is this something that needs to be resolved within the server’s end of the modbus configuration?

It’s worth noting that this issue is present across multiple facilities that we operate, all related to the same device (a UPS) that the server is supposed to be sending data from. At one of the sites the dump indicated only ARP requests, so that one can’t even locate the MAC address.

Last question - is this at all related to a heartbeat timeout issue? I don’t believe it is, but there are people above me (that frankly aren’t that familiar with the Modbus TCP Protocol either) that seem to think it is. I understand a “Connection reset by peer” can be caused by a timeout, but does anyone have suggestions on how I can rule that out with confidence?

Jonny Hoffman
  • 1
  • 2

2 Answers2

0

Your idea that the original SYN packet comes from the server is wrong. How and why would that be the case?

Q: When I open my web browser to google.com which side is initiating the TCP connection?

A: My side is.

Q: Where does the first SYN in the three-way handshake come from?

A: My side.

Q: How could google.com initiate the three-way handshake with me?

A: They can't.

In your capture, 192.168.114.5 is initiating the connection and is the "client". 192.168.114.30 is the "server". After the three-way handshake completes, the server is terminating the session with a RST packet. Is there a process/service/daemon listening on port 53734 on the "server"?

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • Yes, I see what you’re saying. I was told by someone else at my company that the 192.168.114.30 IP was associated with the Client, but as I mentioned it didn’t seem to match up with any of my research. There is supposed to be a process listening on the server side, but when I execute the ss command, for example, the 114.30 server doesn’t appear anywhere, even when using the all option. I also checked the firewall and iptable rules, but didn’t find anything suspicious. Do you have any suggestions on steps I can take using the CLI? Sorry for the lack of knowledge, I’m still learning. – Jonny Hoffman Aug 20 '22 at 14:36
0

According to your network dump, the machine with IPv4 address 192.168.114.5 is acting as a client, initiating a TCP connection to port 502 (Modbus) on IPv4 address 192.168.114.30 which is therefore acting as the server. The two machines complete the three-way handshake but 5 ms later the server aborts the connection by sending a RST (reset) packet.

The reason why it is doing this needs to be investigated on the server, ie. the machine with IPv4 address 192.168.114.30. The application listening on port 502 of that machine may have insufficient resources to process the connection request or encounter some other kind of malfunction. If there's nothing helpful in the logs you may have to need to resort to debugging that application.

It is definitely not a timeout or heartbeat issue. The connection is actively aborted by the server by means of an RST packet, and that packet is arriving almost immediately, much quicker than any possible timeout. If anything it is a malfunction of the server.

Tilman Schmidt
  • 3,778
  • 10
  • 23
  • Thank you, very well explained. When you say application would that be referring to the modbus configuration? I apologize for the lack of knowledge. I’m still learning, and this issue was kind of thrown on me and is frankly outside of my job requirements. Though I do really enjoy learning about it. – Jonny Hoffman Aug 20 '22 at 15:23
  • Also, is there anything I can do straight from the CLI that could help narrow down the issue? The ss command doesn’t show this server (even with the all option), but the rest of our modbus servers are doing fine. The issue is present with this particular device (the one connected to the server that the client wants the data from) across all facility that have the device (it’s a UPS). This lead me to believe it may be something in the config file that is causing the issue, as the integration team used the same config for all facilities since the device is the same across all of them. – Jonny Hoffman Aug 20 '22 at 15:36
  • So 192.168.114.30 is the UPS? I assume you cannot run `ss` on the UPS so you ran it on the client in which case wouldn't be able to show listening sockets on the server. Please edit your question to clarify this, so I can amend my answer accordingly. – Tilman Schmidt Aug 22 '22 at 18:11
  • Anyway, the server is definitely listening on that socket since it answers the SYN with a SYN/ACK. – Tilman Schmidt Aug 22 '22 at 18:17