Ask Your Question
0

Wireshark seems to misinterprete some TCP packets

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

Bernhard Stockman gravatar image

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

grahamb gravatar image

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

1 Answer

Sort by ยป oldest newest most voted
0

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

grahamb gravatar image

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.

edit flag offensive delete link more

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 gravatar imageBernhard 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.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

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

Seen: 3,348 times

Last updated: Jul 31 '19