Re: Network/ARP problem? Maybe pn driver?
Stefan Esser writes: You could have blocked reception of ARP requests / ARP replies in your IPFW rules on one of the systems involved. Just try again with a completely open FYI- There's no way to block ARP packets with ipfw... it only deals with IP packets. er... if you use bridging and enable ipfw on bridged packets (net.link.ether.bridge_ipfw=1) then you can block non-ip packets if you don't use an open firewall. I don't think the original poster is in this situation that's why i did not spoke before. cheers luigi ---+- Luigi RIZZO . EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Yust a wild guess: You could have blocked reception of ARP requests / ARP replies in your IPFW rules on one of the systems involved. Just try again with a completely open configuration (a pass all as rule 1 should work). That would explain that other systems can learn the ARP address as soon as they have received IP packets, but they can't get at the ARP address by querying for it ... Regards, STefan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 06:28:46PM -0500, Bill Paul wrote:
- Change the if() clause so that it looks like this:
if (sc-pn_promisc_war /* ifp-if_flags IFF_PROMISC*/) {
(In other words, comment out the test for the IFF_PROMISC flag.)
This will enable the workaround all the time and allow the receiver bug
to be detected and handled properly.
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'm sad to say, this didn't solve the problem. It still happens
exactly as before, and still goes away immediately if I run a tcpdump
on another console (but not if I do tcpdump -p).
I did add a printf when pn_promisc_war is set to 1 just to make sure
that it was being properly detected and turned on, and it is.. but
enabling the workaround all the time doesn't seem to help.
--
Christopher MastoDirector of Operations NetMonger Communications
ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net
Good tools allow users to do stupid things. -- Clay Shirky
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Stefan Esser writes: You could have blocked reception of ARP requests / ARP replies in your IPFW rules on one of the systems involved. Just try again with a completely open FYI- There's no way to block ARP packets with ipfw... it only deals with IP packets. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Can you run a tcpdump arp on the machine that is having the problem, as well? This could help to determine if it's a driver problem (e.g. if the replies don't show up) or an ARP problem (e.g. if the replies do show up but arp doesn't use them). Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 02:52:07PM -0800, Bill Fenner wrote: Can you run a tcpdump arp on the machine that is having the problem, as well? This could help to determine if it's a driver problem (e.g. if the replies don't show up) or an ARP problem (e.g. if the replies do show up but arp doesn't use them). Good idea. Hmm. Running tcpdump seems to make the problem go away. The ARP replies show up immediately appear in the table. Clue. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Of all the gin joints in all the towns in all the world, Christopher
Masto had to walk into mine and say:
On Fri, Jan 29, 1999 at 02:52:07PM -0800, Bill Fenner wrote:
Can you run a tcpdump arp on the machine that is having the problem,
as well? This could help to determine if it's a driver problem (e.g.
if the replies don't show up) or an ARP problem (e.g. if the replies
do show up but arp doesn't use them).
Good idea.
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.
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 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.
Do me the following:
- Bring up /sys/pci/if_pn.c in your favorite editor.
- Locate the pn_rxeof() function and find the following code:
#ifdef PN_PROMISC_BUG_WAR
/*
* XXX The PNIC seems to have a bug that manifests
* when the promiscuous mode bit is set: we have to
* watch for it and work around it.
*/
if (sc-pn_promisc_war ifp-if_flags IFF_PROMISC) {
[...]
- Change the if() clause so that it looks like this:
if (sc-pn_promisc_war /* ifp-if_flags IFF_PROMISC*/) {
(In other words, comment out the test for the IFF_PROMISC flag.)
This will enable the workaround all the time and allow the receiver bug
to be detected and handled properly.
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.
-Bill
--
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness
=
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Big Clue. Run tcpdump -p and see if the problem doesn't go away. (tcpdump puts the card in promiscuous mode, tcpdump -p does not). Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 06:02:16PM -0500, Alfred Perlstein wrote: On Fri, 29 Jan 1999, Christopher Masto wrote: I hope I'm not just being really stupid, but I think there's a problem somewhere. If it's a configuration error on my part, then I think I'd better take a vacation, considering what my job is supposed to be. Anyway, I have a machine that is exhibiting a weird network problem. My guess is that ARP is not working, or perhaps something that ARP depends on (broadcasts?) is not working. i didn't see your netmask's, can you show me those please? on the broken box, and on one of the working boxes? Yes, sorry.. I accidentally deleted that part of the message. Here's the broken box: pn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 209.54.21.233 netmask 0xff00 broadcast 209.54.21.255 ether 00:a0:cc:3b:66:51 media: 10baseT/UTP half-duplex supported media: autoselect 100baseTX full-duplex 100baseTX half-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP 10baseT/UTP half-duplex And here's a working one: ep0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 209.54.21.199 netmask 0xff00 broadcast 209.54.21.255 ether 00:60:97:a3:63:e6 The 255.255.255.0 netmask is correct here, despite the router being at .129. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
Christopher Masto writes: Can you run a tcpdump arp on the machine that is having the problem, as well? This could help to determine if it's a driver problem (e.g. if the replies don't show up) or an ARP problem (e.g. if the replies do show up but arp doesn't use them). Good idea. Hmm. Running tcpdump seems to make the problem go away. The ARP replies show up immediately appear in the table. Clue. Tcpdump puts the Ethernet card in promiscuous mode. So perhaps somebody is trying to unicast you something but using the wrong Ethernet address. Could be the local or remote ARP code. Just a guess. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
I hope I'm not just being really stupid, but I think there's a problem somewhere. If it's a configuration error on my part, then I think I'd better take a vacation, considering what my job is supposed to be. Anyway, I have a machine that is exhibiting a weird network problem. My guess is that ARP is not working, or perhaps something that ARP depends on (broadcasts?) is not working. The symptom is, quite simply, that computer A (this new one) is not able to communicate with any other computers.. until those other computers communicate with A. This usually means that you have the netmask wrong, so broadcasts don't work (wrong destination address). When someone else talks to the misconfigured machine, they create an ARP cache entry, which allows the victim to see them (until it times out). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
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 MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
