Using Tcpdump to analyze HTTP won't always work. Unless I'm mistaken, Tcpdump doesn't decode packet fragments into a stream, so if the request is fragmented, your grep won't work. If there are multiple HTTP requests in one TCP stream, it's less likely they are aligned completely in one packet, also fragmenting the request. And if it's a request to Google it could be in QUIC rather than TCP. You may wonder what on your network is broken because you can't see the requests, but it's just the network fragmenting packets.
Tshark (nee Wireshark) I believe does decode packet fragments into streams, and allows you to use more advanced Wireshark protocol filters. My suggestion is to start a pcap capture, and at the same time replay it using Tshark with the filters you want. This way you can re-analyze the same live traffic both now and later.
I use tcpdump continuously to analyse multiple RTP feeds coming in to our edge network. Found all sorts of issues with it, including packet reordering in Cisco and mikrotik routers (shouldn't be a problem with rtp - but tell that to ateme decoders), actual packet loss on juniper srx, and of course minor outages on international and even local links on the order of 100-200ms of loss.
Packet stream is dumped into some perl which keeps across the sequence number looking for out of sequence packets, summarise output every second into an elastic stack. Also have it comparing multiple streams for dual streaming and comparing skew.
Ironically I rarely use tcpdump to look at tcp packets - about the only interesting thing to me there is the SYN packets to see if the packet is getting through the firewall!
I think a similar post on leveraging Wireshark would be neat. The deepest I tend to need to go is searching packets for a known substring and then following the TCP stream to see where something unexpected happened. Add to this the analyzing of the frames on this stream and you can diagnose tricky timeout issues, bad protocol usage, and much more.
Yeah, my workflow is generally to use tshark (wireshark's command-line tool) for server-side capture, then scp file to local and use wireshark gui to poke around. I find tshark's interface to be simpler than tcpdump. tcpdump feels like bringing a gun to a knife fight when all you want to do is look at application layer payloads/streams (http/etc). But it's good to know more about tcpdump than I did before, because when things get complicated it's good to have more options.
You can also pipe tshark capture to the Wireshark GUI on your machine through ssh in realtime, e.g. `ssh host.example.com 'tshark -i eth0 -w - -F pcapng -f "not tcp port 22"' | wireshark -k -i -`
I recently presented my tool HTTPanalyzer at RIPE76.
It's a C tool I developed in 2016 available at Github for processing HTTP traffic up to 10Gbps from PCAP files or straight from the interface. I recommend the branch "revisited", much better coded in my opinion. Of course, it's limited to the first packet of the request and first packet of the response. It's aimed to aggregated statistics like response codes, user agents, response time (immediate one, not full load of the resource) etc.
More info here: https://carlosvega.github.io/httpDissector/
Only HTTP traffic, you can process decrypted HTTPS traffic (like some devices do, i.e. IXIA network devices) which is transformed into HTTP traffic. Regarding HTTPS or HTTP2 etc. The current approach is to correlate the application information from log events against traffic measurements.
There should be a better way to do that. Ideally I would want a tool shows Request Method, Headers, Query String, POST Payload of requests as they come in (and let's me filter on those). It should support HTTP2 and know how to stitch together the payload from multiple packets.
HTTPS is a difficult topic. I think it's fair for a tool like this, not to mess with encrpytion. Usually you don't want to had a precious private key file to a command line tool for debugging. A better way seems to be to terminate SSL on a separate host, and analyze the un-encrypted traffic.
If you've already terminated SSL, you can do this easily by using iptables nflog rule to duplicate traffic and send it to mitmproxy. Or you can setup a transparent proxy (but sounds like that violates your requirement). Either way, if SSL is not terminated you're not going to be able to do much.
1. Use `-i any` -- just in case the traffic you want to look at is not on the interface you think it is. Also doesn't put the interface(s) into promiscuous mode, which can be preferable.
Shameless plug, but if you’re interested in this sort of thing, I published a proof of concept docker container that makes packet analysis with scapy very easy. [0] The trick is to leverage iptables nfqueue to filter packets you’re interested in, and have scapy listen to the queue.
The "-nn" explanation seems wrong. Neither libpcap's tcpdump nor BSD's need more than one "-n" to not translate port. Even in their examples, we can spot that using a single "-n" do not translate port names.
Additionally, it's always better to always use "-p" if you don't want to accidentally attract additional traffic to the host (additional VLAN on a 802.1q interface, or additional multicast traffic).
Really annoying, in the common case you don't want /etc/services names since they're always wrong for the ephemeral >1024 client side port. Also, not to be confused with `lsof -n -P`!
For example, imagine spanning/mirroring a 10G backbone link, how many people are pinging 8.8.8.8 all the time. I can ping with a specific DSCP value set to isolate my pings from anyone elses, looking into the reported issue of 8.8.8.8 latency, then apply a filter to tcpdump on my mirrored port that matches ICMP traffic to a specific IP, with a specific DSCP value, inside specific L3 VPN (specific MPLS labels) etc.
sudo tcpdump -nlASX -s 65535 -vvv -i eth3 '(mpls 52634 and (ip and (ip[1] & 0xfc) >> 2 > 0x01) and host 11.22.33.44 and icmp)'
I mostly make notes for myself, so no need for an about page, I'm the target audience. Someone else might find the info useful which is why it's publically visible, but I'm mainly writing for myself, so no contact or comments. If you want to contact me, jwbensley /at/ gmail /dot/ com. Or Google this username, I just did, you'll find me on GitHub, LinkedIn, StackExchnage and many other places.
Try dumpcap [0], also part of the Wireshark suite. It's the back-end engine used by the Wireshark GUI as well as tshark.
tshark tracks state for streams the same way the GUI will and eats your RAM, whereas dumpcap is a dumb siphon (with filtering).
Reading through a long man page in terminal to get to el' result and then find and use cmd extensions. vs 2s google "how to inurl: tcpdump http packet"
Tshark (nee Wireshark) I believe does decode packet fragments into streams, and allows you to use more advanced Wireshark protocol filters. My suggestion is to start a pcap capture, and at the same time replay it using Tshark with the filters you want. This way you can re-analyze the same live traffic both now and later.