Date: Thu, 30 Nov 2000 14:29:26 -0800 (PST) From: Guy Harris <guy@netapp.com> To: Stanley.Hopcroft@ipaustralia.gov.au Cc: rowan@sensation.net.au, freebsd-isp@freebsd.org Subject: Re: tcpdump & user-ppp/tunX. Ethereal ? Message-ID: <200011302229.OAA16145@tooting.eng.netapp.com>
next in thread | raw e-mail | index | archive | help
> I am writing to say that ethereal (http://www.zing.org aka > http://www.ethereal.com/) is a very nice seven layer packet decoder > that may be suitable if you need nasty link layer stuff. > > There is a FreeBSD port of it, and while for my moneys worth, tcpdump > with ASCII decode patches (he he), Note that at least some ASCII display is done by the current version of tcpdump in CVS - see http://www.tcpdump.org/ (nightly snapshots of the CVS source are available from there as tarballs). I forget whether the most recent tcpdump.org release (3.5.2) has it or not. As for the original question that started this thread: The "-e" flag isn't a "show packet size" option, it's a "show the link-level header" options; from the man page (this is the tcpdump 3.4 man page, but others should say the same thing): -e Print the link-level header on each dump line. At least in the FreeBSD 3.4 source, the "tun" devices register themselves with BPF as DLT_NULL devices. Tcpdump 3.4's link-layer print header for DLT_NULL does *nothing* if "-n" is specified, so the options in the example: velvet# tcpdump -qenli tun0 will cause "-e" to do nothing. The *PPP* link-layer printer in the FreeBSD 3.4 source appears to print a packet length, when "-e" is used, for "BSD/OS PPP", but you'd only see that, I suspect, on, well, BSD/OS. I don't see any indication that it would print the length on "standard" PPP, but I may have missed something. For some other link-layers, e.g. Ethernet, the "-e" flag does cause a link-layer header, plus the packet length, to be printed. Another problem is that "tunX" devices being DLT_NULL will confuse tcpdump if the link-layer header isn't 4 bytes of AF_ value specifying the protocol used by the payload; if, for example, it's a PPP header, tcpdump will probably get greatly confused in other ways. A while ago, I put a hack into Ethereal to cause it not to trust that DLT_NULL captures have an AF_ type as the link-layer header, and to check for what appears to be a PPP header and, if it finds it, treat the capture as a PPP capture. If Ethereal, when capturing on a tunX device, reports the packet size correctly, but tcpdump doesn't, that's probably the source of the problem; tcpdump is probably just completely confused about the type of packets it's seeing. I still have a capture of that sort which I got when the DLT_NULL-capture-with-PPP-header problem was reported on one of the Ethereal mailing lists (that being what provoked the addition of the aforementioned hack); I shall look into putting an equivalent hack into tcpdump, sigh (it'd show up in the current CVS version). (It might be Really Nice if there were, say, an "ioctl" that could be done on "tunX" devices to set the DLT_ type of the device to something other than DLT_NULL, and if programs using it for, say, user-mode PPP set the DLT_ type appropriately.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011302229.OAA16145>