I\'m trying to save only POST packets using tcpdump filter expressions. I starte
ID: 660185 • Letter: I
Question
I'm trying to save only POST packets using tcpdump filter expressions. I started with 'tcp port 80' and I found on the web a specific expression to achieve that.
tcpdump -i wlan0 -s 0 -A -vv 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354'
Where 0x504f5354 means POST.
That works, but when only saving packets instead of printing them on the standard output and opening it on Wireshark I get just a few random packets. Here's my command,
tcpdump -i wlan0 -s 0 -A -w test.pcap 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354'
Explanation / Answer
I have not clear what you mean by, "when only saving packets instead of printing them on the standard output and opening it on Wireshark".
I believe, however, that you're trying to save "POST data" (which lives at the HTTP level) while your expression specifies only the first POST packet (living at the TCP level).
If you're intercepting, say, a 5Kb POST packet, chances are that it has been fragmented into three or more shorter packets (with say 1476, 1476, 1476 and 692 bytes payload - numbers almost at random, I haven't checked, but you see my meaning). Of these, only the first does actually contain the HTTP POST command, so that it is actually intercepted.
And there's more. The HTTP1.1 protocol allows for keeping the connection alive and "pipelining" commands in a single TCP connection so as to save the handshake and socket maintenance hassle. So you can have three POST commands in a single conversation: POST data1... POST data2... POST data3...
and of course the chances of any but the very first POST to come exactly at the beginning of a packet and be snatched by Wireshark are very small.
In order to properly capture POST data you need a HTTP proxy with conversation capture facility (or Firefox's Firebug, which is better for some applications), and have the whole HTTP stream parsed and the POST requests captured. Otherwise you would need a PCAP regexp complex enough to understand HTTP, which, even if feasible (which I'm not too sure), would be exceedingly impractical.