Is it possible to filter Window Update-packets with tcpdump? I know that in wireshark the filter is "tcp.analysis.window_update" but I'm capturing traffic from a server and I can't use wireshark. For example the Zero Window packet (tcp.analysis.zero_window) can be filtered with "tcp[14] = 0 && tcp[15] = 0" in tcpdump. Is there something similar for Window Update? -Rakki asked 10 Oct '12, 02:12  rakki |
One Answer:
unfortunately that's not possible within tcpdump. There is no special flag or byte you can filter on with a capture filter. A window update is just an ACK with a new window size. tcpdump would need to build internal state about the connection (e.g. the previous window size), to detect the window update, and that is not implemented. Why do you need to filter/detect that during the capture process? Can't you just capture everything and then analyse the capture file later? With the text output of tcpdump and scripting, you should be able to detect the window update. Regards answered 10 Oct '12, 03:30  Kurt Knochner ♦ |
The problem is that there's a lot of traffic and I'll get a 300MB dump file in ~4 minutes if I capture everything. I need only the window update packets from 24 hours of traffic.
o.k. some ideas:
are you just interested in the fact, that there is a window update (not the packet itself)? If so, a little (perl) script might help. Dump the text output of tcpdump to the perl script, parse everything and build your own state within that perl script for every tcp connection. Then print the timestamp for every window update (plus any other information you need). It's a bit of work, but doable.
Or even better, use a perl module that can access the packets directly via libpcap, if that's possible on your system.
Not quite. We have a load balancer in front of our servers which generates its own zero window packets (like thousands of them). I need to find out how much delay it generates to the traffic and to do that I need the window update packets too. So what I actually need is the time between each zero window packet and the next window update. I've already done this for a 4 minute capture and it was around 60%.
I figured I can just capture all ack packets (length 60) and the dump file should stay small enough.
after the tcp session is established almost every packet contains an ACK flag ;-) Anway, if you capture only up to the TCP header, you will limit the amout of data to a level that should work for you and you would still be able to analyze the data.
That would do the trick. Thanks, Kurt.