Date: Sun, 3 Dec 2000 21:32:00 -0800 From: Guy Harris <gharris@flashcom.net> To: Stanley.Hopcroft@ipaustralia.gov.au Cc: rowan@sensation.net.au, freebsd-isp@freebsd.org Subject: Re: tcpdump & user-ppp/tunX. Ethereal ? Message-ID: <20001203213200.I349@quadrajet.flashcom.com>
next in thread | raw e-mail | index | archive | help
> 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. ... > 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). A quick look at the FreeBSD 3.4 code, at least, suggests that the link-layer header will be 4 bytes of AF_ value with the "tunX" devices, so tcpdump should have no problem dissecting those packets. No tcpdump hack should be necessary (unless something *else* will still cause those DLT_NULL-capture-with-PPP-header captures to show up; I think it was an ISDN capture), and the "ioctl" to which I referred: > (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.) shouldn't be necessary. The reason for the lack of any packet length when the "-e" option was used presumably is, as per my previous mail, the fact that, for DLT_NULL (and DLT_PPP), the link-layer header information that tcpdump prints with "-e" doesn't, for better or worse, include the packet length. As for why it the length showed up on PPP devices in 2.2.8R but not 3.4R, the answer to the question > has something major changed with the ppp/tun device structure, BPF, or > tcpdump since 2.2.8R? is "yes" - revision 1.2.2.1 of "print-ppp.c" in tcpdump, which is tagged with RELENG_2_2_8_RELEASE, printed the length when the "-e" flag is specified, but, in revision 1.6, that stuff was removed (see PR 7741, which includes a new version of "print-ppp.c" that didn't print the length), and 1.7.2.2 was the revision in 3.4R. I'll check to make sure that the version in the tcpdump.org CVS tree prints the length, and, if, as, and when that gets picked up by FreeBSD, the length will be back, at least for PPP. (I'll also look at putting it for DLT_NULL, which should make it show up for the "tunX" devices.) 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?20001203213200.I349>