Re: [tcpdump-workers] (another) bug in the BPF compiler (wireless)
Hi, On 26 Nov 2007, at 19:05, Gianluca Varenni wrote: I don't know what the status of the libpcap 1.0/tcpdump 4.0 release is, but I'd like to hold on the release for a day or so. I've just found (another) bug in the BPF compiler for wireless link types. A simple filter like "link src host 11:22:33:44:55:66" seems to discard all the packets. Although I do not know much about wireless but in ethernet this would be source multicast, which is prohibited. Kind regards, Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] patch: Allow various ethernet address notations
Greetings, Attached is a small patch which makes libpcap filter expressions a bit more tolerant towards ethernet (MAC) address notations. When troubleshooting network problems, me and my colleagues often want to cut-and-paste MAC addresses as displayed by network equipment. However, modern equipment show addresses in notations that are not accepted in libpcap filter expressions. Changing the notation each time is trivial but annoying. It seems unlikely that we are the only ones doing this. Therefore we would like to propose this patch. With this patch the following notation forms are accepted as valid addresses: \1 xx:xx:xx:xx:xx:xx \2 .. \3 xx-xx-xx-xx-xx-xx \4 xx.xx.xx.xx.xx.xx \5 \1 is the common notation; \2 is the Cisco-like notation, as used by many equipment vendors; \3 seems preferred by the IEEE and in many books. While testing this patch, I discovered that Debian applies a similar, independently developed, patch just to allow notations \4 and \5. Please review this patch and consider it for some future release. If needed, I can make a patch for CVS HEAD. The same diff was uploaded to sourceforge. Kind regards, Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] patch: Allow various ethernet address notations
On 7 Jan 2008, at 16:37, Joerg Mayer wrote: On Mon, Jan 07, 2008 at 03:13:32PM +0100, Arien Vijn wrote: Attached is a small patch which makes libpcap filter expressions a bit more tolerant towards ethernet (MAC) address notations. Did you use invisible ink^H^H^Hpixels in the attached patch? Not sure what you mean exactly. I guess the file did not come through in good order? You may want to download it from SourceForge or from here: http://www.ams-ix.net/~arien/macnotation-0.9.8.diff I just tried it from there and it works for me. \3 seems preferred by the IEEE and in many books. The '-' notation should be used by all media that use the Ethernet bit order, TR should use ':' - at least if I interpreted the IEEE correctly. Well, it seems that hardly anyone knows that (or that I'm imagining things of course :-) I for one, did not know that but it seems another reason for this patch :) Thanks, Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump and wireshark
On 15 sep 2008, at 23:05, Dmitry wrote: Hello. I'm interesting in info extraction from pcap dumps. Recently I did some test dump of downloaded picture with tcpdump and wrote it to file 'dump.pcap'. Test zero: I have started capture on 192.168.0.1 host and did http request of image to 192.168.0.2 Nothing else dropped to dump except arp requests etc. Test one: I've opened dump with wireshark. Found stream, filtered it out and saved raw data to file 'dump.hex' Deleted HTTP request till \xff byte before JFIF header and got image. Test two: I've processed dump thru tcpdump in command-line manner $> tcpdump -nn -r dump.pcap src host 192.168.0.2 and src port 80 and dst host 192.168.0.1 and dst port 50713 -w dump.hex Deleted HTTP request till \xff byte before JFIF header and got wrong image. So, there I've got in trouble. What I'm doing wrong with tcpdump? Snap length I guess. Tcpdump's default is 68 bytes. Try the parameter: "-s 0" to capture the whole packet. I believe that tshark captures the entire packet by default. -- Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] the capture layer about tcpdump,more info
Hello, Just a suggestion. It might be that the NIC you use to capture processes the pause frame and does not put it through to the bus. You might want to try to switch flow control off on the NIC and see what happens then. This under the assumption that the pause frames actually hit your capture NIC. It is not impossible or so, I did capture pause frames with tcpdump. Cheers, Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] question about -E parameter decrypting esp packets
On 20 Feb. 2009, at 10:29 AM, Torsten Krah wrote: Am Freitag, 20. Februar 2009 02:35:04 schrieb Michael Richardson: First, are you capturing the entire packet? Hm what do you mean with "entire" packet? How do i know this? The command i have used i told - have i have to do something more to get the entire dump? The snap length is set to 68 bytes by default on most OSes. That is enough to capture IP, ICMP, TCP and UDP. To capture the whole frame you need to run with: -s 0. -- Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Should the default snapshot length in tcpdump be 65535?
On 5 Mar. 2009, at 10:20 AM, Guy Harris wrote: Would it make sense to have tcpdump default to the maximum snapshot length, rather than 68 (without IPv6 support) or 96 (with IPv6 support)? I've checked in a change to make the default snapshot length 65535. Suddenly* changing this default may couse some inconveniences for those who use tcpdump in scripts to archive and/or process headers only. People may not expect a full packtet from tcpdump after all these years. Short snap lengths may be wanted because of legal reasons or because the payload is just not interesting. Therefore it would be a good idea to make this an option during compile time. The default should be what it always was until at least the next major version (5.0.0). Just my thoughts for what they are worth without code :) -- Arien * from an enduser perspective. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Should the default snapshot length in tcpdump be 65535?
On 10 Mar. 2009, at 2:01 AM, Eloy Paris wrote: On Mon, Mar 09, 2009 at 11:52:50PM +0100, Arien Vijn wrote: Therefore it would be a good idea to make this an option during compile time. Hmmm. Wouldn't this be a bit overkill? And even if we went down this path, I don't think that recompiling with the option to revert to the shorter snapshot length by default will be that much easier for administrators than editing legacy scripts to add "-s 68" to tcpdump invokations. I meant it the other way around :) I suggested to leave the defaults to what they are. From experience I know that changing defaults are often not appreciated by the many administrators with lots of things on their minds. For those who don't like to type "-s 0" it would be nice to have the option to get rid of that under compile time. Things should not be static for ever though. IMO the default can be changed in the next major release (5), not in any 4.x.x release. Cheers, Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] deduct local IPs from pcap-files, possible?
Hi Andrej, On 20 May 2010, at 04:05, Andrej van der Zee wrote: > Hi, > > Sorry for asking again, but I got no useful answer last time. Hopefully more > luck this time... > > I receive many pcap-files from our clients. Now I am constructing an > algorithm using libpcap that deducts time differences between the servers by > matching packets on both ends of the connection and comparing timestamps > (neglecting latencies). Every server produces one pcap-file that listens to > all interfaces of the local machine. I found a way to calculate the time > differences between the IPs, but I cannot tell if a particular server is > ahead or behind in time. To be able to do this, I need to deduct the local > IPs that belong to the server that produced the pcap-file. The "problem" is > that on a particular server all incoming and outgoing packets are sniffed, > hence the local IPs will appear as "src" and "dst" in the IP-packets. I am > looking for a way to deduct the local IPs anyway, but need a push in the > right direction (if it is possible at all). I guess you can look at the MAC addresses. The MAC address that is in all frames is the address of the NIC from which that file was generated. The corresponding IP address(es) is/are the IP address(es) of that server. If you are sure that all NICs have only one IP address configured and no addresses can be spoofed, then you can do the same for IP addresses. Perhaps you don't need to parse all frames, it might be enough to even parse frames until you have a frame with the same source and a destination address. If the servers communicates with one other MAC/IP address, then the method above won't work. At any rate, there is no header that contains the local address. Hence you have to resort to heuristics. -- Arien - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] ipv6 DAD packets?
On 3 Mar 2011, at 9:52 PM, Jeff Sadowski wrote: > On Thu, Mar 3, 2011 at 1:31 PM, Eloy Paris wrote: >> On 03/03/2011 02:48 PM, Jeff Sadowski wrote: >> >> [...] >> >>> I tried "tcpdump ip6 and icmp" but it says im blocking all. How would >>> I do what I am trying to do? >>> I can't quite figure out tcpdump syntax. >> >> "tcpdump icmp6", per pcap-filter(7), does not do what you need? >> > with -vv it shows the mac but Is there a way to put the full packet > all on one line that I can parse the output easier Not that I know. The -e option shows the link layer addresses at the same dump line though. Perhaps you can use that. -- Arien smime.p7s Description: S/MIME cryptographic signature
Re: [tcpdump-workers] One of these things is not like the others
> On May 24, 2017(21), at 21:23, Michael Richardson wrote:
>
> Guy Harris wrote:
>>> Guy Harris wrote:
>>>
Note that macOS's tcpdump has a -g flag ("g" for "greppable", more
greppable output being the purpose of the flag), which puts the IPv4
input back on one line:
>>>
>>> How can we move to this format?
>
>> To make that the default and only format, we'd just have to turn
>
> Yes... but are we going to screw people over with this change?
Most likely yes.
>> To add support for the -g flag, we'd just make that conditional at run time,
>> with a gflag field in the netdissect_options field.
>
> I'm thinking, can we just make it the default?
It is likely that textual output is being parsed by scripts in many many
places. Those scripts may not work properly anymore when you change the
default.
I think that it is best to keep the current behaviour and make the output that
is easier parsable optional with the -g flag.
— Arien
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
