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

Ssh display filter doesn’t match TCP port 22 packets?

0

While analyzing packets for an ssl issue today, I entered "ssl" into the Display Filter, and no packets were found. Further inspection showed that there WERE TCP packets using port 22 in this trace. I was very surprised that my filter didn't find them.

Some more experimentation showed the following Wireshark behavior for packets using TCP port 22...

If a successful SSL connection was established (3-way handshake completed), the ssh filter found those ssl packets.

BUT, if an SSL connection was attempted, but not completed (destination did not respond to the SYN packets), the filter did not find these packets. I expected that the "ssl" display filter would match any TCP packets using port 22, but that was not the case.

Is this expected behavior??

Thx, Feenyman99

asked 09 Jan '14, 21:17

feenyman99's gravatar image

feenyman99
96222226
accept rate: 25%


One Answer:

4

Yes, this is expected behavior. If there is no data in the packet, then it's not an SSH packet, it's just a TCP packet. Wireshark behaves this way with all the higher-level protocols that run on top of TCP. For this reason, "tcp.port==22" is usually a better display filter than "ssh".

Even when the connection is successful, the "ssh" filter is only showing you the packets with data in them. It does not display the connection establishment process, the connection termination process, or any TCP packets that don't have data in them, such as naked ACKs, Zero Window, Keep-Alives, etc.

Use "tcp.port==22" when you want to see all the packets. Use "ssh" when you really only want to see the packets with data.

answered 09 Jan '14, 21:38

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

Wow... This certainly proves the adage that you learn something everyday. I've been using Wireshark/Ethereal for 10+ years, and I never noticed this behavior. The most common "protocol" filter I use is probably "dns", which, unless it uses TCP, is almost never "data-less", so the "dns" filter will find the same packets as udp.port == 53.

I also often use "http", but I never noticed till I just now tried it again, that when i do that, the 3-way handshakes don't appear.

The only reason I noticed this behavior the other day, and submitted this question, is that I was troubleshooting an SSH connection attempt that never completed, and hence there were no data packets.

Anyway... Thanx for the clarification. I'm a wiser man today :-)

(10 Jan '14, 11:28) feenyman99