Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Jan 1999 20:36:35 -0500
From:      Christopher Masto <chris@netmonger.net>
To:        Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc:        fenner@parc.xerox.com, current@FreeBSD.ORG, hardware@FreeBSD.ORG
Subject:   Re: Network/ARP problem?  Maybe pn driver?
Message-ID:  <19990129203635.A13393@netmonger.net>
In-Reply-To: <199901292328.SAA26781@skynet.ctr.columbia.edu>; from Bill Paul on Fri, Jan 29, 1999 at 06:28:46PM -0500
References:  <19990129180612.C3237@netmonger.net> <199901292328.SAA26781@skynet.ctr.columbia.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990129203635.A13393>