Displaying all TCP connections with SYN packets

Question

Hello,

I'm working on a rather large .pcap file, and I'm interested in displaying only the TCP connections that contain a SYN packet. Is there any way to do this?

Accepted Answer

The display filter to show only SYN packets is:

tcp.flags.syn==1 && tcp.flags.ack==0

If you only want to capture TCP/SYN packets, the capture filter would be:

tcp[0xd]&18=2

When you are not only interested in the SYN packets, but also the SYN/ACK packets this changes to:

tcp.flags.syn==1
tcp[0xd]&2=2

If I read your question in another way, you are looking for "all packets belonging to a TCP session for which the SYN packet is actually in the capture file". If this is your question, this can't be done directly with Wireshak. But you can do it by using MATE or LUA.

Or you can write a tshark script to extract all the TCP sessions that have the initial SYN in the capture file.

Answer 2

1

(tcp.flags.syn == 1 and tcp.flags.ack == 0) is the display filter you want

answered 20 Sep '10, 10:48

grossman
16●1●1●4
accept rate: 0%

That will get you SYN packets only. Removing the "and tcp.flags.ack == 0" part will get you SYNs and SYN/ACKs.

(20 Sep '10, 10:49) grossman

That will show all packets that are SYN packets, but I want to see the complete connections for all connections that have SYN packets.

(20 Sep '10, 10:50) cmkastn

Ah. Hmm. Well, you could use the results of such a filter and then Right Click->Prepare A Filter->And Selected for the Stream Index under the TCP section of each SYN packet. Not exactly elegant, but that is the first thing that comes to mind.

(20 Sep '10, 10:55) grossman

Which can be automated with a little tshark scripting :-)

(20 Sep '10, 11:05) SYN-bit ♦♦

Answer 3

1

With the release of Wireshark 1.6.0, and thanks to some code changes by Sake Blok, you can now show all conversations that have their three-way handshake in the trace file with the display filter "tcp.window_size_scalefactor!=-1".

Note that this will show each CONVERSATION whose three-way handshake is present in the trace file, but it won't show the SYN packet or the SYN/ACK packet. The display will start with the third packet of the three-way handshake for each conversation. To see everything, select the stream you're interested in and then select "Follow TCP Stream."

answered 07 Jun '11, 13:51

Jim Aragon
7.2k●7●33●118
accept rate: 24%

2

That was indeed a nice semi-planned by-product from my code change... Glad to see it got picked up :-)

Well, since we're looking for all conversations that do have the 3-way handshake in the tracefile, adding all the SYN packets will not harm us here. So you could use:

tcp.flags.syn==1 or tcp.window_size_scalefactor!=-1

(07 Jun '11, 14:17) SYN-bit ♦♦

Thanks, Sake. That's what we're looking for. Question: In bug 5541, you said that the three values were going to be:

-1: 3WHS missing 0: No scaling negotiated, using the real value. 1 & higher powers of two: scaling has been negotiated & the window_size has been calculated accordingly

I see the following in the packet details pane:

[Window size scaling factor: -2 (no window scaling used)]

tcp.window_size_scalefactor==-2 shows me the streams that don't use window scaling; tcp.window_size_scalefactor==0 doesn't display anything. So I guess "0" got changed to "-2" in the final code revision?

(07 Jun '11, 15:07) Jim Aragon

Yes, while implementing, I wanted to be able to make a distinction between window scaling factor 0 and no window scaling used. Both will result in the window size not being scaled up, but they are completely different situations. So the values are:

-2 : Either the client or the server did not negotiate(!) window scaling, so no window scaling used
-1 : We have not seen the 3WHS and can therefor not tell whether or not to use window scaling
0+ : We do window scaling and this is the announced(!) window scaling factor for this flow

Hope this makes it clear...

(07 Jun '11, 15:43) SYN-bit ♦♦

Yes, that makes it clear. And I agree with distinguishing between the two situations. That was the original problem with bug 5541: Using the same name/value for things that are different.

(07 Jun '11, 16:02) Jim Aragon

Answer 4

For anyone who's curious, this bash script seems to work. I'm sure there's an easier way to do it, but I'm not the best scripter in the world.

#!/bin/bash
file=$1
outfile=$2
string=""
counter=0
for src in tshark -r $file -R &quot;tcp.flags.syn == 1&quot; -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport | cut -d &#39; &#39; -f1-4
do
if [ $counter == 0 ]; then
string=$string"(ip.src == $src && "
elif [ $counter == 1 ]; then
string=$string"ip.dst == $src && "
elif [ $counter == 2 ]; then
string=$string"tcp.srcport == $src && "
else
string=$string"tcp.dstport == $src) || "
fi
if [ $counter == 3 ]; then
    let counter=0
else
    let counter=$counter+1
fi 

done
string=${string%????}
tshark -r $file -R "$string" -w "$outfile"

Answer 5

If I only want to see the SYN-Flag (and not also SYN/ACK or funky flag combinations created by OS fingerprinting tools like nmap) I usually go for

"tcp.flags==0x02"

I used to do it like Sake suggested with the "tcp.flags.syn==1 and tcp.flags.ack==0", but I'm lazy and since my memory now allows me to remember the shorter version with "0x02" I use that :-)

Oh, and maybe this helps: if you want to avoid loading the whole trace and then filter it, you can also use the "tcp.flags==0x02" as a load filter in the open file dialog. That will then only load the frames that match and allow faster processing afterwards.