My web server logs are telling me that I'm having trouble receiving data from my customers. I want to review the traffic to look for anomalies (lost packets and so forth). The actual traffic is encrypted HTTP, so I don't care about the data beyond the information that should be present in the headers (length, etc). My plan is to run dumpcap, with appropriate arguments, to log data to a file for later analysis. To keep the size of the log file from getting out of control, I'd like to set a packet snapshot length to keep things manageable. What snaplen is appropriate for this use case? asked 06 May '11, 09:29  DanilSuits |
2 Answers:
I totally agree with Jaap, you should check on your network to see what the actual headers look like, there might be vlan tagging, extra TCP options and other stuff enlarging the headers you would like to capture. On a "vanilla" network, you would probably want to capture the Ethernet headers (14 bytes), the IP headers (normally 20 bytes) and the TCP headers (normally 20 bytes). IE 54 bytes should be enough, but values ussually seen as default are 68 bytes or 96 bytes. I tend to use 128 bytes in situations where I do not know what to expect up front. However, I always try to avoid using a snaplength, because many times you start looking at what seems to be a problem at the network or transport layer, that in the end turns out to be a problem at the application layer. I don't want to have to make new traces every time that happens. So if you have the diskspace, use it :-) answered 07 May '11, 02:28  SYN-bit ♦♦ |
Best way to figure that out is to make a sample capture and have a look. answered 06 May '11, 10:21  Jaap ♦ |
Yup, we use 128 byte snaplen as default as well. We're forbidden to take full packet captures (w/o various levels of approval), but I find that in most cases, 128 is enough.