laavid.blogg.se - Wireshark linux magic pipe error

This is an especially quick and dirty method of course you could pipe in multiple status codes, or use egrep and a regex, but from the CLI you run a pretty big risk of missing something. # tcpdump -i eth0 -pnA port 80 | grep '404\|GET' If you are just interested in the negative status codes, you of course can just pipe the output to grep: Many firewalls can filter this stuff out at the edge, but this a job best suited to a load balancer or Application Delivery controller (posh load balancer). Random clients attempting to request executables is of course an example of virus or other malicious activity. This time, the client is requesting reallybadfile.exe so the server returns a 404 Not Found error. However, changing things just to troubleshoot is never a good idea and that wouldn't help if your problem is with gzip compression.Īnother example shows a less than healthy connection: As a workaround, you could disable compression on your browser, or use a CLI web tool such as cURL.

There *may* be an arcane way of getting tcpdump to decompress gzip on the fly, but I’ll be darned if I can figure it out. However, from just the tcpdump we can’t see that.

Somewhere in this packet exchange, a redirect sends the client to a different TCP port.

The parameters/session features enabled (such as gzip compression).

The server was happy to accept the request.

You can’t see the conversation between the client and server once the TCP and HTTP parameters are established. Whilst the sessions is not encrypted with gzip compression enabled, for a human it may as well be. The clue is in the client and server headers. Beyond that, it’s HTML:īut, that doesn't look anything like HTML. Various other headers are displayed, but they not usually that useful.

The server HTTP 200 return code (HTTP/1.1 200 OK).

The HTTP GET request from the client (GET / HTTP/1.1).

Probably the most interesting parts are highlighted in yellow After a few packets we can see the client's request, the ACK, and the server’s response. To kick of a capture on our server we run:įor sanity’s sake I've snipped out the initial handshake. The most useful switch for debugging http is -A, which decodes the traffic in ASCII format, which kinda makes it human readable. Whilst you *can* definitely do some analysis of HTTP, as we’ll see, once the initial handshake is complete, it gets messy, real quick. So, how far can we take troubleshooting with tcpdump? Well pretty far but in troubleshooting you have to decide whether the fastest resolution will come from the tools you have to hand or grabbing the capture and using something better. In my last post, I took a look the DNS protocol with tcpdump and as it turns out you can do some really useful stuff with the embedded protocol decoders.