From owner-freebsd-hardware Fri Jan 29 17:36:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21873 for freebsd-hardware-outgoing; Fri, 29 Jan 1999 17:36:53 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21850; Fri, 29 Jan 1999 17:36:46 -0800 (PST) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id UAA16694; Fri, 29 Jan 1999 20:36:35 -0500 (EST) Message-ID: <19990129203635.A13393@netmonger.net> Date: Fri, 29 Jan 1999 20:36:35 -0500 From: Christopher Masto To: Bill Paul Cc: fenner@parc.xerox.com, current@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Network/ARP problem? Maybe pn driver? References: <19990129180612.C3237@netmonger.net> <199901292328.SAA26781@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199901292328.SAA26781@skynet.ctr.columbia.edu>; from Bill Paul on Fri, Jan 29, 1999 at 06:28:46PM -0500 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 29, 1999 at 06:28:46PM -0500, Bill Paul wrote: > > Hmm. Running tcpdump seems to make the problem go away. The ARP > > replies show up immediately appear in the table. Clue. > > You should have tried that first. I'm sorry. I ran tcpdump on a different host precisely because I didn't want to interfere with the problem and make it harder to debug. I overlooked the obvious. > There's something I'd like you to try for me. (Don't delay in trying > this; I've had a long string of people who appear suddenly, complain > about a problem of some sort, then vanish before I can extract enough > information from them to find a solution.) I have been active with FreeBSD for the past four years. I have not appeared suddenly, nor do I intend to vanish. The delay in responding to your message is solely a result of a dinner party I had to attend. > I was menaced by a bug in the PNIC's receive DMA operation which, according > to all my tests, only appeared in promiscuous mode. I devised a workaround, > however it's only enabled when the IFF_PROMISC flag is set on the > interface. Running tcpdump (without the -p flag) places the interface > in promiscuous mode and enables the workaround. Given what you've said, > it's possible that we need to enable the workaround all the time, not > just in promiscuous mode. I would say you're quite right, considering the result of tcpdump -n -p arp: 20:32:36.302468 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:36.303175 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:37.310842 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:37.311563 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:38.320858 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:38.321579 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:39.330866 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:39.331600 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:40.340883 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:40.341581 arp who-has 209.54.21.129 tell 209.54.21.233 Run again without -p, and voila: 20:33:30.232549 arp who-has 209.54.21.129 tell 209.54.21.233 20:33:30.233301 arp reply 209.54.21.129 is-at 0:e0:b0:e2:bc:79 > Do me the following: > > - Bring up /sys/pci/if_pn.c in your favorite editor. [...] > Compile a new kernel with this change and see if the problem persists. > Report back your findings (one way or the other) so that I'll know if > I should modify the code in the repository. I will have the results for you by tomorrow. Thank you very much for your assistance. -- Christopher Masto Director of Operations NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net "Good tools allow users to do stupid things." -- Clay Shirky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message