the other fields don't print 'field: value' so don't here either.
Index: print-ip.c
===
RCS file: /tcpdump/master/tcpdump/print-ip.c,v
retrieving revision 1.155
diff -u -r1.155 print-ip.c
--- print-ip.c 19 Feb 2006 05:00:19 -
Hi,
> Will we be able to capture twice as few packets (hopefully not)? I was
> hoping to kinda avoid the need to do this test if anyone has already did
> some sort of evaluation...
Complex filters are cheap in terms of capturing performance. For a
detailed examination take a look at:
http://
Dmitry Rubinstein wrote:
Greetings, everyone!
We are trying to capture stuff using a relatively simple filter (on
Linux, using Phil Wood's PCAP with ssldump on top of it). What we want
is basically to capture the traffic to and from a specific port of a
specific host (say, 10.0.0.1:80). So far
Greetings, everyone!
We are trying to capture stuff using a relatively simple filter (on
Linux, using Phil Wood's PCAP with ssldump on top of it). What we want
is basically to capture the traffic to and from a specific port of a
specific host (say, 10.0.0.1:80). So far we did it using the filter
Kevin Steves wrote:
this eliminates extra leading space for DNS dissector.
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
on Mon 1/15/2007 10:32 AM Guy Harris wrote:
> > (So, if this is the way, I can update the wireshark dissector accordingly).
> The dissector would assume that the packet header is in host byte order,
> which it will automatically be when doing a live capture, and which the
> libpcap_read() and
Abeni Paolo wrote:
1) the host reading a capture file can determine the byte order of the
host on which the capture was done,
I did not know this. Can you plase explain me how ?
The file header in a libpcap file starts with a magic number to indicate
that it's a libpcap file; the magic numb
