From owner-freebsd-current Sun Feb 7 15:15:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA02367 for freebsd-current-outgoing; Sun, 7 Feb 1999 15:15:52 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from niobe.ewox.org (ppp035.uio.no [129.240.240.36]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02303; Sun, 7 Feb 1999 15:15:37 -0800 (PST) (envelope-from des@niobe.ewox.org) Received: (from des@localhost) by niobe.ewox.org (8.9.2/8.9.1) id AAA68765; Mon, 8 Feb 1999 00:16:14 +0100 (CET) (envelope-from des) To: wpaul@FreeBSD.ORG Cc: nsouch@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Regarding tcpdump and plip In-Reply-To: From: Dag-Erling Smorgrav Date: 08 Feb 1999 00:16:13 +0100 Message-ID: <86n22pg5z6.fsf@niobe.ewox.org> Lines: 68 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moving over to -hackers...] As I mentioned in earlier correspondance on -current, tcpdump is broken wrt plip connections. The reason for this is that, as I read the code in src/contrib/libpcap/gencode.c, libpcap expect DLT_NULL- type interfaces to produce a four-byte header with the link type in the first two bytes, whereas the PLIP driver produces a two-byte header consisting solely of the link type. The obvious fix is to patch src/sys/dev/ppbus/if_plip.c to announce and use a four-byte header as libpcap expects it to do; I have attached an untested patch which does this. I'm not sure it's the *correct* fix, however, and I have a hunch that it's only a partial fix since it seems that the plip code does not construct a header for incoming packets - if I am correct, then even with the attached patch tcpdump will only show outgoing packets correctly. I'll toy around with it a little to see if I can confirm or deny my hunch, and/or fix it to work in all cases. On a related note, I was rather surprised, when browsing through the ppbus code, to discover that it is based on an older version of the parallell port code than what was then (and is still) in -CURRENT. What caught my attention was that src/sys/dev/ppbus/nlpt.c still uses the old probe code, instead of the new one I wrote about a year ago, which was integrated in revision 1.66 of src/sys/i386/isa/lpt.c on 1998/02/20. There may be other differences as well, but I did not look too closely. Also, the plip code still causes regular panics. I haven't caught a dump yet because my dump device was misconfigured, but I've had at least two plip-related panics on an otherwise perfectly stable system in the last two weeks. I'll send a backtrace as soon as I have one. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: if_plip.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ppbus/if_plip.c,v retrieving revision 1.9 diff -u -r1.9 if_plip.c --- if_plip.c 1999/01/30 15:35:39 1.9 +++ if_plip.c 1999/02/07 22:31:42 @@ -123,7 +123,7 @@ #define CLPIP_SHAKE 0x80 /* This bit toggles between nibble reception */ #define MLPIPHDRLEN CLPIPHDRLEN -#define LPIPHDRLEN 2 /* We send 0x08, 0x00 in front of packet */ +#define LPIPHDRLEN 4 /* We send 0x08, 0x00, 0x00, 0x00 in front of packet */ #define LPIP_SHAKE 0x40 /* This bit toggles between nibble reception */ #if !defined(MLPIPHDRLEN) || LPIPHDRLEN > MLPIPHDRLEN #define MLPIPHDRLEN LPIPHDRLEN @@ -743,11 +743,11 @@ * try to free it or keep a pointer to it). */ struct mbuf m0; - u_short hdr = 0x800; + u_char hdr[4] = { 0x08, 0x00, 0x00, 0x00 }; m0.m_next = m; - m0.m_len = 2; - m0.m_data = (char *)&hdr; + m0.m_len = 4; + m0.m_data = (char *)hdr; bpf_mtap(ifp, &m0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message