Wireshark seems to misinterprete some TCP packets

asked 2019-07-31 08:06:15 +0000

updated 2019-07-31 09:22:20 +0000

flag of United Kingdom of Great Britain and Northern Ireland

23790 ●4 ●950 ●227 https://www.wireshark.org

I am doing some checks on communications between Google Chrome and a Chromecast device. Unfortunately I do not have 60 points so I cannot attach the wireshark file but have to try to write relevant part of the rows here. 192.168.47.68 = Windows PC 192.168.47.75 = Chromecast device

Source Destination Protocol  Length Info
192.168.47.68  192.168.47.75 TCP 66 58528 -> 8009 [SYN] 
192.168.47.75  192.168.47.68 TCP 66 8009 -> 58528 [SYN, ACK]
192.168.47.68  192.168.47.75 TCP 54 58528 -> 8009 [ACK]
192.168.47.68  192.168.47.75 TCP 200 58528 -> 8009 [PSH, ACK]
192.168.47.75  192.168.47.68 TCP 60 8009 -> 58528 [ACK]
192.168.47.75  192.168.47.68 AJP13 1214 AJP13 Error?
192.168.47.68  192.168.47.75 TCP 54 58528 -> 8009 [ACK]
192.168.47.68  192.168.47.75 AJP13 180 AJP13 Error?

It is of course the AJP13 I think is a bad interpretation of the TCP packet as this is a communication with a Chromecast device. AJP13 = Apache Jserv Protocol version 1.3. I am just showing the first lines of the Wireshark output. It continues with several more rows but then it is not showing any AJP13 rows. By the way Apache JServ Protocol also uses port 8009.

Looking in the IP packet with the AJP13 rows it clearly says Protocol = 6 i.e TCP.

My question is thus: What makes Wireshark think this is an AJP13 packet? All the communication is between my computer port and port 8009 but it is only two rows where AJP13 shows up. It seems there is something else than the port number that triggers this.

Any idea where I shall look in the packet besides the IP-packet protocol number?

edit retag flag offensive close merge delete

add a comment

answered 2019-07-31 09:45:48 +0000

grahamb

23790 ●4 ●950 ●227 https://www.wireshark.org

The AJP13 dissector will only be invoked when there is actual data to be processed, and by default, traffic to\from port 8009 will be given to the AJP13 dissector. Most of the packets you list are either TCP handshake packets or ACK's which have no data. This is normal Wireshark behaviour and explains most of the packets.

The outlier is the 4th packet that has some data but doesn't seem to have been processed by the AJP13 dissector. This might be because the data is such that the dissector doesn't think it's an AJP13 packet.

You can disable any dissector in the case of false positives by either:

Right-clicking the dissector line in the packet detail pane and selecting Protocol Preferences -> Disable <dissector name="">
Using the menu item Analyze -> Enabled Protocols and then search for the dissector in the list and uncheck it.

Capture files can be uploaded to a public sharing site, e.g. Google Drive, DropBox etc., and a link to the file added in the question or a comment.

Comments

Ahh, that solved this issue. After disabling AJP13 it now shows as TLSv1.3 which fits much bettar in this scenario. Thanks.

Bernhard Stockman ( 2019-07-31 10:44:03 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Wireshark seems to misinterprete some TCP packets

1 Answer

Comments

Your Answer

Question Tools

Stats

Wireshark seems to misinterprete some TCP packets edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Wireshark seems to misinterprete some TCP packets