This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Finding a network problem (Modbus traffic)

0

I've a strange problem, and find it very hard to find the cause. Maybe someone can help :)

My setup is like this:

1 PC with 2 network cards 1 card connected to subnet A (this is the connection to 'outside') 1 card connected to subnet B (this is a direct connection to only 1 device, a PLC)

We send Modbus packages to the PLC all day long, and most of the time this is absolutely no problem (get a direct response from the PLC). But then, out of nowhere, the communication is failing.

Now I try to find the cause of this. maybe the network routing in windows changes and the traffic is send to the wrong subnet?! Maybe someone is plugging in a 3G modem or another device to the PC that causes the problems (i do not know for sure because I’m monitoring the problem remotely). maybe bad cabeling.

So I was capturing the traffic, and now I noticed that the moment it is failing, I see a lot of SSDP messages. as far as I’m aware these messages are 'normal' and do not indicate a problem? but I’m not absolutely sure because I see them nowhere else in the traffic, only at the time the problem is occurring.

info: The PLC IP = 192.168.1.5 The PC = 192.168.1.100 (subnet 192.168.1.xxx)

the other subnet is 192.168.0.xxx

alt text

image of the first occurrence:

https://onedrive.live.com/redir?resid=782C76D08BB7C8E2!10690&authkey=!AL-J4M547ayp88k&v=3&ithint=photo%2cpng

asked 01 Sep '15, 07:42

DMeijden's gravatar image

DMeijden
1112
accept rate: 0%

edited 01 Sep '15, 13:20

Could you share us a pcap file instead of a screenshot?

(01 Sep '15, 12:16) Christian_R

Seems to me like the PLC has high latency since frame #23447. And it seems that it could not recover. Maybe the SSDP has something to do with it, it is Multicast ( But I really can´t say )

Have you cheked the logs of the PLC? It would be easier if you could trace at or next the PLC.

Is the connection a direct ethernet or is switched?

(01 Sep '15, 16:40) Christian_R

There is one switch. unfortunately i cannot monitor from the PLC side.

i try to find more information from the PLC side

(02 Sep '15, 01:58) DMeijden

If I were you, then I would try to find out, if this UPnP/SSDP_traffic is always related with problem situations or does it sometimes happens without issueing any problems.

(02 Sep '15, 12:09) Christian_R

One Answer:

0

It does seem awfully co-incidental that the problems with the PLC start just about the same time as the SSDP multicasts on the 192.168.1 subnet.

I would guess that the SSDP multicasts (which I believe are being used for UPnP [which see] on the PC) are somehow confusing/overloading the PLC.

So: (assuming that the SSDP on the 192.188.1 subnet/NIC is useless), I would research how to disable UPnP (at least on that NIC or maybe on all the NICs).

That being said, I see some other issues.

  1. In frame 23503, the "TCP ACKed unseen segment" message appears to be incorrect (i.e., a bug in Wireshark). I'll follow up on that. (Is it OK to attach a portion of your capture to a bug report I'll want to file at bugs.wireshark.org ?)

  2. The re-transmissions starting at frame 23461 seem to increase in size by multiples of 12 bytes almost as if additional Modbus requests are being added to the (retransmitted) packet sent as time goes on (even tho no reply has been received from the PLC). I'm not familiar with Modbus/TCP so I've no idea if this is OK (i.e. if the PLC can deal with this).

answered 01 Sep '15, 18:40

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850
accept rate: 17%

edited 01 Sep '15, 19:30

Thanks for your reply. I also noticed the add of a new modbus request to the retransmission. This is due to a bug in the software that is sending the modbus requests. We will fix that soon.

I will try to capture more data and see if the problems happens again when the UPnP messages are rising. then i try to find a way to disable UPnP.

(02 Sep '15, 01:37) DMeijden

Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.

(02 Sep '15, 04:05) Jaap ♦