Re: RTM_NEWNEIGH message for static ARP entry

On Wed, 21 Jun 2023, at 5:19 PM, Hartmut Brandt wrote: > Hi, > > when I set a static ARP entry I see an RTM_NEWNEIGH message on a netlink > socket as expected, but the ndm_state is NUD_INCOMPLETE. Should'nt this be > NUD_NOARP? At least this is what Linux returns. Thanks for t

RTM_NEWNEIGH message for static ARP entry

Hi, when I set a static ARP entry I see an RTM_NEWNEIGH message on a netlink socket as expected, but the ndm_state is NUD_INCOMPLETE. Should'nt this be NUD_NOARP? At least this is what Linux returns. Cheers, Harti

vnet/if_bridge: ARP issues: connection failure

ryin again is in 99% then a fail. Once connected the ssh connection fries after a couple of seconds of inactivity. Checking ARP on the jail (login via host and jexec) and listening via tcpdump -XXvi vnet0 arp on a jail while pinging the jail from the netowrk shows up the typical requests, but not eve

Re: arp panic

On 02/04/17 07:43, Chagin Dmitry wrote: chd.heemeyer.club dumped core - see /var/crash/vmcore.8 Sat Feb 4 09:01:35 MSK 2017 FreeBSD chd.heemeyer.club 12.0-CURRENT FreeBSD 12.0-CURRENT #237 r313172+c19dc6ff09(lemul): Fri Feb 3 22:38:44 MSK 2017

arp panic

chd.heemeyer.club dumped core - see /var/crash/vmcore.8 Sat Feb 4 09:01:35 MSK 2017 FreeBSD chd.heemeyer.club 12.0-CURRENT FreeBSD 12.0-CURRENT #237 r313172+c19dc6ff09(lemul): Fri Feb 3 22:38:44 MSK 2017 r...@chd.heemeyer.club:/home/rootobj/home/git/head/sys/YOY amd64 panic: GNU gdb

Re: arp flapping after udating system to 11-CURRENT.

On Thu, Feb 04, 2016 at 03:43:05PM -0800, Roger Marquis wrote: > Slawa Olhovchenkov wrote: > >> It seems to be flapping between the virtual mac of my bridge interface > >> and the actual mac adress on the physical interface. This was not the > >> case when i ran FreeBSD 10.2. Is there some

Re: arp flapping after udating system to 11-CURRENT.

Slawa Olhovchenkov wrote: >> It seems to be flapping between the virtual mac of my bridge interface >> and the actual mac adress on the physical interface. This was not the >> case when i ran FreeBSD 10.2. Is there some settings I need to do? While the documentation says you should assign an IP

arp flapping after udating system to 11-CURRENT.

Hi! I recently upgraded my system to 11-CURRENT (FreeBSD 11.0-CURRENT #0 r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other devices in the network complains about arp-flapping: arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0 arp: 172.25.0.1 moved

Re: arp flapping after udating system to 11-CURRENT.

On Wed, Feb 03, 2016 at 08:31:43AM +0100, Peter Ankerstål wrote: > Hi! > > I recently upgraded my system to 11-CURRENT (FreeBSD 11.0-CURRENT #0 > r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other > devices in the network complains about arp-flapping: >

Re: arp flapping after udating system to 11-CURRENT.

Sorry, must've missed that... :( -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: arp flapping after udating system to 11-CURRENT.

t;>> On Wed, 3 Feb 2016 08:31:43 +0100 Peter Ankerstål <pe...@pean.org> wrote >>>> >>>>> Hi! >>>>> >>>>> I recently upgraded my system to 11-CURRENT (FreeBSD 11.0-CURRENT #0 >>>>> r295087: Sun Jan 31 10:21:31 CET 20

Re: arp flapping after udating system to 11-CURRENT.

On Wed, 3 Feb 2016 11:37:30 -0800 Adrian Chadd wrote > Hi, > > Are these interfaces in a bridge group? No. > Why are you putting the IP on > the physical interface, instead of the bridgeX interface? Which is why the IP's are set per interface. :) I stated that in at

Re: arp flapping after udating system to 11-CURRENT.

On Wed, 3 Feb 2016 08:31:43 +0100 Peter Ankerstål <pe...@pean.org> wrote > Hi! > > I recently upgraded my system to 11-CURRENT (FreeBSD 11.0-CURRENT #0 > r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other > devices in the network complains about a

Re: arp flapping after udating system to 11-CURRENT.

gt; r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other > > devices in the network complains about arp-flapping: > > > > arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0 > > arp: 172.25.0.1 moved from 02:e8:ea:15:66:00 to 00:00:24:d0:

Re: arp flapping after udating system to 11-CURRENT.

gt; r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other > > devices in the network complains about arp-flapping: > > > > arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0 > > arp: 172.25.0.1 moved from 02:e8:ea:15:66:00 to 00:00:24:d0:

Re: arp flapping after udating system to 11-CURRENT.

my system to 11-CURRENT (FreeBSD 11.0-CURRENT #0 >>> r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other >>> devices in the network complains about arp-flapping: >>> >>> arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0

Re: arp flapping after udating system to 11-CURRENT.

Ankerstål <pe...@pean.org> wrote > >> > >>> Hi! > >>> > >>> I recently upgraded my system to 11-CURRENT (FreeBSD 11.0-CURRENT #0 > >>> r295087: Sun Jan 31 10:21:31 CET 2016) and after that all of my other > >>> devices in the n

Re: arp flapping after udating system to 11-CURRENT.

Hi, Are these interfaces in a bridge group? Why are you putting the IP on the physical interface, instead of the bridgeX interface? -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To

Re: r288951: ifconfig -alias, arp not removed

>>> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 >>>> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 >>>> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> >>>> media: Ethernet autoselect (1

Re: r288951: ifconfig -alias, arp not removed

 inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 >>>>  inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 >>>>  inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 >>>>  nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINK

r288951: ifconfig -alias, arp not removed

inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT ) status: active # ifconfig igb0 inet 10.1

Re: r288951: ifconfig -alias, arp not removed

gt;> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> # ifconfig igb0 inet 10.10.0.9 -alias >> # arp -an|grep 10.10.0.9 >> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb

Re: r288951: ifconfig -alias, arp not removed

t; media: Ethernet autoselect (1000baseT ) > status: active > > # ifconfig igb0 inet 10.10.0.9 -alias > # arp -an|grep 10.10.0.9 > ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] > # arp -d 10.10.0.9 > arp: writing to routing socket: Operation not permitted &g

Re: r288951: ifconfig -alias, arp not removed

gt;>> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 >>> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> # ifconfig igb0 inet

Fwd: Interfaces connected by bridge(4) do not pass arp replies

On Wed, Oct 31, 2012 at 8:37 AM, Gleb Smirnoff gleb...@freebsd.org wrote: On Wed, Oct 31, 2012 at 08:28:48AM -0400, Kim Culhan wrote: K Thanks for that, so far the working revision has been found in r240826. K K Would anyone have a suggestion for a revision to try next ? Middle between

Re: Interfaces connected by bridge(4) do not pass arp replies

, Monthadar since you have an earlier version can you try a test: From a machine on one of your 2 interfaces, can you ping a machine on the other interface? Yes Do you see the MAC for a machine on the other interface in the arp table? Yes When this problem is present, it is possible to reach

Re: Interfaces connected by bridge(4) do not pass arp replies

in the arp table? Yes When this problem is present, it is possible to reach the router and out to the internet (if it is routed that way) but in the case of the wireless interface, for example, you cannot reach a machine on the wired interface. The interfaces here: bridge0: flags=8843UP

Re: Interfaces connected by bridge(4) do not pass arp replies

Kim, On Mon, Oct 29, 2012 at 05:59:04PM -0400, Kim Culhan wrote: K What svn revision of FreeBSD -current are you running? K K FreeBSD head r238604. K K I should have mentioned earlier this is with r242126, there have been K some changes K to the network code since 238604, maybe that is why

Re: Interfaces connected by bridge(4) do not pass arp replies

a machine on one of your 2 interfaces, can you ping a machine on the other interface? Do you see the MAC for a machine on the other interface in the arp table? When this problem is present, it is possible to reach the router and out to the internet (if it is routed that way) but in the case

Re: Interfaces connected by bridge(4) do not pass arp replies

, Monthadar since you have an earlier version can you try a test: From a machine on one of your 2 interfaces, can you ping a machine on the other interface? Do you see the MAC for a machine on the other interface in the arp table? When this problem is present, it is possible to reach the router

Interfaces connected by bridge(4) do not pass arp replies

With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0

Re: Interfaces connected by bridge(4) do not pass arp replies

On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0

Re: Interfaces connected by bridge(4) do not pass arp replies

On Mon, Oct 29, 2012 at 3:59 PM, Monthadar Al Jaberi montha...@gmail.com wrote: On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request

Re: Interfaces connected by bridge(4) do not pass arp replies

On Mon, Oct 29, 2012 at 9:55 PM, Kim Culhan w8hd...@gmail.com wrote: On Mon, Oct 29, 2012 at 3:59 PM, Monthadar Al Jaberi montha...@gmail.com wrote: On Mon, Oct 29, 2012 at 8:46 PM, Kim Culhan w8hd...@gmail.com wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0

Re: Interfaces connected by bridge(4) do not pass arp replies

wrote: With 2 interfaces present on a bridge0, an arp request is send from msk0 and is received by a machine on em0. When a reply to that arp request is sent by a machine on em0 it is not visible on the bridge0 nor on msk0 as indicated by tcpdump. The arp reply is visible while watching em0

packages that can generate arp storm

hi, gurus: are freebsd system coming with any packages that could generate arp storm? thanks _gahn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd

Fw: Re: packages that can generate arp storm

- Forwarded message from Rodrigo OSORIO rodr...@bebik.net - From: Rodrigo OSORIO rodr...@bebik.net Date: Wed, 4 Apr 2012 17:14:21 +0200 To: gahn ipfr...@yahoo.com Subject: Re: packages that can generate arp storm User-Agent: Mutt/1.4.2.3i On 04/04/12 07:33 -0700, gahn wrote: hi, gurus

arp -nf list; work about 35 minutes

I have file with list of static ARP entries for about 65000 IPs. arp -nf list eating ~80% CPU and work very long time. It is a normal or something misconfigured ? FreeBSD-current from 5dec2010 ___ freebsd-current@freebsd.org mailing list http

Re: net/mpd5, ppp, proxy-arp issues

Am 22.04.2010 20:43, schrieb Marin Atanasov: Hello, Thanks a lot for the patch, Qing! It works fine. However I've noticed one thing, after I start mpd5 and connect to my home network: kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() Not very sure if this is

Re: net/mpd5, ppp, proxy-arp issues

On 4/26/10 1:11 AM, Stefan Esser wrote: Am 22.04.2010 20:43, schrieb Marin Atanasov: Hello, Thanks a lot for the patch, Qing! It works fine. However I've noticed one thing, after I start mpd5 and connect to my home network: kernel: WARNING: attempt to domain_add(netgraph) after

Re: net/mpd5, ppp, proxy-arp issues

I was using csup to track RELEN_8_0 branch. Currently I'm syncing to RELENG_8. If I understood you right, after getting the sources for RELENG_8, I need to apply the patch and then rebuild world? You only need to rebuild the kernel. -- Qing ___

Re: net/mpd5, ppp, proxy-arp issues

...@gmail.com wrote: Hi, I was setting up mpd5 from ports, but this proxy-arp issue still exists in 8.0. uname -r 8.0-RELEASE-p2 I've attached the output from the mpd5 daemon, where you can still see that the issue is relevant. I've also tried to apply the patch, but it's no longer

arp: unknown hardware address format

Hello! What is the problem if I see arp: unknown hardware address format (0x4d6f) messages with bge driver on 5.1R? Yours truly, Boris Kovalenko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current

lock order reversal (arp mutex/radix node head)

lock order reversal 1st 0xc03bbde0 arp mutex (arp mutex) @ ../../../netinet/if_ether.c:151 2nd 0xc6149e7c radix node head (radix node head) @ ../../../net/route.c:549 Debugger(witness_lock) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c031e895,c6149e7c,c033b2a0

LOR: arp mutex/radix node head

On yesterday's -current: lock order reversal 1st 0xc03d2740 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151 2nd 0xc64c6b7c radix node head (radix node head) @ /usr/src/sys/net/route.c:549 Will try to get a trace next time it happens. Lars -- Lars Eggert [EMAIL PROTECTED

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

On Fri, 19 Oct 2001, Mark Peek wrote: MPYes, it does appear to be due to this commit. The first address on the MPinterface queue has an address of 0.0.0.0. Here's a patch that works for MPme to block the messages. I'm guessing at the correct behavior so use at MPyour own risk. At least the

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

hi, there! Same here. My -CURRENT system is replying to those ARP request which carry 0.0.0.0 as sender IP address: 14:43:33.706099 arp who-has 158.227.48.193 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0 14:43:33.706152 arp reply 0.0.0.0 is-at 0:d0:b7:3e:a0:fb I think this is because I have

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

On Thu, 18 Oct 2001, Terry Lambert wrote: TLTo expand a little... TL TL That said, it's probably a good idea to never ARP for 0.0.0.0, TL since a who has in that case is a really dumb idea, since, TL as weas pointed out, it's intended to mean this host, in the TL absence of an IP address (i.e

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

On Fri, Oct 19, 2001 at 11:12:48AM +0200, Harti Brandt wrote: I have run tcpdump all night to find out what happens. The host receives an ARP request with a source address of 0.0.0.0: 18:33:51.222688 arp who-has hydra tell 0.0.0.0 0001 0800 0604 0001 0030 65c6 a174

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

will try to MK identify the senders (over 40!). MK MK Anyway, these 0.0.0.0 ARP messages are new in -CURRENT, and none of our MK machines running FreeBSD 4.x show them. MK MKhow current -CURRENT are you running? I have these two on a yesterday's current and remember that they appeared after I

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

At 9:14 PM -0500 10/19/01, Jonathan Lemon wrote: Below is the patch that I've sent to the people who reported the problem, I'm waiting to hear back from them that it works. Thanks for the real patch. It appears to work fine on my system. No log messages and arps look good so far. Mark To

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

. MK MK MK But I am not using DHCP. Maybe there are other machines in the LAN (it is MK a *big* LAN) trying to get their addresses using DHCP, and now -CURRENT MK shows a message whenever detects one of those packets. I will try to MK identify the senders (over 40!). MK MK Anyway, these 0.0.0.0 ARP

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

) trying to get their addresses using DHCP, and now -CURRENT shows a message whenever detects one of those packets. I will try to identify the senders (over 40!). Anyway, these 0.0.0.0 ARP messages are new in -CURRENT, and none of our machines running FreeBSD 4.x show them. how current -CURRENT

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

On Wed, Oct 17, 2001 at 10:55:25PM -0800, Beech Rintoul wrote: On Wed, 17 Oct 2001, Jose M. Alcaide wrote: After rebuilding the kernel two days ago (Oct 15), I am getting lots of messages like these: arp: 00:30:65:de:99:32 is using my IP address 0.0.0.0! arp: 00:0a:27:b0:a7:06 is using

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

Jose M. Alcaide wrote: I found something interesting: these messages are caused by ARP requests carrying 0.0.0.0 as the sender IP address. All of them come from Apple Macintosh (over 40 different machines). I am not sure whether 0.0.0.0 is a legal sender IP address in an ARP request; 0.0.0.0

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

To expand a little... That said, it's probably a good idea to never ARP for 0.0.0.0, since a who has in that case is a really dumb idea, since, as weas pointed out, it's intended to mean this host, in the absence of an IP address (i.e. 0.0.0.0 is not an IP address, it's a special value

arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

After rebuilding the kernel two days ago (Oct 15), I am getting lots of messages like these: arp: 00:30:65:de:99:32 is using my IP address 0.0.0.0! arp: 00:0a:27:b0:a7:06 is using my IP address 0.0.0.0! arp: 00:30:65:d1:2f:cc is using my IP address 0.0.0.0! arp: 00:30:65:e9:57:5e is using my IP

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

I've seen this when DHCP fails to allocate an address. On Wed, 17 Oct 2001, Jose M. Alcaide wrote: After rebuilding the kernel two days ago (Oct 15), I am getting lots of messages like these: arp: 00:30:65:de:99:32 is using my IP address 0.0.0.0! arp: 00:0a:27:b0:a7:06 is using my IP

Re: arp: some ether addr is using my IP address 0.0.0.0! ??!?!?

detects one of those packets. I will try to identify the senders (over 40!). Anyway, these 0.0.0.0 ARP messages are new in -CURRENT, and none of our machines running FreeBSD 4.x show them. -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** Beware of Programmers who

arp messages

Since my latest build of -current (today) I'm getting pages of these: arp: 00:30:65:48:fd:cc is using my IP address 0.0.0.0! arp: 00:30:65:48:fd:cc is using my IP address 0.0.0.0! arp: 00:30:65:48:fd:cc is using my IP address 0.0.0.0! arp: 00:30:65:48:fd:cc is using my IP address 0.0.0.0! arp

Re: gratuituous arp for multiple IP addresses

By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul That won't achieve the desired result, which is to complain if someone _else_ replies to the arp

Re: gratuituous arp for multiple IP addresses

I stand corrected again, as needed. The gratuituous arp should be formatted in whatever the correct way is. The machine that encountered loss of connectivity due to interface IPs being swapped is running 3.4-STABLE that was cvsup'd on January 7, 2000. If in fact some change was made

Re: gratuituous arp for multiple IP addresses

FreeBSD 4.0-RELEASE does the gratuitous ARP when ifconfig'ing an alias: fenestro# ifconfig de1 1.2.3.5 alias 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5 FreeBSD 3.4-STABLE also does: mango# ifconfig xl0 135.197.2.250 netmask 255.255.255.255 alias 18:39

Re: gratuituous arp for multiple IP addresses

By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul On Sun, 7 May 2000, Bill Fenner wrote: fenestro# ifconfig de1 1.2.3.5 alias 18:35:47.269471 0:40:5:42:d6:de B

Re: gratuituous arp for multiple IP addresses

By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de The ARP processing specified in RFC 826 says that if you have an entry for the source IP address you update the hardwa

Re: gratuituous arp for multiple IP addresses

Ok, I stand corrected. Rahul On Sun, 7 May 2000, Bill Fenner wrote: By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de The ARP processing specified in RFC 826 s

gratuituous arp for multiple IP addresses

. Connectivity is now lost to secondary IP addresses on each interface, presumably because upstream router's arp cache still has old entries. Said router's arp timeout is long and said router is not under my control. Router administrator eventually forces a cache flush some time later, which

Re: ARP issues (Arcnet)

Once again I'm trying to port Arcnet driver from NetBSD/amiga to FreeBSD/i386 (like I did more than a year ago for 3.x). The problem is in Wow! I might be able to make the Arcnet board in my Tandy 6000 XENIX machine actually talk to someone someday!?!?!?!? COOL! :) (Actually, that machine

ARP issues (Arcnet)

hi, there! Once again I'm trying to port Arcnet driver from NetBSD/amiga to FreeBSD/i386 (like I did more than a year ago for 3.x). The problem is in ARP stuff -- should I port if_arp.c from NetBSD or should I make changes in if_ether.c for arcnet stuff like Token Ring support did? Any

ARP Failure

I'm sorry I don't have logs to include with this, but after booting with the current kernel and system (as of Oct 28 14:52), I kept getting arp lookup failures on every address, didn't experience anything else out of the ordinary. Any ideas as to what's wrong? (If you need the actual error

Patch to fix [Re: Bad, reliable crash: Julian's oltr stuff ARP]

The problem Mr. Pallfreeman was seeing are related to how I was building the arp-reply based on the sources arp_hrd type. I never expected to see a token-ring arp arrive over an ethernet interface. Therefore the arp code was trying to check for and collect the source route that the arp took

Re: Patch to fix [Re: Bad, reliable crash: Julian's oltr stuff ARP]

Okay, that one is just a little too strong. It won't allow a FreeBSD token-ring station to arp-reply to an ethernet station on the other side of a broken translational bridge. This one will. Larry Lile l...@stdio.com On Wed, 14 Apr 1999, Larry Lile wrote: The problem Mr. Pallfreeman

Bad, reliable crash: Julian's oltr stuff ARP

My -current trashbox is having some pretty severe problems which seem to stem from the token ring additions on March 10th. The box in question wouldn't stay up for more than a few minutes. ``savecore'' isn't working for me right now, but I've managed to delete a single line of code which lets

Re: Bad, reliable crash: Julian's oltr stuff ARP

Just so Julian doesn't get blamed here, I was the one who wrote the Olicom oltr driver and made the arp changes. Julian was just nice enough to commit them. The only thing I can figure, as I can't tell exactly what caused it to punt, is that you received a token-ring arp packet that is somewhat

Re: arp.

if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables are system-wide so if i change arp entry to cacth request on PrimaryNet the 2subnet dont'works anymore. Is possible to catch arp request only on a single subnet,without broke any other

Re: arp.

to forward it. It also would not respond to ARP calls by the Primary Router when it is looking for a machine on SubNet2. wonder if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables are system-wide so if i change arp entry to cacth request

Re: arp.

it never gets the packet and never tries to forward it. It also would not respond to ARP calls by the Primary Router when it is looking for a machine on SubNet2. wonder if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables

Re: arp.

it believes that all the hosts on the 192.168.1.128 subnet are local. This is not hard to solve; you just turn on routing in the sub-router box and enable proxy-arp. This will cause the subrouter box, when it receives an arp request for the 128/25 subnet on the 0/25 interface, to reply to that ARP

arp.

of the mainroute,so i wonder if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables are system-wide so if i change arp entry to cacth request on PrimaryNet the 2subnet dont'works anymore. Is possible to catch arp request only on a single subnet

Re: arp.

is that i cannot change configuration of the mainroute,so i wonder if is possible to configure the new gateway to do a sort of proxy arp for my secondary Subnet. But arp-tables are system-wide so if i change arp entry to cacth request on PrimaryNet the 2subnet dont'works anymore. Is possible to catch

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

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

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

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

Network/ARP problem? Maybe pn driver?

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. For example, if A tries to ping B, A appears

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

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

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

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?

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

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

Re: Network/ARP problem? Maybe pn driver?

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

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