Wireshark seems to misinterprete some TCP packets

Chromecast
AJP13
retag add tags

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?

Bernhard Stockman

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

23.8k

grahamb

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

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Wireshark seems to misinterprete some TCP packets edit

Comments

1 Answer

Comments