Archive for Packet size limited during capture

tcpdump – Packet size limited during capture [ENG]

Posted in Computación with tags , , , , , , on 16/July/2009 by Alex Pérez
Wireshark logo

Wireshark logo

[Due to the # of hits of this entry, I translated this to English …. my poor English xD]

I was looking why a web application was not running at all. The browser must send a request and the app should add some headers in order to login without problems … but seeing that the web application didn’t behave as expected, I decided to see what’s going on and what was sending *exactly* the browser to the app.

So, I left a “tcpdump” running in the server, and replayed the issue with the browser. When I opened the dump file with Wireshark (Ethereal fork, AFAIK), I found that too many frames got a tag “Packet size limited during capture”.

WTF?

After searching with Wireshark some strings that are supposed to exist in the HTTP request ….no luck. But I’m 100% sure that the browser is sending the string I’m searching!?

Wireshark - Packet size limited during capture

Wireshark - Packet size limited during capture

No luck. And … what’s this message “Packet size limited during capture”?

After googling for a while, it seems that older versions of tcpdump, or running tcpdump in old OSes, by default the packet size it’s truncated to 96 or 68 bytes. So, the Wireshark/Ethereal option “Follow TCP Stream” is unable to show what’s exactly going on between the broswser and HTTP server.

If we want to capture network frames full-length, you must use “-s 0” flag. (ie # tcpdump -i eth0 -w file.cap -s 0). But in tcpdump manpage they alert that this is a lot of extra work to the server. With the “-s 0” flag, the frames are captured with the original length, and we can follow the TCP stream as required.

HTH

Advertisements