This is not a tethereal bug, but this is the way tethereal and ethereal
work.
The issue is that the "http" display filter will only match the packets
where Ethereal could find a match for "http"; this includes packets where
the HTTP message is contained in one single packet, or also *the last
packet* of a reassembled buffer that matches "http". In the latter case the
"http" display filter will not match the packets that were *not* the last of
a fragmented HTTP message spanning more than one packet.
Should you want to redissect a filtered capture, you need to make sure you
save sufficient packets required for preserving the dissection state. Today
it is not possible to specify a display filter for this.
Regards,
Olivier
|-----Original Message-----
|From: Jonas Åberg
|
|Hi,
|
|I've been capturing some data and later used tethereal to
|remove none http traffic form the captured data. However,
|teathereal remove abit too much from one (atleast) http
|transfer. The HTTP header is gone.
|
|I produced the bug this way:
| - starting ethereal capture until 32 mb reached.
|
|wget -r -l 3 www.svd.se
|
| - saved it in "sniffer 2.00x" format. (If I load the file
|again in ethereal and take follow tcpflow the bad transfer looks fine.)
|
|- After saving I ran:
|
|tethereal -F libpcap -r "large.sniff" -w
|"/tmp/dmm-capture-tmp.pcap" -R "http" -d "tcp.port==3128,http"
|
|(with libpcap 0.8.3 - Transfered over a squid proxy on 3128)
|loaded /tmp/dmm-capture-tmp.pcap again and looked at the same
|stream stream and parts of the http header was gone. I've used
|tcpflow 0.21 also, and it also produces atleast one flauty
|http package, so it isn't "follow tcp stream" that has problems.
|
|I have cut of the error below, however, I guess you can't make
|much out of it. I'll keep the captured data that is on around
|32mb, and if wished I can transfer it to anyone.
|
|Best regards,
| Jonas