NetBSD Problem Report #5228

Received: (qmail 387 invoked from network); 29 Mar 1998 09:08:10 -0000
Message-Id: <199803290907.BAA00812@mbw.placo.com>
Date: Sun, 29 Mar 1998 01:07:19 -0800 (PST)
From: monroe@pobox.com
Reply-To: monroe@pobox.com
To: gnats-bugs@gnats.netbsd.org
Subject: libpcap doesn't correctly identify EtherTalk packets
X-Send-Pr-Version: 3.95

>Number:         5228
>Category:       lib
>Synopsis:       libpcap doesn't correctly identify EtherTalk packets
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 29 01:20:01 +0000 1998
>Closed-Date:    Sat Aug 12 02:04:44 +0000 2017
>Last-Modified:  Sat Aug 12 02:11:13 +0000 2017
>Originator:     Monroe Williams
>Release:        NetBSD-current supped on March 17, 1998
>Organization:
	None
>Environment:
	Macintosh SE/30
	NetBSD-1.3.1 or -current
	mac68k
System: NetBSD archaeopteryx 1.3.1 NetBSD 1.3.1 (GENERICSBC) #0: Mon Mar 16 23:13:18 CST 1998 scottr@fx1:/amd/polka/a/src/sys/arch/mac68k/compile/GENERICSBC mac68k


>Description:
	bpf-programs generated by libpcap for keyword 'atalk' don't match EtherTalk
	phase II packets.

>How-To-Repeat:
	Use 'tcpdump atalk' on an ethernet segment with known EtherTalk phase II traffic.
	Note that it isn't dumped.

>Fix:
	Apply the following patch to /src/lib/libpcap/gencode.c:


*** gencode.c.orig	Fri Mar 27 01:55:17 1998
--- gencode.c	Sun Mar 29 00:44:02 1998
***************
*** 140,145 ****
--- 140,146 ----
  static void backpatch(struct block *, struct block *);
  static void merge(struct block *, struct block *);
  static struct block *gen_cmp(u_int, u_int, bpf_int32);
+ static struct block *gen_cmp_gt(u_int, u_int, bpf_int32);
  static struct block *gen_mcmp(u_int, u_int, bpf_int32, bpf_u_int32);
  static struct block *gen_bcmp(u_int, u_int, const u_char *);
  static struct block *gen_uncond(int);
***************
*** 401,406 ****
--- 402,425 ----
  }

  static struct block *
+ gen_cmp_gt(offset, size, v)
+ 	u_int offset, size;
+ 	bpf_int32 v;
+ {
+ 	struct slist *s;
+ 	struct block *b;
+ 
+ 	s = new_stmt(BPF_LD|BPF_ABS|size);
+ 	s->s.k = offset;
+ 
+ 	b = new_block(JMP(BPF_JGT));
+ 	b->stmts = s;
+ 	b->s.k = v;
+ 
+ 	return b;
+ }
+ 
+ static struct block *
  gen_mcmp(offset, size, v, mask)
  	u_int offset, size;
  	bpf_int32 v;
***************
*** 619,624 ****
--- 638,677 ----
  		}
  		break;

+ 	case DLT_EN10MB:
+ 		switch(proto) {
+ 		case ETHERTYPE_ATALK:
+ 		case ETHERTYPE_AARP:
+ 			/* EtherTalk (AppleTalk protocols on Ethernet link layer) 
+ 				may use 802.2 encapsulation.
+ 			*/
+ 
+ 			/* Check for 802.2 encapsulation (EtherTalk phase 2?) */
+ 			b0 = gen_cmp_gt(off_linktype, BPF_H, 1500);
+ 			gen_not(b0);
+ 
+ 			/* The following compares the entire contents of the 802.2 LLC and
+ 				SNAP headers in one go.  For the LLC, we check that DSAP = 0xAA,
+ 				SSAP = 0xAA, and cntl = 0x03.  The 5-byte SNAP needs to be
+ 				0x080007809B for ETHERTYPE_ATALK and 0x00000080F3 for ETHERTYPE_AARP.
+ 				Yes, this means that EtherTalk packets use a non-zero org code.
+ 			*/
+ 			if(proto == ETHERTYPE_ATALK) {
+ 				b1 = gen_bcmp(14, 8, "\xAA\xAA\x03\x08\x00\x07\x80\x9B");
+ 			}
+ 			else { /* proto == ETHERTYPE_AARP */
+ 				b1 = gen_bcmp(14, 8, "\xAA\xAA\x03\x00\x00\x00\x80\xF3");
+ 			}
+ 			gen_and(b0, b1);
+ 
+ 			/* Check for Ethernet encapsulation (Ethertalk phase 1?) */
+ 			b0 = gen_cmp(off_linktype, BPF_H, (bpf_int32)proto);
+ 
+ 			gen_or(b0, b1);
+ 			return b1;
+ 		}
+ 		break;
+ 
  	case DLT_NULL:
  		/* XXX */
  		if (proto == ETHERTYPE_IP)
***************
*** 998,1004 ****
--- 1051,1059 ----
  		bpf_error("link layer applied in wrong context");

  	case Q_ATALK:
+ 		b0 =  gen_linktype(ETHERTYPE_AARP);
  		b1 =  gen_linktype(ETHERTYPE_ATALK);
+ 		gen_or(b0, b1);
  		break;

  	case Q_DECNET:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: itojun 
State-Changed-When: Thu May 23 22:54:17 PDT 2002 
State-Changed-Why:  
tcpdump has been upgraded multiple times.  did the problem addressed? 

From: "Perry E. Metzger" <perry@piermont.com>
To: monroe@pobox.com
Cc: gnats-bugs@gnats.netbsd.org, itojun@itojun.org, perry@piermont.com
Subject: Re: lib/5228
Date: 04 Apr 2003 12:19:51 -0500

 >Synopsis:       libpcap doesn't correctly identify EtherTalk packets

 Hi there...

 Is this PR still an issue, or does libpcap in current correctly deal
 with EtherTalk?

 Perry

From: Monroe Williams <monroe@pobox.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: <gnats-bugs@gnats.netbsd.org>, <itojun@itojun.org>
Subject: Re: lib/5228
Date: Fri, 04 Apr 2003 10:13:07 -0800

 on 4/4/03 9:19 AM, Perry E. Metzger at perry@piermont.com wrote:

 > 
 >> Synopsis:       libpcap doesn't correctly identify EtherTalk packets
 > 
 > Hi there...
 > 
 > Is this PR still an issue, or does libpcap in current correctly deal
 > with EtherTalk?

 Wow.  Did I really submit that one five years ago?

 I just tried this on a NetBSD-macppc system running 1.6 with a 1.6P -current
 kernel, and it looks like it never got fixed.

 If I run 'tcpdump not ip' and generate appletalk traffic to the machine
 (specifically, open the "connect to" file sharing browser on a Mac OS X box
 on the local network), it shows up as:

 10:05:19.653714 255.145.248.253 > 0.0.nis: nbp-lkup 27: "=:AFPServer@*"
 10:05:19.653934 255.0.94.nis > 255.145.248.253: nbp-reply 27:
 "macppc:AFPServer@*"(0) 128
 10:05:19.653945 255.145.248.253 > 0.0.nis: nbp-lkup 28: "=:AFPServer@*"
 10:05:19.654014 255.0.94.nis > 255.145.248.253: nbp-reply 28:
 "macppc:AFPServer@*"(0) 128

 If I run 'tcpdump atalk' and generate the same traffic, tcpdump shows
 nothing.

 -- monroe
 ------------------------------------------------------------------------
 Monroe Williams                                         monroe@pobox.com


From: "Perry E. Metzger" <perry@piermont.com>
To: Monroe Williams <monroe@pobox.com>
Cc: gnats-bugs@gnats.netbsd.org, itojun@itojun.org, perry@piermont.com
Subject: Re: lib/5228
Date: 04 Apr 2003 13:23:27 -0500

 Monroe Williams <monroe@pobox.com> writes:
 > on 4/4/03 9:19 AM, Perry E. Metzger at perry@piermont.com wrote:
 > >> Synopsis:       libpcap doesn't correctly identify EtherTalk packets
 > > 
 > > Is this PR still an issue, or does libpcap in current correctly deal
 > > with EtherTalk?
 > 
 > Wow.  Did I really submit that one five years ago?
 > 
 > I just tried this on a NetBSD-macppc system running 1.6 with a 1.6P -current
 > kernel, and it looks like it never got fixed.

 Okay, could I request that you clean up your patches so that they
 apply to the latest tcpdump.org sources and submit them to
 tcpdump.org? Itojun can make sure the patches are applied there, and
 we will then import a new version from tcpdump.org some time soon.

 Perry

From: "Charles M. Hannum" <abuse@spamalicious.com>
To: Monroe Williams <monroe@pobox.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/5228: libpcap doesn't correctly identify EtherTalk packets
Date: Tue, 6 Jul 2004 07:47:54 +0000

 FWIW, if you update the AppleTalk patches for current libpcap, I will 
 personally commit them.
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 27 Mar 2008 15:03:00 +0000
State-Changed-Why:
Feedback timeout. Looks like the submitter isn't going to deal with this,
but it would be best to adopt the patch anyway - anyone else want to try
merging it into current libpcap?


State-Changed-From-To: open->closed
State-Changed-By: ginsbach@NetBSD.org
State-Changed-When: Sat, 12 Aug 2017 02:04:44 +0000
State-Changed-Why:
It appears that libpcap has had the capabilithy to handle EtherTalk packets
since Monroe Williams (the Originator of the PR) submitted similar changes
to tcpdump/libpcap some 17+ years ago.  It is safe to close as NetBSD has
since updated to a newer version of libpcap.
(See https://github.com/the-tcpdump-group/libpcap/commit/54b2ab13c29b96c9d587a0fb348ae8a1caccf08f)


>Unformatted:

Home	PR Database Search