Today is...
Tuesday, September 25, 2018
Welcome to the Modbus Community, about
the world's leading automation protocol.
Additional TCP packet between MODBUS/TCP query & response pair
Why is there always one TCP packet before the modbus/tcp query-response pair?

A master(client) is polling a slave (server) through modbus/tcp to collect data (func 04 read input register)

Attached are some packets captured by wireshark:

The first three are TCP handshake. I am not sure why there is always one TCP packet before the modbus/tcp query-response pair? and the content of that TCP header is exactly same as the content of the tcp header of its following modbus/tcp query packet, except the len field.

Can anyone help to explain? Thanks a lot.

kevin

368 13.167499 master slave TCP hagel-dump > asa-appl-proto [SYN] Seq=0 Win=65535 Len=0 MSS=1460
369 13.167622 slave master TCP asa-appl-proto > hagel-dump [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
370 13.167635 master slave TCP hagel-dump > asa-appl-proto [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0

417 14.160252 master slave Modbus/TCP query [ 1 pkt(s)]: trans: 0; unit: 1, func: 4: Read input registers.
418 14.160795 slave master Modbus/TCP response [ 1 pkt(s)]: trans: 0; unit: 1, func: 4: Read input registers.
444 14.472704 master slave TCP hagel-dump > asa-appl-proto [ACK] Seq=13 Ack=30 Win=65506 [TCP CHECKSUM INCORRECT] Len=0
488 16.160212 master slave Modbus/TCP query [ 1 pkt(s)]: trans: 1; unit: 1, func: 4: Read input registers.
489 16.160421 slave master Modbus/TCP response [ 1 pkt(s)]: trans: 1; unit: 1, func: 4: Read input registers.
494 16.332059 master slave TCP hagel-dump > asa-appl-proto [ACK] Seq=25 Ack=59 Win=65477 [TCP CHECKSUM INCORRECT] Len=0
554 18.160220 master slave Modbus/TCP query [ 1 pkt(s)]: trans: 2; unit: 1, func: 4: Read input registers.
555 18.160441 slave master Modbus/TCP response [ 1 pkt(s)]: trans: 2; unit: 1, func: 4: Read input registers.

read from other internet sources, wireshark does not support few function codes to decode the message but the message query and response is correct. Its only the wireshark decoding the modbus message problem

The first 3 are the TCP establishment sequence or 3-way handshake.

The ones tagged TCP between the response and the next query contain the ACK to the response.

Wireshark doesn't seem to associate frames with zero payload length with the protocol (Modbus) as they only carry information for the TCP-level.