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
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
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
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
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
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
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
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
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
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
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.
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
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
13 matches
Mail list logo
