Re: RTM_NEWNEIGH message for static ARP entry

[Alexander Chernikov]

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 the report, I’ll take a look.
To me, NUD_REACHABLE | NUD_PERMANENT looks better suited for the particular 
case, but I’ll dive deeper tomorrow. Anyway NUD_INCOMPLETE is certainly wrong.
> 
> Cheers,
> Harti
> 
> 

/Alexander

RTM_NEWNEIGH message for static ARP entry

[Hartmut Brandt]

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

[FreeBSD User]

Hello,

the problem I'm about to report is not specific to CURRENT, I report this to 
CURRENT
because I'm list member. The problem occurs on FreeBSD 12.3-RELEASE-p5.

Setup: connecting to vnet jails bound to a dedicated NIC via if_bridge results 
in an
erratic behaviour (from my point of view). The box has two NICs, em0 which is 
dedicated
for managing the host and igb0 for services like NFS, SMB and jails (the host 
is de facto
a Xigmanas box). The NIC igb0 also has an IPv4 which is accessible without 
problem (sshd
is listening on em0 and igb0 and any service bound to igb0 and its IP itself 
works like a
charme, execept anything that is connected via if_bridge/vnet). Both, em0 and 
igb0, are
member of the same network and connected to the same switch (I guess, it's the 
campus
infrastructure, I have no access to that).

Phenomenon: trying to ping a jail results initially in a long term waiting and 
often in
"Host is down" - but then, sudenly, the jail is responding. Trying to connect to
port 22/tcp of any jail doesn't work in 90% of the cases, but randomly, a host 
(out of
five) does respond and the connection can be established. Terminating the 
connection and
tryin 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
every request is then acompanied by a reply. I'm not firm in terms of 
networking and
investigating ARP issues, so I followed some instructions found with ARP issues 
on FBSD,
vnet and routing.

MIB settings (on the host itself, vnet untouched):
net.inet.ip.forwarding: 0
net.link.bridge.ipfw: 0
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0

I also realised that on the igb0 interace checksum errors occured while rxcsum 
is
enabled. I disbaled special features via "ifconfig igb0  -rxcsum -txcsum -tso 
-lro

I'm out of ideas here.

Another box, the same base OS, similar setup (two NICs, same ambition), but 
with the
difference that the second NIC resides on a different network and is connected 
to a
different switch, also if_bridge and vnet attached jails, there is no problem.

Either there is a serious bug in 12.3-p5 (haven't had the chance to check on 
13/CURRENT)
or I'm doing something terribly wrong.

Some technical details:




em0@pci0:0:25:0:class=0x02 card=0x29828016 chip=0x153b8086 rev=0x04 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Connection I217-V'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xf7d0, size 131072, enabled
bar   [14] = type Memory, range 32, base 0xf7d35000, size 4096, enabled
bar   [18] = type I/O Port, range 32, base 0xf080, size 32, enabled
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 13[e0] = PCI Advanced Features: FLR TP


gb0@pci0:4:0:0:class=0x02 card=0x00028086 chip=0x15848086 rev=0x03 
hdr=0x00
vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xf790, size 1048576, enabled
bar   [1c] = type Memory, range 32, base 0xf7a0, size 16384, enabled
cap 01[40] = powerspec 3  supports D0 D3  current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks 
cap 11[70] = MSI-X supports 5 messages, enabled
 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
cap 10[a0] = PCI-Express 2 endpoint max data 128(512) FLR NS
 max read 512
 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1)
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
ecap 0003[140] = Serial 1 x
ecap 0017[1a0] = TPH Requester 1

Kind regards,

oh

Re: arp panic

[Hans Petter Selasky]

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 
r...@chd.heemeyer.club:/home/rootobj/home/git/head/sys/YOY  amd64

panic:

GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x807833ed
stack pointer   = 0x28:0xfe032db70430
frame pointer   = 0x28:0xfe032db704f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 11 (swi4: clock (0))

Reading symbols from /boot/kernel/drm2.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/drm2.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/pseudofs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/procfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/procfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/i915kms.ko.debug...done.
done.
doadump (textdump=766966752) at /home/git/head/sys/kern/kern_shutdown.c:318
318 dumptid = curthread->td_tid;
(kgdb) #0  doadump (textdump=766966752)
at /home/git/head/sys/kern/kern_shutdown.c:318
#1  0x803fbcc5 in db_fncall_generic (addr=-2139566720,
rv=0xfe032db6fb90, nargs=0, args=0xfe032db6fba0)
at /home/git/head/sys/ddb/db_command.c:581
#2  0x803fb284 in db_fncall (dummy1=-2185371386672, dummy2=false,
dummy3=0, dummy4=0xfe032db6fcd0 "\360\374\266-\003\376\377\377")
at /home/git/head/sys/ddb/db_command.c:629
#3  0x803fabee in db_command (
last_cmdp=0x81703940 , cmd_table=0x0, dopager=1)
at /home/git/head/sys/ddb/db_command.c:453
#4  0x803fa789 in db_command_loop ()
at /home/git/head/sys/ddb/db_command.c:506
#5  0x803ff5da in db_trap (type=9, code=0)
at /home/git/head/sys/ddb/db_main.c:248
#6  0x807f6b3f in kdb_trap (type=9, code=0, tf=0xfe032db70370)
at /home/git/head/sys/kern/subr_kdb.c:654
#7  0x80ceb21c in trap_fatal (frame=0xfe032db70370, eva=0)
at /home/git/head/sys/amd64/amd64/trap.c:819
#8  0x80cea651 in trap (frame=0xfe032db70370)
at /home/git/head/sys/amd64/amd64/trap.c:553
#9  0x80cebd2a in trap_check (frame=0xfe032db70370)
at /home/git/head/sys/amd64/amd64/trap.c:625
#10 
#11 0x807833ed in _rw_wlock_cookie (c=0xdeadc0dedeadc2de,
file=0x80ea3d10 "/home/git/head/sys/netinet/if_ether.c", line=287)
at /home/git/head/sys/kern/kern_rwlock.c:295
#12 0x80a2c723 in arptimer (arg=0xf80007d67a00)
at /home/git/head/sys/netinet/if_ether.c:287
#13 0x807b60bc in softclock_call_cc (c=0xf80007d67ab8,
cc=0x81a31a00 , direct=0)
at /home/git/head/sys/kern/kern_timeout.c:729
#14 0x807b68ec in softclock (arg=0x81a31a00 )
at /home/git/head/sys/kern/kern_timeout.c:867
#15 0x807350c8 in intr_event_execute_handlers (p=0xf80003df9000,
ie=0xf80003deea00) at /home/git/head/sys/kern/kern_intr.c:1262
#16 0x80735e57 in ithread_execute_handlers (p=0xf80003df9000,
ie=0xf80003deea00) at /home/git/head/sys/kern/kern_intr.c:1275
#17 0x80735c86 in ithread_loop (arg=0xf80003e30060)
at /home/git/head/sys/kern/kern_intr.c:1356
#18 0x807306ee in fork_exit (
callout=0x80735b10 , arg=0xf80003e30060,
frame=0xfe032db70ac0) at 

arp panic

[Chagin Dmitry]

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 (GDB) 7.12 [GDB v7.12 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x807833ed
stack pointer   = 0x28:0xfe032db70430
frame pointer   = 0x28:0xfe032db704f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 11 (swi4: clock (0))

Reading symbols from /boot/kernel/drm2.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/drm2.ko.debug...done.
done.
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/pseudofs.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/procfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/procfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/i915kms.ko.debug...done.
done.
doadump (textdump=766966752) at /home/git/head/sys/kern/kern_shutdown.c:318
318 dumptid = curthread->td_tid;
(kgdb) #0  doadump (textdump=766966752)
at /home/git/head/sys/kern/kern_shutdown.c:318
#1  0x803fbcc5 in db_fncall_generic (addr=-2139566720, 
rv=0xfe032db6fb90, nargs=0, args=0xfe032db6fba0)
at /home/git/head/sys/ddb/db_command.c:581
#2  0x803fb284 in db_fncall (dummy1=-2185371386672, dummy2=false, 
dummy3=0, dummy4=0xfe032db6fcd0 "\360\374\266-\003\376\377\377")
at /home/git/head/sys/ddb/db_command.c:629
#3  0x803fabee in db_command (
last_cmdp=0x81703940 , cmd_table=0x0, dopager=1)
at /home/git/head/sys/ddb/db_command.c:453
#4  0x803fa789 in db_command_loop ()
at /home/git/head/sys/ddb/db_command.c:506
#5  0x803ff5da in db_trap (type=9, code=0)
at /home/git/head/sys/ddb/db_main.c:248
#6  0x807f6b3f in kdb_trap (type=9, code=0, tf=0xfe032db70370)
at /home/git/head/sys/kern/subr_kdb.c:654
#7  0x80ceb21c in trap_fatal (frame=0xfe032db70370, eva=0)
at /home/git/head/sys/amd64/amd64/trap.c:819
#8  0x80cea651 in trap (frame=0xfe032db70370)
at /home/git/head/sys/amd64/amd64/trap.c:553
#9  0x80cebd2a in trap_check (frame=0xfe032db70370)
at /home/git/head/sys/amd64/amd64/trap.c:625
#10 
#11 0x807833ed in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, 
file=0x80ea3d10 "/home/git/head/sys/netinet/if_ether.c", line=287)
at /home/git/head/sys/kern/kern_rwlock.c:295
#12 0x80a2c723 in arptimer (arg=0xf80007d67a00)
at /home/git/head/sys/netinet/if_ether.c:287
#13 0x807b60bc in softclock_call_cc (c=0xf80007d67ab8, 
cc=0x81a31a00 , direct=0)
at /home/git/head/sys/kern/kern_timeout.c:729
#14 0x807b68ec in softclock (arg=0x81a31a00 )
at /home/git/head/sys/kern/kern_timeout.c:867
#15 0x807350c8 in intr_event_execute_handlers (p=0xf80003df9000, 
ie=0xf80003deea00) at /home/git/head/sys/kern/kern_intr.c:1262
#16 0x80735e57 in ithread_execute_handlers (p=0xf80003df9000, 
ie=0xf80003deea00) at /home/git/head/sys/kern/kern_intr.c:1275
#17 0x80735c86 in ithread_loop (arg=0xf80003e30060)
at /home/git/head/sys/kern/kern_intr.c:1356
#18 0x807306ee in fork_exit (
callout=0x80735b10 , arg=0xf80003e30060, 
frame=0xfe032db70ac0) at /home/git/head/sys/kern/kern_fork.c:1038
#19 
(kgdb) 

(kgdb) 

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

[Slawa Olhovchenkov]

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 settings I need to do?
> 
> While the documentation says you should assign an IP to the bridge it is 
> probably
> not a good idea, code aside, since bridges are layer 2 devices and IPs are
> layer 3.

bridge members also are layer 2 devices
___
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.

[Roger Marquis]

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 to the bridge it is 
probably
not a good idea, code aside, since bridges are layer 2 devices and IPs are
layer 3.

Haven't seen this issue while testing if_bridge/epair under 11-CURRENT but also
have not been assigning IPs to bridges, only to bridge members.

Roger Marquis



___
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"

arp flapping after udating system to 11-CURRENT.

[Peter Ankerstål]

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 from 02:e8:ea:15:66:00 to 00:00:24:d0:9e:5d on re0
arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0


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?



bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
1500

description: wired <-> wifi bridge
ether 02:e8:ea:15:66:00
inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
inet6 2001:470:de59::1 prefixlen 64
inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
nd6 options=1
groups: bridge
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 6
member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 6
member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 8 priority 128 path cost 2
member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 200

em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
mtu 1500

description: wired LAN

options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
ether 00:00:24:d0:9e:5d
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT )
status: active


/Peter.





smime.p7s
Description: S/MIME Cryptographic Signature

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

[Slawa Olhovchenkov]

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:
> 
> 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:9e:5d on re0
> arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
> 
> 
> 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?

I am see this on FreeBSD 10. And FreeBSD 9.
Only switch to ng_bridge remove this for me.
___
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.

[Adrian Chadd]

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.

[Allan Jude]

On 2016-02-03 12:36, Chris H wrote:
> On Wed, 3 Feb 2016 11:13:21 -0500 Allan Jude <allanj...@freebsd.org> wrote
> 
>> On 2016-02-03 10:32, Chris H wrote:
>>> On Wed, 03 Feb 2016 06:55:47 -0800 "Chris H" <bsd-li...@bsdforge.com> wrote
>>>
>>>> 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 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:9e:5d on re0
>>>>> arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
>>>>>
>>>> FWIW I'm seeing this too. As it happened; I had just changed upstream
>>>> providers, getting a larger static block (IP's), as well as updating
>>>> my long overdue -CURRENT. So I simply blamed it on their (upstream)
>>>> network. I'd love to get to the bottom of this, and would be happy to
>>>> help.
>>>>
>>>> FreeBSD dev-box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294112:
>>>> Mon Jan 18 14:25:01 PST 2016 root@dev-box:/usr/obj/usr/src/sys/DEVBOX
>>>> amd64 >>
>>>> src is at Revision: 406193
>>>>
>>> Well, it would have helped if I had also mentioned that I'm not using
>>> a bridge, and list the interfaces involved. :/
>>>
>>> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
>>>
>>> This also occurs on my 9-STABLE boxes
>>> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500  
>>>
>>>
> options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LIN
>>> KSTATE> 
>>> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
>>>
>>> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
>>>
>>> --Chris
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>>
>>>>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
>>>>> 1500
>>>>>  description: wired <-> wifi bridge
>>>>>  ether 02:e8:ea:15:66:00
>>>>>  inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
>>>>>  inet6 2001:470:de59::1 prefixlen 64
>>>>>  inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
>>>>>  nd6 options=1
>>>>>  groups: bridge
>>>>>  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>>>>  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>>>>>  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>>>>  member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>>>  ifmaxaddr 0 port 10 priority 128 path cost 6
>>>>>  member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>>>  ifmaxaddr 0 port 9 priority 128 path cost 6
>>>>>  member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>>>  ifmaxaddr 0 port 8 priority 128 path cost 2
>>>>>  member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>>>  ifmaxaddr 0 port 2 priority 128 path cost 200
>>>>>
>>>>> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
>>>>> mtu 1500
>>>>>  description: wired LAN
>>>>>  
>>>>> options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
>>>>>  ether 00:00:24:d0:9e:5d
>>>>>  nd6 options=29<PERF

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

[Chris H]

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 *least* one of my replies. :)
> 
> 
> -a
Thanks for the reply, Adrian.

--Chris


___
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.

[Chris H]

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 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:9e:5d on re0
> arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
> 
FWIW I'm seeing this too. As it happened; I had just changed upstream
providers, getting a larger static block (IP's), as well as updating
my long overdue -CURRENT. So I simply blamed it on their (upstream)
network. I'd love to get to the bottom of this, and would be happy to
help.

FreeBSD dev-box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294112:
Mon Jan 18 14:25:01 PST 2016 root@dev-box:/usr/obj/usr/src/sys/DEVBOX amd64

src is at Revision: 406193

--Chris

> 
> 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?
> 
> 
> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> 1500
>  description: wired <-> wifi bridge
>  ether 02:e8:ea:15:66:00
>  inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
>  inet6 2001:470:de59::1 prefixlen 64
>  inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
>  nd6 options=1
>  groups: bridge
>  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>  member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>  ifmaxaddr 0 port 10 priority 128 path cost 6
>  member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>  ifmaxaddr 0 port 9 priority 128 path cost 6
>  member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>  ifmaxaddr 0 port 8 priority 128 path cost 2
>  member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>  ifmaxaddr 0 port 2 priority 128 path cost 200
> 
> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> mtu 1500
>  description: wired LAN
>  
> options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
>  ether 00:00:24:d0:9e:5d
>  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>  media: Ethernet autoselect (1000baseT )
>  status: active
> 
> 
> /Peter.


___
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.

[Chris H]

On Wed, 03 Feb 2016 06:55:47 -0800 "Chris H" <bsd-li...@bsdforge.com> wrote

> 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 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:9e:5d on re0
> > arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
> > 
> FWIW I'm seeing this too. As it happened; I had just changed upstream
> providers, getting a larger static block (IP's), as well as updating
> my long overdue -CURRENT. So I simply blamed it on their (upstream)
> network. I'd love to get to the bottom of this, and would be happy to
> help.
> 
> FreeBSD dev-box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294112:
> Mon Jan 18 14:25:01 PST 2016 root@dev-box:/usr/obj/usr/src/sys/DEVBOX amd64
> 
> src is at Revision: 406193
> 
Well, it would have helped if I had also mentioned that I'm not using
a bridge, and list the interfaces involved. :/

nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>

This also occurs on my 9-STABLE boxes
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500  
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>

nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>

nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>

--Chris
> 
> > 
> > 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?
> > 
> > 
> > bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> > 1500
> >  description: wired <-> wifi bridge
> >  ether 02:e8:ea:15:66:00
> >  inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
> >  inet6 2001:470:de59::1 prefixlen 64
> >  inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
> >  nd6 options=1
> >  groups: bridge
> >  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> >  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> >  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> >  member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 10 priority 128 path cost 6
> >  member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 9 priority 128 path cost 6
> >  member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 8 priority 128 path cost 2
> >  member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 2 priority 128 path cost 200
> > 
> > em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> > mtu 1500
> >  description: wired LAN
> >  
> > options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
> >  ether 00:00:24:d0:9e:5d
> >  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> >  media: Ethernet autoselect (1000baseT )
> >  status: active
> > 
> > 
> > /Peter.
> 
> 
> ___
> 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"


___
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.

[Chris H]

On Wed, 03 Feb 2016 06:55:47 -0800 "Chris H" <bsd-li...@bsdforge.com> wrote

> 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 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:9e:5d on re0
> > arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
> > 
> FWIW I'm seeing this too. As it happened; I had just changed upstream
> providers, getting a larger static block (IP's), as well as updating
> my long overdue -CURRENT. So I simply blamed it on their (upstream)
> network. I'd love to get to the bottom of this, and would be happy to
> help.
> 
> FreeBSD dev-box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294112:
> Mon Jan 18 14:25:01 PST 2016 root@dev-box:/usr/obj/usr/src/sys/DEVBOX amd64
> 
> src is at Revision: 406193
> 
Well, it would have helped if I had also mentioned that I'm not using
a bridge, and list the interfaces involved. :/

nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>

This also occurs on my 9-STABLE boxes
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500  
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>

nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>

nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>

--Chris
> 
> > 
> > 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?
> > 
> > 
> > bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> > 1500
> >  description: wired <-> wifi bridge
> >  ether 02:e8:ea:15:66:00
> >  inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
> >  inet6 2001:470:de59::1 prefixlen 64
> >  inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
> >  nd6 options=1
> >  groups: bridge
> >  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> >  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> >  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> >  member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 10 priority 128 path cost 6
> >  member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 9 priority 128 path cost 6
> >  member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 8 priority 128 path cost 2
> >  member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >  ifmaxaddr 0 port 2 priority 128 path cost 200
> > 
> > em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> > mtu 1500
> >  description: wired LAN
> >  
> > options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
> >  ether 00:00:24:d0:9e:5d
> >  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> >  media: Ethernet autoselect (1000baseT )
> >  status: active
> > 
> > 
> > /Peter.
> 
> 
> ___
> 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"


___
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.

[Allan Jude]

On 2016-02-03 10:32, Chris H wrote:
> On Wed, 03 Feb 2016 06:55:47 -0800 "Chris H" <bsd-li...@bsdforge.com> wrote
> 
>> 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 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:9e:5d on re0
>>> arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
>>>
>> FWIW I'm seeing this too. As it happened; I had just changed upstream
>> providers, getting a larger static block (IP's), as well as updating
>> my long overdue -CURRENT. So I simply blamed it on their (upstream)
>> network. I'd love to get to the bottom of this, and would be happy to
>> help.
>>
>> FreeBSD dev-box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294112:
>> Mon Jan 18 14:25:01 PST 2016 root@dev-box:/usr/obj/usr/src/sys/DEVBOX amd64
>>
>> src is at Revision: 406193
>>
> Well, it would have helped if I had also mentioned that I'm not using
> a bridge, and list the interfaces involved. :/
> 
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> 
> This also occurs on my 9-STABLE boxes
> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500  
> options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
> 
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> 
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> 
> --Chris
>>
>>>
>>> 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?
>>>
>>>
>>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
>>> 1500
>>>  description: wired <-> wifi bridge
>>>  ether 02:e8:ea:15:66:00
>>>  inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
>>>  inet6 2001:470:de59::1 prefixlen 64
>>>  inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
>>>  nd6 options=1
>>>  groups: bridge
>>>  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>>  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>>>  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>>  member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>  ifmaxaddr 0 port 10 priority 128 path cost 6
>>>  member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>  ifmaxaddr 0 port 9 priority 128 path cost 6
>>>  member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>  ifmaxaddr 0 port 8 priority 128 path cost 2
>>>  member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>  ifmaxaddr 0 port 2 priority 128 path cost 200
>>>
>>> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
>>> mtu 1500
>>>  description: wired LAN
>>>  
>>> options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
>>>  ether 00:00:24:d0:9e:5d
>>>  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>>  media: Ethernet autoselect (1000baseT )
>>>  status: active
>>>
>>>
>>> /Peter.
>>
>>
>> ___
>> 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"
> 
> 
> ___
> 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"
> 

Chris:
If you are not using a bridge, please provide the complete output of
ifconfig, and the log messages about the arp flapping, so we can see
which two interfaces it is bouncing between.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

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

[Chris H]

On Wed, 3 Feb 2016 11:13:21 -0500 Allan Jude <allanj...@freebsd.org> wrote

> On 2016-02-03 10:32, Chris H wrote:
> > On Wed, 03 Feb 2016 06:55:47 -0800 "Chris H" <bsd-li...@bsdforge.com> wrote
> > 
> >> 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 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:9e:5d on re0
> >>> arp: 172.25.0.1 moved from 00:00:24:d0:9e:5d to 02:e8:ea:15:66:00 on re0
> >>>
> >> FWIW I'm seeing this too. As it happened; I had just changed upstream
> >> providers, getting a larger static block (IP's), as well as updating
> >> my long overdue -CURRENT. So I simply blamed it on their (upstream)
> >> network. I'd love to get to the bottom of this, and would be happy to
> >> help.
> >>
> >> FreeBSD dev-box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294112:
> >> Mon Jan 18 14:25:01 PST 2016 root@dev-box:/usr/obj/usr/src/sys/DEVBOX
> >> amd64 >>
> >> src is at Revision: 406193
> >>
> > Well, it would have helped if I had also mentioned that I'm not using
> > a bridge, and list the interfaces involved. :/
> > 
> > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> > 
> > This also occurs on my 9-STABLE boxes
> > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500  
> >
> >
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LIN
> > KSTATE> 
> > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> > 
> > nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> > options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
> > 
> > --Chris
> >>
> >>>
> >>> 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?
> >>>
> >>>
> >>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> >>> 1500
> >>>  description: wired <-> wifi bridge
> >>>  ether 02:e8:ea:15:66:00
> >>>  inet 172.25.0.1 netmask 0xff00 broadcast 172.25.0.255
> >>>  inet6 2001:470:de59::1 prefixlen 64
> >>>  inet6 fe80::2%bridge0 prefixlen 64 scopeid 0xb
> >>>  nd6 options=1
> >>>  groups: bridge
> >>>  id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> >>>  maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> >>>  root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> >>>  member: wlan2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >>>  ifmaxaddr 0 port 10 priority 128 path cost 6
> >>>  member: wlan1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >>>  ifmaxaddr 0 port 9 priority 128 path cost 6
> >>>  member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >>>  ifmaxaddr 0 port 8 priority 128 path cost 2
> >>>  member: em1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> >>>  ifmaxaddr 0 port 2 priority 128 path cost 200
> >>>
> >>> em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 
> >>> mtu 1500
> >>>  description: wired LAN
> >>>  
> >>> options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
> >>>  ether 00:00:24:d0:9e:5d
> >>>  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> >>>  media: Ethernet autoselect (1000baseT )
> >>>  status: active
> >>>
> >>>
> >>> /Peter.
> >>
> 
> Chris:
> If you are not using a bridge, p

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

[Adrian Chadd]

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 unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r288951: ifconfig -alias, arp not removed

[Eric van Gyzen]

On 10/29/2015 16:56, Bryan Drewery wrote:
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>> On 10/29/2015 11:25, Bryan Drewery wrote:
>>>> # ifconfig
>>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>>
>>>> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
>>>> ether c8:0a:a9:04:39:78
>>>> 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_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 igb0 permanent [ethernet]
>>>> # arp -d 10.10.0.9
>>>> arp: writing to routing socket: Operation not permitted
>>>>
>>>> I swear this is not normal. I'm on an older build as well, r288951.
>>>
>>> That definitely looks abnormal.  See what "route get" says.  I think
>>> that's the error you get when there is a route for that address.
>>>
>>
>> # netstat -rn|grep 10.10.0.9
>> # route get 10.10.0.9
>>route to: lapbox
>> destination: 10.10.0.0
>>mask: 255.255.0.0
>> fib: 0
>>   interface: igb0
>>   flags: <UP,DONE,PINNED>
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>> # route get 5.5.5.5
>>route to: 5.5.5.5
>> destination: default
>>mask: default
>> gateway: router.asus.com
>>     fib: 0
>>   interface: igb0
>>   flags: <UP,GATEWAY,DONE,STATIC>
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500         1 0
>>
>> For more context, this current system had 10.10.0.9 added to it. I
>> started up a VM which also started using 10.10.0.9 and managed to "win"
>> on the local network for owning it. (I don't know arp and this stuff
>> well). I then came to this system to remove the alias and the arp entry
>> to allow me to connect from it and have gotten into this situation.
>>
> 
> Just saw this in dmesg, which is what I described:
> 
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0

The kernel should have removed the arp entry when you removed the alias.
 I just played with this on r289837 (one week old), and I could not
reproduce the failure.  In particular, r289501 sounds interesting, even
though your interface is up.

Eric
___
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: r288951: ifconfig -alias, arp not removed

[Alexander V . Chernikov]

30.10.2015, 00:57, "Bryan Drewery" <bdrew...@freebsd.org>:
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>>  On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>>  On 10/29/2015 11:25, Bryan Drewery wrote:
>>>>  # ifconfig
>>>>  igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>>
>>>>  
>>>> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
>>>>  ether c8:0a:a9:04:39:78
>>>>  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_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 igb0 permanent [ethernet]
>>>>  # arp -d 10.10.0.9
>>>>  arp: writing to routing socket: Operation not permitted
>>>>
>>>>  I swear this is not normal. I'm on an older build as well, r288951.
Well, there were changes on arpscrub procedures in r287789.
(There was one bug fixed in r289501, but I think it is not relevant).
Could you consider trying more recent HEAD and check if this is still 
reproducible?
I was not able to reproduce that behavior.
>>>
>>>  That definitely looks abnormal. See what "route get" says. I think
>>>  that's the error you get when there is a route for that address.
>>
>>  # netstat -rn|grep 10.10.0.9
>>  # route get 10.10.0.9
>> route to: lapbox
>>  destination: 10.10.0.0
>> mask: 255.255.0.0
>>  fib: 0
>>    interface: igb0
>>    flags: <UP,DONE,PINNED>
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>  # route get 5.5.5.5
>> route to: 5.5.5.5
>>  destination: default
>>     mask: default
>>  gateway: router.asus.com
>>  fib: 0
>>    interface: igb0
>>    flags: <UP,GATEWAY,DONE,STATIC>
>>   recvpipe sendpipe ssthresh rtt,msec mtu weight expire
>> 0 0 0 0 1500 1 0
>>
>>  For more context, this current system had 10.10.0.9 added to it. I
>>  started up a VM which also started using 10.10.0.9 and managed to "win"
>>  on the local network for owning it. (I don't know arp and this stuff
>>  well). I then came to this system to remove the alias and the arp entry
>>  to allow me to connect from it and have gotten into this situation.
>
> Just saw this in dmesg, which is what I described:
>
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
>
> --
> Regards,
> Bryan Drewery
___
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"

r288951: ifconfig -alias, arp not removed

[Bryan Drewery]

# ifconfig
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
ether c8:0a:a9:04:39:78
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_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 igb0 permanent [ethernet]
# arp -d 10.10.0.9
arp: writing to routing socket: Operation not permitted

I swear this is not normal. I'm on an older build as well, r288951.

-- 
Regards,
Bryan Drewery
___
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: r288951: ifconfig -alias, arp not removed

[Bryan Drewery]

On 10/29/15 9:42 AM, Eric van Gyzen wrote:
> On 10/29/2015 11:25, Bryan Drewery wrote:
>> # ifconfig
>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>
>> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
>> ether c8:0a:a9:04:39:78
>> 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_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 igb0 permanent [ethernet]
>> # arp -d 10.10.0.9
>> arp: writing to routing socket: Operation not permitted
>>
>> I swear this is not normal. I'm on an older build as well, r288951.
> 
> That definitely looks abnormal.  See what "route get" says.  I think
> that's the error you get when there is a route for that address.
> 

# netstat -rn|grep 10.10.0.9
# route get 10.10.0.9
   route to: lapbox
destination: 10.10.0.0
   mask: 255.255.0.0
fib: 0
  interface: igb0
  flags: <UP,DONE,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
   0 0 0 0  1500 1 0
# route get 5.5.5.5
   route to: 5.5.5.5
destination: default
   mask: default
gateway: router.asus.com
fib: 0
  interface: igb0
  flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
   0 0 0 0  1500 1 0

For more context, this current system had 10.10.0.9 added to it. I
started up a VM which also started using 10.10.0.9 and managed to "win"
on the local network for owning it. (I don't know arp and this stuff
well). I then came to this system to remove the alias and the arp entry
to allow me to connect from it and have gotten into this situation.


-- 
Regards,
Bryan Drewery
___
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: r288951: ifconfig -alias, arp not removed

[Eric van Gyzen]

On 10/29/2015 11:25, Bryan Drewery wrote:
> # ifconfig
> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 
> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
> ether c8:0a:a9:04:39:78
> 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_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 igb0 permanent [ethernet]
> # arp -d 10.10.0.9
> arp: writing to routing socket: Operation not permitted
> 
> I swear this is not normal. I'm on an older build as well, r288951.

That definitely looks abnormal.  See what "route get" says.  I think
that's the error you get when there is a route for that address.

Eric
___
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: r288951: ifconfig -alias, arp not removed

[Bryan Drewery]

On 10/29/2015 9:46 AM, Bryan Drewery wrote:
> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>> On 10/29/2015 11:25, Bryan Drewery wrote:
>>> # ifconfig
>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>
>>> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
>>> ether c8:0a:a9:04:39:78
>>> 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_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 igb0 permanent [ethernet]
>>> # arp -d 10.10.0.9
>>> arp: writing to routing socket: Operation not permitted
>>>
>>> I swear this is not normal. I'm on an older build as well, r288951.
>>
>> That definitely looks abnormal.  See what "route get" says.  I think
>> that's the error you get when there is a route for that address.
>>
> 
> # netstat -rn|grep 10.10.0.9
> # route get 10.10.0.9
>route to: lapbox
> destination: 10.10.0.0
>mask: 255.255.0.0
> fib: 0
>   interface: igb0
>   flags: <UP,DONE,PINNED>
>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>0 0 0 0  1500 1 0
> # route get 5.5.5.5
>route to: 5.5.5.5
> destination: default
>mask: default
> gateway: router.asus.com
> fib: 0
>   interface: igb0
>   flags: <UP,GATEWAY,DONE,STATIC>
>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>0 0 0 0  1500 1 0
> 
> For more context, this current system had 10.10.0.9 added to it. I
> started up a VM which also started using 10.10.0.9 and managed to "win"
> on the local network for owning it. (I don't know arp and this stuff
> well). I then came to this system to remove the alias and the arp entry
> to allow me to connect from it and have gotten into this situation.
> 

Just saw this in dmesg, which is what I described:

arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0
arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
on igb0



-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Kim Culhan]

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 r240826 and revision that didn't work for you. :)

 --
 Totus tuus, Glebius.

Searching for the revision which did not work, I started with a test
machine at a revision which was working and
tested several builds until the latest at the time: r242429, where it
is still working.

The 'non-working' machine was also updated to r242429 and it is still
not working.

For this update, the existing /usr/src tree was removed and a new tree
checked-out, /usr/obj was removed before
building.

The working machine had 2 identical em interfaces, so removed one and
installed it into the non-working machine
replacing an re interface there.

The em interface on the working machine looks like:

em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric
0 mtu 1500

options=4009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO
ether 00:15:17:93:95:c9
inet6 fe80::215:17ff:fe93:95c9%em0 prefixlen 64 scopeid 0x1
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active

The identical type em interface on the non-working machine looks like:

em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric
0 mtu 1500
options=40098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO
ether 00:15:17:98:5f:e6
inet6 fe80::215:17ff:fe98:5fe6%em0 prefixlen 64 scopeid 0x2
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active

Note the options on the cards are now different, how can I [re]enable
RXCSUM,TXCSUM on the card
which was moved?

Any thoughts on what could be going on would be greatly appreciated.

thanks
-kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Monthadar Al Jaberi]

On Tue, Oct 30, 2012 at 2:29 PM, Kim Culhan w8hd...@gmail.com wrote:
 On Tue, Oct 30, 2012 at 8:19 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
   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 you don't have this 
 problem.

 If you can do binary search, that may be valuable.

 --
 Totus tuus, Glebius.

 Ok I can begin that process, 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 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,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 ether 02:f3:8d:7d:04:00
 inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
 member: msk0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
 ifmaxaddr 0 port 2 priority 128 path cost 55
 member: em0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
 ifmaxaddr 0 port 1 priority 128 path cost 200
 member: wlan1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
 ifmaxaddr 0 port 11 priority 128 path cost 3

 msk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST
 metric 0 mtu 1500
 options=c0019RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWTSO,LINKSTATE
 ether 00:1e:8c:0a:50:e2
 inet6 fe80::21e:8cff:fe0a:50e2%msk0 prefixlen 64 scopeid 0x2
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active

 em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric
 0 mtu 1500
 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC
 ether 00:0e:0c:7f:cf:02
 inet6 fe80::20e:cff:fe7f:cf02%em0 prefixlen 64 scopeid 0x1
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active

 In rc.conf the bridge is created with:

 ifconfig_bridge0=inet 10.0.0.1 netmask 255.255.255.0 addm wlan1 addm
 em0 addm msk0 up

I create the bridge the same way as you.


 thanks
 -kim



-- 
Monthadar Al Jaberi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Kim Culhan]

On Wed, Oct 31, 2012 at 4:41 AM, Monthadar Al Jaberi
montha...@gmail.com wrote:
 On Tue, Oct 30, 2012 at 2:29 PM, Kim Culhan w8hd...@gmail.com wrote:
 On Tue, Oct 30, 2012 at 8:19 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
   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 you don't have this 
 problem.

 If you can do binary search, that may be valuable.

 --
 Totus tuus, Glebius.

 Ok I can begin that process, 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 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,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 ether 02:f3:8d:7d:04:00
 inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
 member: msk0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
 ifmaxaddr 0 port 2 priority 128 path cost 55
 member: em0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
 ifmaxaddr 0 port 1 priority 128 path cost 200
 member: wlan1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
 ifmaxaddr 0 port 11 priority 128 path cost 3

 msk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST
 metric 0 mtu 1500
 options=c0019RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWTSO,LINKSTATE
 ether 00:1e:8c:0a:50:e2
 inet6 fe80::21e:8cff:fe0a:50e2%msk0 prefixlen 64 scopeid 0x2
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active

 em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric
 0 mtu 1500
 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC
 ether 00:0e:0c:7f:cf:02
 inet6 fe80::20e:cff:fe7f:cf02%em0 prefixlen 64 scopeid 0x1
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active

 In rc.conf the bridge is created with:

 ifconfig_bridge0=inet 10.0.0.1 netmask 255.255.255.0 addm wlan1 addm
 em0 addm msk0 up

 I create the bridge the same way as you.

Thanks for that, so far the working revision has been found in r240826.

Would anyone have a suggestion for a revision to try next ?

thanks
-kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Gleb Smirnoff]

  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 you don't have this 
problem.

If you can do binary search, that may be valuable.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Kim Culhan]

On Tue, Oct 30, 2012 at 8:19 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
   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 you don't have this 
 problem.

 If you can do binary search, that may be valuable.

 --
 Totus tuus, Glebius.

Ok I can begin that process, 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 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,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 02:f3:8d:7d:04:00
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: msk0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 2 priority 128 path cost 55
member: em0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 1 priority 128 path cost 200
member: wlan1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 11 priority 128 path cost 3

msk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST
metric 0 mtu 1500
options=c0019RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWTSO,LINKSTATE
ether 00:1e:8c:0a:50:e2
inet6 fe80::21e:8cff:fe0a:50e2%msk0 prefixlen 64 scopeid 0x2
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active

em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric
0 mtu 1500
options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC
ether 00:0e:0c:7f:cf:02
inet6 fe80::20e:cff:fe7f:cf02%em0 prefixlen 64 scopeid 0x1
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active

In rc.conf the bridge is created with:

ifconfig_bridge0=inet 10.0.0.1 netmask 255.255.255.0 addm wlan1 addm
em0 addm msk0 up

thanks
-kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Kim Culhan]

On Tue, Oct 30, 2012 at 9:29 AM, Kim Culhan w8hd...@gmail.com wrote:
 On Tue, Oct 30, 2012 at 8:19 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
   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 you don't have this 
 problem.

 If you can do binary search, that may be valuable.

 --
 Totus tuus, Glebius.

 Ok I can begin that process, 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 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:

Sorry omitted one interface:

wlan1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST
metric 0 mtu 1500
ether fa:d1:11:38:3c:e5
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng hostap
status: running
ssid ap2 channel 6 (2437 MHz 11g ht/40+) bssid fa:d1:11:38:3c:e5
regdomain 32924 country CN indoor ecm authmode OPEN privacy OFF
txpower 20 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8
shortgi wme burst dtimperiod 1

-kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Kim Culhan]

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 with tcpdump.

This behaviour is also true when arp requests are sent from a wlan
interface ath0
and received on a wired interface, the arp reply is visible on the
wired interface but not
visible monitoring with 'tcpdump -i bridge0 arp'.

The machine running the em0, msk0 and ath0 interfaces and bridge0 can
receive arp requests
from any interface and the arp replies are received fine from the
machine by the arp requester -err requestor.

Any help is greatly appreciated.

thanks
-kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Monthadar Al Jaberi]

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 as indicated by tcpdump.

 The arp reply is visible while watching em0 with tcpdump.

Is em0 set in promisc mode?


 This behaviour is also true when arp requests are sent from a wlan
 interface ath0
 and received on a wired interface, the arp reply is visible on the
 wired interface but not
 visible monitoring with 'tcpdump -i bridge0 arp'.

Hmm, I am briding between ath0 and wired (arge0).

Can you provide more info? what is your rc.conf? How does it set the interfaces?
Can you give ifconfig output?
The are reply that you dont see on bridge0 can you dump it from wired
interface?


 The machine running the em0, msk0 and ath0 interfaces and bridge0 can
 receive arp requests
 from any interface and the arp replies are received fine from the
 machine by the arp requester -err requestor.

 Any help is greatly appreciated.

 thanks
 -kim
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



-- 
Monthadar Al Jaberi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Kim Culhan]

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 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 with tcpdump.

 Is em0 set in promisc mode?


 This behaviour is also true when arp requests are sent from a wlan
 interface ath0
 and received on a wired interface, the arp reply is visible on the
 wired interface but not
 visible monitoring with 'tcpdump -i bridge0 arp'.

 Hmm, I am briding between ath0 and wired (arge0).

 Can you provide more info? what is your rc.conf? How does it set the 
 interfaces?
 Can you give ifconfig output?
 The are reply that you dont see on bridge0 can you dump it from wired
 interface?

What svn revision of FreeBSD -current are you running?

 The machine running the em0, msk0 and ath0 interfaces and bridge0 can
 receive arp requests
 from any interface and the arp replies are received fine from the
 machine by the arp requester -err requestor.

 Any help is greatly appreciated.

 thanks
 -kim
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



 --
 Monthadar Al Jaberi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Monthadar Al Jaberi]

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 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 with tcpdump.

 Is em0 set in promisc mode?


 This behaviour is also true when arp requests are sent from a wlan
 interface ath0
 and received on a wired interface, the arp reply is visible on the
 wired interface but not
 visible monitoring with 'tcpdump -i bridge0 arp'.

 Hmm, I am briding between ath0 and wired (arge0).

 Can you provide more info? what is your rc.conf? How does it set the 
 interfaces?
 Can you give ifconfig output?
 The are reply that you dont see on bridge0 can you dump it from wired
 interface?

 What svn revision of FreeBSD -current are you running?

FreeBSD head r238604.


 The machine running the em0, msk0 and ath0 interfaces and bridge0 can
 receive arp requests
 from any interface and the arp replies are received fine from the
 machine by the arp requester -err requestor.

 Any help is greatly appreciated.

 thanks
 -kim
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



 --
 Monthadar Al Jaberi



-- 
Monthadar Al Jaberi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Kim Culhan]

On Mon, Oct 29, 2012 at 5:17 PM, Monthadar Al Jaberi
montha...@gmail.com wrote:
 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 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 with tcpdump.

 Is em0 set in promisc mode?


 This behaviour is also true when arp requests are sent from a wlan
 interface ath0
 and received on a wired interface, the arp reply is visible on the
 wired interface but not
 visible monitoring with 'tcpdump -i bridge0 arp'.

 Hmm, I am briding between ath0 and wired (arge0).

 Can you provide more info? what is your rc.conf? How does it set the 
 interfaces?
 Can you give ifconfig output?
 The are reply that you dont see on bridge0 can you dump it from wired
 interface?

 What svn revision of FreeBSD -current are you running?

 FreeBSD head r238604.

I should have mentioned earlier this is with r242126, there have been
some changes
to the network code since 238604, maybe that is why you don't have this problem.

-kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

packages that can generate arp storm

[gahn]

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-current-unsubscr...@freebsd.org

Fw: Re: packages that can generate arp storm

[Rodrigo OSORIO]

- 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:
 
 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-current-unsubscr...@freebsd.org

Hi,

There is a few list of ports dealing with arp :

net-mgmt/arpscan : simple scanner which sends out arp requests for the given IP 
addresses.
security/arpCounterattack : a program for detecting and remedying ARP attacks.
security/ipguard : listens network for ARP packets and if not listed in 
'ethers' file, it will send ARP reply with configured
fake address.

I'm sure combining those tools together you can obtain a funny arp party !

Regards,
- rodrigo


- End forwarded message -
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

arp -nf list; work about 35 minutes

[Andrey Smagin]

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://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Stefan Esser]

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 something to worry about or not?

There was a problem with the initialization order of network domains,
which caused kernel crashes with ISDN+INET6 some two years ago. The
reason was, that there was an implicit assumption, that all domains
were initialized when the network interfaces are initialized, with
NULL dereferences if domains are added (and relevant to a device)
after the device has been initialized.

I debugged this problem and prepared a patch for discussion, which
later was committed by Max Laier (if memory serves me right). The
message was added in order to identify further situations, where
network domains are added after network interfaces have been
initialized. This message ought to be informational right now, since
the interface init is repeated whenever a network domain is added
as part of above mentioned patch. Init order should be fixed, if
this message is printed for compiled in drivers, but in case of a
kernel module (like netgraph) that adds a domain, it is unadvoidable
that the init order is reversed.

Perhaps the message should be made conditional on the start-up of
the kernel not having finished, or it should be completely removed,
since time has shown, that the init order is correct in general.

I'll remove that message (or make it conditional on bootverbose)
unless there is opposition to this change ...

Regards, STefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Julian Elischer]

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 domainfinalize()

Not very sure if this is something to worry about or not?


There was a problem with the initialization order of network domains,
which caused kernel crashes with ISDN+INET6 some two years ago. The
reason was, that there was an implicit assumption, that all domains
were initialized when the network interfaces are initialized, with
NULL dereferences if domains are added (and relevant to a device)
after the device has been initialized.

I debugged this problem and prepared a patch for discussion, which
later was committed by Max Laier (if memory serves me right). The
message was added in order to identify further situations, where
network domains are added after network interfaces have been
initialized. This message ought to be informational right now, since
the interface init is repeated whenever a network domain is added
as part of above mentioned patch. Init order should be fixed, if
this message is printed for compiled in drivers, but in case of a
kernel module (like netgraph) that adds a domain, it is unadvoidable
that the init order is reversed.

Perhaps the message should be made conditional on the start-up of
the kernel not having finished, or it should be completely removed,
since time has shown, that the init order is correct in general.

I'll remove that message (or make it conditional on bootverbose)
unless there is opposition to this change ...

please do..

it's an unavoidable thing that domains added after boot
are done after boot completes   :-)


Regards, STefan
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Qing Li]

 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

[Qing Li]

Have you seen this thread?

http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025128.html

Quite a few fixes have gone into the -current and RELENG_8 branches.
Please try sync-up to the latest code before applying the patch.

-- Qing



On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov dna...@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 on that location.
 Something else to add - I've a dns server running on the same machine that
 mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp
 issue, but after a couple of start/stops of mpd5 the name resolving from the
 gateway machine is not possible, all other systems from the internal network
 are able to use the dns server on the gateway, but the gateway itself
 cannot.

 Restart of named, doesn't help either, so I had to completely reboot the
 machine, so that arp entries are flushed as well.

 Could you please have a look at the issue? If you need some additional
 information, please let me know.

 Regards,
 Marin

 On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. pr...@skylinetele.com
 wrote:

 Thank you !
 The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with
 mpd5).

 Please, somebody  fix  the bug kern/141285...


 Li, Qing wrote:

 Hi,

 Recently there have been several reports regarding issues with ppp, mpd5
 and proxy-arp configuration over the ppp links. I read through the
 various postings and the problems seem to be:

 1. Unable to add proxy-arp entries for the remote ppp clients.

 2. Log showing ifa_add_loopback_route: insertion failed causing    some
 userland applications to fail.

 May I ask that you try applying patch

  http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff

 and report back if the patch fixes your problems. And if not, please
 describe what additional issues you are having.

 Thanks,

 -- Qing


 ___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org




 ___
 freebsd-sta...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org



 --
 Marin Atanasov Nikolov
 dnaeon AT gmail DOT com
 daemon AT unix-heaven DOT org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

arp: unknown hardware address format

[Boris Kovalenko]

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
To unsubscribe, send any mail to [EMAIL PROTECTED]

lock order reversal (arp mutex/radix node head)

[Kris Kennaway]

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,c033b2a0,c033b2f6) at Debugger+0x55
witness_lock(c6149e7c,8,c033b2f6,225,0) at witness_lock+0x667
_mtx_lock_flags(c6149e7c,0,c033b2f6,225,c01bc2e4) at _mtx_lock_flags+0xb2
rtrequest1(2,df0d1c44,0,0,c638e680) at rtrequest1+0x5a
rtrequest(2,c638e680,0,0,0) at rtrequest+0x4b
arptfree(c612eb40,0,7530,97,7) at arptfree+0x76
arptimer(0,0,c03344ed,bf,1d9e6) at arptimer+0x80
softclock(0,0,c0331543,230,c21ab720) at softclock+0x19c
ithread_loop(c21a8e00,df0d1d48,c03313b4,361,0) at ithread_loop+0x182
fork_exit(c01a4650,c21a8e00,df0d1d48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xdf0d1d7c, ebp = 0 ---
db 

Kris



msg50892/pgp0.pgp
Description: PGP signature

LOR: arp mutex/radix node head

[Lars Eggert]

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]   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature

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

[Harti Brandt]

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 voices^Wlog messages have stopped. :-)
MP
MPMark

The last commit fixed the problem. Thanks.

harti
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Max Khon]

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 an interface that is up and has NO IP
  address:
 
 I don't think so:
 
 # ifconfig -a
 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 inet 158.227.6.52 netmask 0xff00 broadcast 158.227.6.255
 inet6 fe80::2d0:b7ff:fe3e:a0fb%fxp0 prefixlen 64 scopeid 0x1 
 inet6 fec0::9ee3:634 prefixlen 120 
 ether 00:d0:b7:3e:a0:fb 
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
 inet6 ::1 prefixlen 128 
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
 inet 127.0.0.1 netmask 0xff00 
 
 Something is broken in the ARP implementation of -CURRENT.

please try this patch (provided by jlemon)

Index: if_ether.c
===
RCS file: /ncvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c  2001/10/17 18:07:05 1.85
+++ if_ether.c  2001/10/19 15:38:07
@@ -593,10 +593,12 @@
isaddr.s_addr == ia-ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
+* No match, use the first inet address on the receive interface
 * as a dummy address for the rest of the function.
 */
-   ifa = TAILQ_FIRST(ifp-if_addrhead);
+   TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
+   if (ifa-ifa_addr  ifa-ifa_addr-sa_family == AF_INET)
+   break;
if (ifa == NULL) {
m_freem(m);
return;

/fjoe

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Harti Brandt]

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. 0.0.0.0 is not an IP address,
TL it's a special value meaning not an IP address).
TL
TLIt's probably also a good idea to make interfaces who have an
TLIP of 0.0.0.0 _not_ respond to ARP requests for that address,
TLand, just in case there are other idiots, we should also not
TLgive proxy ARP responses for that address, etiher.

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 
     c1af 8755  
       

I think, this may happen if the host does not yet know it's IP address
(DHCP maybe?).

But FreeBSD-current for some unknown reason answers to this request:

18:33:51.222835 arp reply 0.0.0.0 is-at 0:60:97:a:99:f
 0001 0800 0604 0002 0060 970a 990f 
  0030 65c6 a174    
       

and then prints:

Oct 18 18:33:51 scotty /boot/kernel/kernel: arp: 00:30:65:c6:a1:74 is using my IP 
address 0.0.0.0!

I think this is because I have an interface that is up and has NO IP
address:

lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet 127.0.0.1 netmask 0xff00
xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
inet 193.175.135.70 netmask 0xff00 broadcast 193.175.135.255
ether 00:60:97:0a:99:0f
media: Ethernet 10baseT/UTP (10baseT/UTP half-duplex)

hatm0: flags=841UP,RUNNING,SIMPLEX mtu 9180
media: ATM UTP/155MBit
status: active
lane0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1516
ether 00:00:00:00:00:00

I think it is definitly wrong to assume that an interface with no IP
address has IP address 0.0.0.0

harti

TLGhah.  I hate special cases...

everything is a special case...

harti

TL
TL-- Terry
TL
TLTo Unsubscribe: send mail to [EMAIL PROTECTED]
TLwith unsubscribe freebsd-net in the body of the message
TL

-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Jose M. Alcaide]

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 
      c1af 8755  
        
 
 I think, this may happen if the host does not yet know it's IP address
 (DHCP maybe?).
 
 But FreeBSD-current for some unknown reason answers to this request:
 
 18:33:51.222835 arp reply 0.0.0.0 is-at 0:60:97:a:99:f
  0001 0800 0604 0002 0060 970a 990f 
   0030 65c6 a174    
        
 
 and then prints:
 
 Oct 18 18:33:51 scotty /boot/kernel/kernel: arp: 00:30:65:c6:a1:74 is using my IP 
address 0.0.0.0!

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 an interface that is up and has NO IP
 address:

I don't think so:

# ifconfig -a
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 158.227.6.52 netmask 0xff00 broadcast 158.227.6.255
inet6 fe80::2d0:b7ff:fe3e:a0fb%fxp0 prefixlen 64 scopeid 0x1 
inet6 fec0::9ee3:634 prefixlen 120 
ether 00:d0:b7:3e:a0:fb 
media: Ethernet autoselect (100baseTX full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 

Something is broken in the ARP implementation of -CURRENT.

  --JMA
-- 
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** Beware of Programmers who carry screwdrivers --  Leonard Brandwein **

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Jonathan Lemon]

On Fri, Oct 19, 2001 at 04:58:21PM -0700, Mark Peek wrote:
 At 11:23 AM +0200 10/18/01, Harti Brandt wrote:
 On Thu, 18 Oct 2001, Max Khon wrote:
 
 MKhi, there!
 MK
 MKOn Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:
 MK
 MK On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
 MK  I've seen this when DHCP fails to allocate an address.
 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 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 saw a commit message approx. 2 weeks ago about adding hashing of
 inet addresses (maybe rev. 1.83 of if_ether.c).
 
 
 Yes, it does appear to be due to this commit. The first address on the
 interface queue has an address of 0.0.0.0. Here's a patch that works for
 me to block the messages. I'm guessing at the correct behavior so use at
 your own risk. At least the voices^Wlog messages have stopped. :-)

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.
-- 
Jonathan

Index: if_ether.c
===
RCS file: /ncvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c  2001/10/17 18:07:05 1.85
+++ if_ether.c  2001/10/19 15:38:07
@@ -593,10 +593,12 @@
isaddr.s_addr == ia-ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
+* No match, use the first inet address on the receive interface
 * as a dummy address for the rest of the function.
 */
-   ifa = TAILQ_FIRST(ifp-if_addrhead);
+   TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
+   if (ifa-ifa_addr  ifa-ifa_addr-sa_family == AF_INET)
+   break;
if (ifa == NULL) {
m_freem(m);
return;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Mark Peek]

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 Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Mark Peek]

At 11:23 AM +0200 10/18/01, Harti Brandt wrote:
On Thu, 18 Oct 2001, Max Khon wrote:

MKhi, there!
MK
MKOn Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:
MK
MK On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
MK  I've seen this when DHCP fails to allocate an address.
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 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 saw a commit message approx. 2 weeks ago about adding hashing of
inet addresses (maybe rev. 1.83 of if_ether.c).


Yes, it does appear to be due to this commit. The first address on the
interface queue has an address of 0.0.0.0. Here's a patch that works for
me to block the messages. I'm guessing at the correct behavior so use at
your own risk. At least the voices^Wlog messages have stopped. :-)

Mark

--
Index: if_ether.c
===
RCS file: /cvs/freebsd/src/sys/netinet/if_ether.c,v
retrieving revision 1.85
diff -u -r1.85 if_ether.c
--- if_ether.c  2001/10/17 18:07:05 1.85
+++ if_ether.c  2001/10/19 23:53:44
@@ -593,15 +593,19 @@
isaddr.s_addr == ia-ia_addr.sin_addr.s_addr)
goto match;
/*
-* No match, use the first address on the receive interface
-* as a dummy address for the rest of the function.
+* No match, use the first non-0.0.0.0 address on the receive
+* interface as a dummy address for the rest of the function.
 */
-   ifa = TAILQ_FIRST(ifp-if_addrhead);
-   if (ifa == NULL) {
-   m_freem(m);
-   return;
-   }
-   ia = ifatoia(ifa);
+   TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
+   if (ifatoia(ifa)-ia_addr.sin_addr.s_addr != 0) {
+   ia = ifatoia(ifa);
+   goto match;
+   }
+
+   /* No applicable interface/address so bail... */
+   m_freem(m);
+   return;
+
 match:
myaddr = ia-ia_addr.sin_addr;
if (!bcmp(ar_sha(ah), IF_LLADDR(ifp), ifp-if_addrlen)) {

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Max Khon]

hi, there!

On Thu, Oct 18, 2001 at 12:00:52AM +0200, Jose M. Alcaide wrote:

 On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
  I've seen this when DHCP fails to allocate an address.
  
 
 But I am not using DHCP. Maybe there are other machines in the LAN (it is
 a *big* LAN) 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 are you running?

/fjoe

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Jose M. Alcaide]

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 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 address 0.0.0.0!
 
  and so on.
 
  Neither ifconfig(8) nor arp(8) show anything unusual.
 
 
 I'm having the exact same problem. I connect to a large subnet  /12 and I'm 
 getting flooded with these. This just started about a week ago. I'm also not 
 using DHCP. Any way of blocking this short of turning off all kernel messages?

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 means this host, so
that I think that it is a valid address when the machine doing the ARP
request does not know its IP address yet (though this sounds stupid).

Anyway, the fact is that -CURRENT can flood the console and
/var/log/messages if there are many Macintosh sending these ARP requests
in a LAN (as it is our case). I think that there is no reason to printf
these messages, since 0.0.0.0 is a valid IP address meaning this host.

-- 
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** Beware of Programmers who carry screwdrivers --  Leonard Brandwein **

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Terry Lambert]

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 means this host, so
 that I think that it is a valid address when the machine doing the ARP
 request does not know its IP address yet (though this sounds stupid).

Most likely, these are ARPs for multicast for SLPv2 location
of network resources, such as default gateway, etc., prior to
stateless autoconfiguration.

We discussed doing this on one of the IETF lists, as a side issue
to IPv6 stateless autoconfiguration, which ends up giving you a
routable address, in the context of permitting the reverse
address to be set to a machine name outside your domain for a
machine who got a routable stateless address from your domain.

You may also want to look at the ZEROCONF working group list
archives.


 Anyway, the fact is that -CURRENT can flood the console and
 /var/log/messages if there are many Macintosh sending these ARP requests
 in a LAN (as it is our case). I think that there is no reason to printf
 these messages, since 0.0.0.0 is a valid IP address meaning this host.

Yes.  This is basically a required use for a whohas for doing
stateless autoconfiguration, both in IPv6 (routable) and IPv4
(in the presence of a NAT).

The most recent DHCP and autoconfiguration RFC lets you ignore
DHCP entirely, and it lets you have a DHCP server refuse an
address to the host, with no recourse for the host to do the
autoconfiguration (e.g. a properly configured DHCP server can
make a conforming client not get an address at all).  I don't
think that, in that case, leaving the machine at 0.0.0.0 is a
valid thing to do: the interface should probably be forced down
instead.

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 meaning not an IP address).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Terry Lambert]

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 meaning not an IP address).

It's probably also a good idea to make interfaces who have an
IP of 0.0.0.0 _not_ respond to ARP requests for that address,
and, just in case there are other idiots, we should also not
give proxy ARP responses for that address, etiher.

Ghah.  I hate special cases...

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Jose M. Alcaide]

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 address 0.0.0.0!

and so on.

Neither ifconfig(8) nor arp(8) show anything unusual.

Somebody reported this problem about two weeks ago, but there were no
answers. Any ideas?

Cheers,
JMA
-- 
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** Beware of Programmers who carry screwdrivers --  Leonard Brandwein **

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Julian Elischer]

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 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 address 0.0.0.0!
 
 and so on.
 
 Neither ifconfig(8) nor arp(8) show anything unusual.
 
 Somebody reported this problem about two weeks ago, but there were no
 answers. Any ideas?
 
 Cheers,
 JMA
 -- 
 ** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
 ** Beware of Programmers who carry screwdrivers --  Leonard Brandwein **
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

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

[Jose M. Alcaide]

On Wed, Oct 17, 2001 at 12:11:45PM -0700, Julian Elischer wrote:
 I've seen this when DHCP fails to allocate an address.
 

But I am not using DHCP. Maybe there are other machines in the LAN (it is
a *big* LAN) 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.

-- 
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** Beware of Programmers who carry screwdrivers --  Leonard Brandwein **

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

arp messages

[Beech Rintoul]

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: 00:30:65:d6:36:8c is using my IP address 0.0.0.0!
arp: 00:30:65:d6:36:8c is using my IP address 0.0.0.0!
arp: 00:30:65:d6:36:8c is using my IP address 0.0.0.0!
arp: 00:30:65:d6:36:8c is using my IP address 0.0.0.0!
arp: 00:20:78:c9:12:55 is using my IP address 0.0.0.0!
arp: 00:20:78:c9:12:55 is using my IP address 0.0.0.0!

uname:

FreeBSD galaxy.anchoragerescue.org 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Tue 
Oct  2 13:11:53 AKDT 2001 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GALAXY  i386

I'm on a cable modem with a static IP. I've never seen this before, any 
suggestions how to stop it?

Beech


-- 
Micro$oft: Where can we make you go today?
---
 Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED]
/\   ASCII Ribbon Campaign  | Anchorage Gospel Rescue Mission
\ / - NO HTML/RTF in e-mail  | P.O. Box 230510
 X  - NO Word docs in e-mail | Anchorage, AK 99523-0510
/ \ -












To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: gratuituous arp for multiple IP addresses

[Mike Smith]

 
 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 request that we send.

The above is achieved by virtue of sending the ARP request (anyone 
watching ARP messages will learn that we are the address in the "tell 
x.x.x.x" field).  What we're trying to provoke is someone else saying 
x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message 
on our system informing the administrator that someone else is already 
using that IP address.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gratuituous arp for multiple IP addresses

[Rahul Dhesi]

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 in the sending of gratuituous arp
since them to correct the problem, then nothing more needs to be done.

Perhaps it would be useful for 'ifconfig' to have an option to
send a gratuituous arp upon request by the user, without having
to reconfigure any IP address.

Rahul

On Mon, 8 May 2000, Mike Smith 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
  
  Rahul
 
 That won't achieve the desired result, which is to complain if someone 
 _else_ replies to the arp request that we send.
 
 The above is achieved by virtue of sending the ARP request (anyone 
 watching ARP messages will learn that we are the address in the "tell 
 x.x.x.x" field).  What we're trying to provoke is someone else saying 
 x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message 
 on our system informing the administrator that someone else is already 
 using that IP address.
 
 -- 
 \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
 \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
 \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
 
 
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gratuituous arp for multiple IP addresses

[Bill Fenner]

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:12.509125 0:10:4b:cc:83:5f Broadcast arp 42: arp who-has 135.197.2.250 tell 
135.197.2.250

I'm not sure what this says; it's entirely possible that there
are conditions under which it doesn't or it fails for some reason.
For example, there was a certain failure mode with sending multicast
leave messages; the packet would be sent to the chip to be sent and then
the multicast filter would be changed causing the chip to reset and lose
the packet that's currently being transmitted.  Adding an alias shouldn't
cause the chip to be reset so that's not likely to be the exact problem,
but perhaps something similar is happening.

  Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gratuituous arp for multiple IP addresses

[Rahul Dhesi]

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 Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gratuituous arp for multiple IP addresses

[Bill Fenner]

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 hardware address no matter what the
opcode is (i.e. you can update your tables due to a request).  Every IP
stack I've seen implements gratuitous ARP by sending a broadcast request
for itself.  In normal ARP operation, replies are unicast so conceivably
an implementation that doesn't expect a broadcast reply might drop it.
Requests are normally broadcasted, and the ARP processing rules cause
broadcasted requests to update existing tables, so a broadcasted request
is a better choice for a gratuitous arp.

tcpdump hides too much information in an attempt to make things look
pretty; it doesn't show the fact that the MAC information is included
in a gratuitous ARP.

  Bill


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gratuituous arp for multiple IP addresses

[Rahul Dhesi]

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 says that if you have an entry for
 the source IP address you update the hardware address no matter what the
 opcode is (i.e. you can update your tables due to a request).  Every IP
 stack I've seen implements gratuitous ARP by sending a broadcast request
 for itself.  In normal ARP operation, replies are unicast so conceivably
 an implementation that doesn't expect a broadcast reply might drop it.
 Requests are normally broadcasted, and the ARP processing rules cause
 broadcasted requests to update existing tables, so a broadcasted request
 is a better choice for a gratuitous arp.
 
 tcpdump hides too much information in an attempt to make things look
 pretty; it doesn't show the fact that the MAC information is included
 in a gratuitous ARP.
 
   Bill
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

gratuituous arp for multiple IP addresses

[Rahul Dhesi]

I was recently struck by this problem:

   Machine running 3.4-STABLE has multiple IP addresses on each
   of two network interfaces.

   IP addresses on network interfaces are exchanged for debugging.  (de0
   gets the IP addresses that de1 had, and vice versa).  Machine is
   rebooted.

   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 restores connectivity.

I think a possible solution would be for some future release of
FreeBSD-CURRENT to send a gratuituous arp packet, at boot time, for each
IP address on each interface.  

(It appears that FreeBSD does send a gratuituous arp but only for the
primary IP address on each interface -- connectivity to the primary IP
addresses was observed to be intact after the reboot.)

Please correct me if I am making any wrong assumptions.
-- 
Rahul Dhesi [EMAIL PROTECTED] (spam-filtered with RSS and ORBS)
   See my ORBS faq:
  http://www.rahul.net/dhesi/orbs.faq.txt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ARP issues (Arcnet)

[Mike Nowlin]

 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 still works, and I fire it up every so often to
play around with...  68000, 1.5MB RAM, 35MB HD, 5 serial ports.  Runs UUCP
with the best of 'em...)

mike




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ARP issues (Arcnet)

[Max Khon]

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 suggestions are appreciated.

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ARP Failure

[Phil 0. Nature]

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
messages let me know and I'll recreate them)

-- Phil 0. Nature

--BEGIN GEEK CODE BLOCK-
Version: 3.1
GIT d++ s+:+ a C+++ UB+++ P+ L++ E- W++ N+ o+ K- w O-
M-- V PS-- PE++ Y+ PGP t+ 5+ X
R- tv- b++ DI+ D G e++ h r+++ y
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

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

[Larry Lile]

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 on its way.  I have modified the
arp code to go looking for the source-route information only if
the arp comes from a token-ring station and is received on a 
token-ring interface.  The arp-reply packet generated is based
on the type of interface the arp was received on.  I think
the bridge should have changed the arp_hrd type when it forwarded
the packet, while it was changing everything else, but I think
that falls into a religous debate.  Thanks to Mr. Pallfreeman
for helping me debug this and testing my patch.

What this means is: you should be able to arp in both directions
over a token-ring-ethernet (translational|non-translational) bridge.

The inherent brokenness of translational bridging is left as an
exercise for the reader :)

Here's the patch, if someone would be kind enough to commit it.  It
seems to have resolved Mr. Pallfreeman's issue and doesn't seem to
break anything else.

Larry Lile
l...@stdio.com
*** if_ether.c.orig Wed Apr 14 09:54:35 1999
--- if_ether.c  Wed Apr 14 12:50:02 1999
***
*** 560,567 
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
  sdl-sdl_rcf = NULL;
!   /* Save source routing information for Token-ring interfaces, 
if available */
!   if (ea-arp_hrd == htons(ARPHRD_IEEE802)) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0]  0x80)  (((ntohs(th-rcf) 
 0x1f00)  8)  2)) {
sdl-sdl_rcf = ntohs(th-rcf)  0x0080 ? 
--- 560,569 
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
  sdl-sdl_rcf = NULL;
!   /* If we receive an arp from a token-ring station over a 
token-ring nic
!* then try to save the source routing info.
!*/
!   if ((ac-ac_if.if_type == IFT_ISO88025)  (ea-arp_hrd == 
htons(ARPHRD_IEEE802))) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0]  0x80)  (((ntohs(th-rcf) 
 0x1f00)  8)  2)) {
sdl-sdl_rcf = ntohs(th-rcf)  0x0080 ? 
***
*** 578,583 
--- 580,587 
}
th-rcf = sdl-sdl_rcf;

+   } else {
+   sdl-sdl_rcf = NULL;
}
if (rt-rt_expire)
rt-rt_expire = time_second + arpt_keep;
***
*** 647,654 
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
!   switch (ntohs(ea-arp_hrd)) {
!   case ARPHRD_IEEE802:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost, 
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr, 
sizeof(th-iso88025_shost));
--- 651,658 
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
!   switch (ac-ac_if.if_type) {
!   case IFT_ISO88025:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost, 
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr, 
sizeof(th-iso88025_shost));
***
*** 663,669 
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
!   case ARPHRD_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha, 
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);
--- 667,673 
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
!   case IFT_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha, 
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);

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

[Larry Lile]

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 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 on its way.  I have modified the
 arp code to go looking for the source-route information only if
 the arp comes from a token-ring station and is received on a 
 token-ring interface.  The arp-reply packet generated is based
 on the type of interface the arp was received on.  I think
 the bridge should have changed the arp_hrd type when it forwarded
 the packet, while it was changing everything else, but I think
 that falls into a religous debate.  Thanks to Mr. Pallfreeman
 for helping me debug this and testing my patch.
 
 What this means is: you should be able to arp in both directions
 over a token-ring-ethernet (translational|non-translational) bridge.
 
 The inherent brokenness of translational bridging is left as an
 exercise for the reader :)
 
 Here's the patch, if someone would be kind enough to commit it.  It
 seems to have resolved Mr. Pallfreeman's issue and doesn't seem to
 break anything else.
 
 Larry Lile
 l...@stdio.com
 
*** if_ether.c.orig Mon Mar  8 13:22:41 1999
--- if_ether.c  Wed Apr 14 14:43:41 1999
***
*** 559,566 
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
  sdl-sdl_rcf = NULL;
!   /* Save source routing information for Token-ring interfaces, 
if available */
!   if (ea-arp_hrd == htons(ARPHRD_IEEE802)) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0]  0x80)  (((ntohs(th-rcf) 
 0x1f00)  8)  2)) {
sdl-sdl_rcf = ntohs(th-rcf)  0x0080 ? 
--- 559,568 
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
  sdl-sdl_rcf = NULL;
!   /* If we receive an arp from a token-ring station over a 
token-ring nic
!* then try to save the source routing info.
!*/
!   if (ac-ac_if.if_type == IFT_ISO88025) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0]  0x80)  (((ntohs(th-rcf) 
 0x1f00)  8)  2)) {
sdl-sdl_rcf = ntohs(th-rcf)  0x0080 ? 
***
*** 577,582 
--- 579,586 
}
th-rcf = sdl-sdl_rcf;

+   } else {
+   sdl-sdl_rcf = NULL;
}
if (rt-rt_expire)
rt-rt_expire = time_second + arpt_keep;
***
*** 646,653 
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
!   switch (ntohs(ea-arp_hrd)) {
!   case ARPHRD_IEEE802:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost, 
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr, 
sizeof(th-iso88025_shost));
--- 650,657 
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
!   switch (ac-ac_if.if_type) {
!   case IFT_ISO88025:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost, 
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr, 
sizeof(th-iso88025_shost));
***
*** 662,668 
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
!   case ARPHRD_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha, 
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);
--- 666,672 
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
!   case IFT_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha, 
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);

Bad, reliable crash: Julian's oltr stuff ARP

[Ian Pallfreeman]

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 the box stay up long enough for me to do a
make world and get to grips with all this EGCS, uh, fun. This isn't a true
solution, obviously.

The ethernet segment to which the box is connected has lots of non-IP traffic
(DECNET, Novell, etc), but I didn't expect to find token ring stuff on it. :-)

Ian.

*** if_ether.c.orig Mon Apr 12 16:11:12 1999
--- if_ether.c  Mon Apr 12 16:13:22 1999
***
*** 435,442 
 panic(arpintr);
 if (m-m_len = sizeof(struct arphdr) 
 (ar = mtod(m, struct arphdr *)) 
!   (ntohs(ar-ar_hrd) == ARPHRD_ETHER || 
!  ntohs(ar-ar_hrd) == ARPHRD_IEEE802) 
 m-m_len =
   sizeof(struct arphdr) + 2 * ar-ar_hln + 2 * ar-ar_pln)

--- 435,441 
 panic(arpintr);
 if (m-m_len = sizeof(struct arphdr) 
 (ar = mtod(m, struct arphdr *)) 
!   ntohs(ar-ar_hrd) == ARPHRD_ETHER 
 m-m_len =
   sizeof(struct arphdr) + 2 * ar-ar_hln + 2 * ar-ar_pln)


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x8
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc017e590
stack pointer   = 0x10:0xc02248d8
frame pointer   = 0x10:0xc0224928
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres type 0x1b
= DPL 0, press 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = 
kernel: type 12 trap, code=0
Stopped at  in_arpinput+0x264:  cmpb$0,0x8(%ecx)
db tr
in_arpinput(c0744100,0,0,c01ee601,c01ee5a3) at in_arpinput+0x264
arpintr(c01ee5a3,8000,10,10,0) at arpintr+0xb4
swi_net_next() at swi_net_next
db show registers
cs 0x8
ds  0x7e8b0010
es0x10
ss0x10
eax  0x600
ecx  0
edx  0
ebx 0xc0a02490
esp 0xc02255ec  __set_pcidevice_set_sym_ide_pci_device+0x2fc0
ebp 0xc022563c  __set_pcidevice_set_sym_ide_pci_device+0x3010
esi 0xc073c820
edi 0xc0a2d600
eip 0xc017e3d4  in_arpinput+0x264
efl0x10246
in_arpinput+0x264:  cmpb$0,0x8(%ecx)
db panic

Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #1: Mon Apr 12 16:13:32 BST 1999
i...@trauma:/usr/src/sys/compile/TRAUMA
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 400910920 Hz
CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping=2
  
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory  = 134217728 (131072K bytes)
avail memory = 127995904 (124996K bytes)
Preloaded elf kernel kernel at 0xc0291000.
Pentium Pro MTRR support enabled, default memory type is uncacheable
ccd0: Concatenated disk driver
Probing for devices on PCI bus 0:
chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0
chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0
chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0
ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1
chip3: Intel 82371AB Power management controller rev 0x02 on pci0.7.3
ahc0: Adaptec 2940 Ultra SCSI adapter rev 0x00 int a irq 10 on pci0.15.0
ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs
fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 12 on 
pci0.17.0
fxp0: Ethernet address 00:90:27:10:2b:ea
Probing for devices on PCI bus 1:
vga0: S3 model 8904 graphics accelerator rev 0x01 int a irq 255 on pci1.0.0
Probing for devices on the ISA bus:
sc0 on isa
sc0: VGA color 16 virtual consoles, flags=0x0
atkbdc0 at 0x60-0x6f on motherboard
atkbd0 irq 1 on isa
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16550A, console
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): Maxtor 90432D2
wd0: 4121MB (8440992 sectors), 8374 cyls, 16 heads, 63 S/T, 512 B/S
wdc1 at 0x170-0x177 irq 15 on isa
wdc1: unit 0 (wd2): QUANTUM FIREBALL_TM3840A
wd2: 3681MB (7539840 sectors), 7480 cyls, 16 heads, 63 S/T, 512 B/S
wdc1: unit 1 (wd3): QUANTUM FIREBALL_TM3840A
wd3: 3681MB (7539840 sectors), 7480 cyls, 16 heads, 63 S/T, 512 B/S
ppc0 at 0x378 irq 7 on isa
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: PLIP network 

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

[Larry Lile]

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 damaged.  Is there a token-ring-ethernet bridge on
your network?  

What was it doing in in_arpinput when it panic'd?

Larry Lile
l...@stdio.com


On Mon, 12 Apr 1999, Ian Pallfreeman wrote:

 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 the box stay up long enough for me to do a
 make world and get to grips with all this EGCS, uh, fun. This isn't a true
 solution, obviously.
 
 The ethernet segment to which the box is connected has lots of non-IP traffic
 (DECNET, Novell, etc), but I didn't expect to find token ring stuff on it. :-)
 
 Ian.
 
 *** if_ether.c.orig Mon Apr 12 16:11:12 1999
 --- if_ether.c  Mon Apr 12 16:13:22 1999
 ***
 *** 435,442 
panic(arpintr);
if (m-m_len = sizeof(struct arphdr) 
(ar = mtod(m, struct arphdr *)) 
 !   (ntohs(ar-ar_hrd) == ARPHRD_ETHER || 
 !  ntohs(ar-ar_hrd) == ARPHRD_IEEE802) 
m-m_len =
  sizeof(struct arphdr) + 2 * ar-ar_hln + 2 * ar-ar_pln)
 
 --- 435,441 
panic(arpintr);
if (m-m_len = sizeof(struct arphdr) 
(ar = mtod(m, struct arphdr *)) 
 !   ntohs(ar-ar_hrd) == ARPHRD_ETHER 
m-m_len =
  sizeof(struct arphdr) + 2 * ar-ar_hln + 2 * ar-ar_pln)
 
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x8
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc017e590
 stack pointer   = 0x10:0xc02248d8
 frame pointer   = 0x10:0xc0224928
 code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres type 0x1b
   = DPL 0, press 1, def32 1, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = Idle
 interrupt mask  = 
 kernel: type 12 trap, code=0
 Stopped at  in_arpinput+0x264:  cmpb$0,0x8(%ecx)
 db tr
 in_arpinput(c0744100,0,0,c01ee601,c01ee5a3) at in_arpinput+0x264
 arpintr(c01ee5a3,8000,10,10,0) at arpintr+0xb4
 swi_net_next() at swi_net_next
 db show registers
 cs 0x8
 ds  0x7e8b0010
 es0x10
 ss0x10
 eax  0x600
 ecx  0
 edx  0
 ebx 0xc0a02490
 esp 0xc02255ec  __set_pcidevice_set_sym_ide_pci_device+0x2fc0
 ebp 0xc022563c  __set_pcidevice_set_sym_ide_pci_device+0x3010
 esi 0xc073c820
 edi 0xc0a2d600
 eip 0xc017e3d4  in_arpinput+0x264
 efl0x10246
 in_arpinput+0x264:  cmpb$0,0x8(%ecx)
 db panic
 
 Copyright (c) 1992-1999 The FreeBSD Project.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
   The Regents of the University of California. All rights reserved.
 FreeBSD 4.0-CURRENT #1: Mon Apr 12 16:13:32 BST 1999
 i...@trauma:/usr/src/sys/compile/TRAUMA
 Timecounter i8254  frequency 1193182 Hz
 Timecounter TSC  frequency 400910920 Hz
 CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0x652  Stepping=2
   
 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
 real memory  = 134217728 (131072K bytes)
 avail memory = 127995904 (124996K bytes)
 Preloaded elf kernel kernel at 0xc0291000.
 Pentium Pro MTRR support enabled, default memory type is uncacheable
 ccd0: Concatenated disk driver
 Probing for devices on PCI bus 0:
 chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0
 chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0
 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0
 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1
 chip3: Intel 82371AB Power management controller rev 0x02 on pci0.7.3
 ahc0: Adaptec 2940 Ultra SCSI adapter rev 0x00 int a irq 10 on pci0.15.0
 ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs
 fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 12 on 
 pci0.17.0
 fxp0: Ethernet address 00:90:27:10:2b:ea
 Probing for devices on PCI bus 1:
 vga0: S3 model 8904 graphics accelerator rev 0x01 int a irq 255 on pci1.0.0
 Probing for devices on the ISA bus:
 sc0 on isa
 sc0: VGA color 16 virtual consoles, flags=0x0
 atkbdc0 at 0x60-0x6f on motherboard
 atkbd0 irq 1 on isa
 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
 sio0: type 16550A, console
 sio1 at 0x2f8-0x2ff irq 3 on isa
 sio1: type 16550A
 fdc0 at 0x3f0-0x3f7

Re: arp.

[Andy V. Oleynik]

andrea wrote:

 I have to add a gateway to my net for experimental reasons.
 Actually there are : a main-router that works as interface to the Internet,
 and some hosts on my sub net.

 Internet-MyRouterMySubNet

 NOw i need to configure one host of MYSubNet to act as a gatway for the
 secondary subnet.
 Both the 1SubNet and 2 SubNEt share the same ip-range.

  Internet-MyRouterMySubNet-My2SubNet

As I understood U have smth like this :
Internet-MyRouterMySubNet
   |2ndRouter-My2SubNet
Then U have to cut My2SubNet from ur  MySubNet and configure
routes to appropriate subnets on appropriate hosts. As long as ur 2ndsubnet
is part of ur mainsubnet  the hosts from  2ndsubnet will be seen from internet

 wise a versa. U may need to run DNS for reverse zone of ur  My2SubNet




 All the sub.net have to be seen from the Internet so I'll need to add a
 route to MainRouter in order to route the Secondary Subnet.
 The problem is that i cannot change configuration of the mainroute,so i


in fact this isnt  big problem as soon as U have properly configured
subnets:) . Correct me if I wrong.

 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,without broke any
 other subnet connected to the same host.?
 thank you!

 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-questions in the body of the message

--
WBW  Andy V. Oleynik  (When U work in virtual office
   U have good chance to obtain virtual money Ж%-)





To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: arp.

[Crist J. Clark]

Andy V. Oleynik wrote,
[Charset koi8-r unsupported, filtering to ASCII...]
 andrea wrote:
 
  I have to add a gateway to my net for experimental reasons.
  Actually there are : a main-router that works as interface to the Internet,
  and some hosts on my sub net.
 
  Internet-MyRouterMySubNet
 
  NOw i need to configure one host of MYSubNet to act as a gatway for the
  secondary subnet.
  Both the 1SubNet and 2 SubNEt share the same ip-range.
 
   Internet-MyRouterMySubNet-My2SubNet
 
 As I understood U have smth like this :
 Internet-MyRouterMySubNet
|2ndRouter-My2SubNet
 Then U have to cut My2SubNet from ur  MySubNet and configure
 routes to appropriate subnets on appropriate hosts. As long as ur 2ndsubnet
 is part of ur mainsubnet  the hosts from  2ndsubnet will be seen from internet
 
  wise a versa. U may need to run DNS for reverse zone of ur  My2SubNet

DNS has nothing really to do with this problem. I believe the original
poster is describing the following (this may be what the second poster
meant to write, but proportional fonts, tab damage, or his character
set wiped it out),

Internet--PrimaryRouter--SubNet1
|
 SecondaryRouter-SubNet2

 
 
  All the sub.net have to be seen from the Internet so I'll need to add a
  route to MainRouter in order to route the Secondary Subnet.
  The problem is that i cannot change configuration of the mainroute,so i
 
 
 in fact this isnt  big problem as soon as U have properly configured
 subnets:) . Correct me if I wrong.

This is a problem. You are wrong. But back to the original poster, why
can you not change the configuration on the Primary Router[0]? If this is
your network, and you want to be able to do things like this, you need
to be able to change the Primary Router configuration.

To the second poster, when the Primary Router receives a packet
destined for a machine on SubNet1 or SubNet2, since the Router
believes all of those machines are still on its LAN, it will try to
use the MAC address (layer 2) to send the packet directly to the
machine. However, now this machine has been moved behind the Secondary
Router. The Secondary Router is not listening for other machines'
packets at layer 2 (in a typical router setup), so 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 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 subnet connected to the same host.?

It is possible. But I am unaware of a tool to do this[1] (which does not
mean there is not one). Might you be better off building a 'new' net
behind your Secondary Router? Say using NAT and a 10.0.0 subnet?

[0] All you need to do on the router is add a route to Secondary
Router for IPs on SubNet2. All you need is the address for the
Secondary Router and a subnet mask.

[1] The Secondary Router would not actually be doing routing in this
case. It's acting more like a switch. You did not really tell us why
you are doing this. Would getting a switch be a better option for you?
-- 
Crist J. Clark   cjcl...@home.com


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: arp.

[Andy V. Oleynik]

Crist J. Clark wrote:

 Andy V. Oleynik wrote,
 [Charset koi8-r unsupported, filtering to ASCII...]
  andrea wrote:
 
   I have to add a gateway to my net for experimental reasons.
   Actually there are : a main-router that works as interface to the 
   Internet,
   and some hosts on my sub net.
  
   Internet-MyRouterMySubNet
  
   NOw i need to configure one host of MYSubNet to act as a gatway for the
   secondary subnet.
   Both the 1SubNet and 2 SubNEt share the same ip-range.
  
Internet-MyRouterMySubNet-My2SubNet
 
  As I understood U have smth like this :
  Internet-MyRouterMySubNet
 |2ndRouter-My2SubNet


I mean 2ndrouter is on  MySubNet, sorrey for unclearity:)

  Then U have to cut My2SubNet from ur  MySubNet and configure
  routes to appropriate subnets on appropriate hosts. As long as ur 2ndsubnet
  is part of ur mainsubnet  the hosts from  2ndsubnet will be seen from 
  internet
 
   wise a versa. U may need to run DNS for reverse zone of ur  My2SubNet

 DNS has nothing really to do with this problem. I believe the original


I said U may not U must. At least I  run DNS for revzones of my subnets.

 poster is describing the following (this may be what the second poster
 meant to write, but proportional fonts, tab damage, or his character
 set wiped it out),

 Internet--PrimaryRouter--SubNet1
 |
  SecondaryRouter-SubNet2

  
  
   All the sub.net have to be seen from the Internet so I'll need to add a
   route to MainRouter in order to route the Secondary Subnet.
   The problem is that i cannot change configuration of the mainroute,so i
  
 
  in fact this isnt  big problem as soon as U have properly configured
  subnets:) . Correct me if I wrong.

 This is a problem. You are wrong. But back to the original poster, why

Sorrey Crist, but there is no need to connect 2nd router to 1st. If U have to
have 2nd subnet just insert 2nd NIC into 1st router and as I sad above
configure ur subnets (with appropriate routes on router off cause 
defaulterouter on hosts on subnets :).



 can you not change the configuration on the Primary Router[0]? If this is
 your network, and you want to be able to do things like this, you need
 to be able to change the Primary Router configuration.

 To the second poster, when the Primary Router receives a packet
 destined for a machine on SubNet1 or SubNet2, since the Router
 believes all of those machines are still on its LAN, it will try to
 use the MAC address (layer 2) to send the packet directly to the


Is this true if 1strouter knows that a route to 2ndsubnet is throught 2ndrouter
which is
on same subnet as 1strouter?

 machine. However, now this machine has been moved behind the Secondary
 Router. The Secondary Router is not listening for other machines'


why not if it's configured as gateway to 2ndsnet?

 packets at layer 2 (in a typical router setup), so 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 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 subnet connected to the same host.?

 It is possible. But I am unaware of a tool to do this[1] (which does not
 mean there is not one). Might you be better off building a 'new' net
 behind your Secondary Router? Say using NAT and a 10.0.0 subnet?

 [0] All you need to do on the router is add a route to Secondary
 Router for IPs on SubNet2. All you need is the address for the
 Secondary Router and a subnet mask.

 [1] The Secondary Router would not actually be doing routing in this
 case. It's acting more like a switch. You did not really tell us why
 you are doing this. Would getting a switch be a better option for you?
 --
 Crist J. Clark   cjcl...@home.com

--
WBW  Andy V. Oleynik  (When U work in virtual office
   U have good chance to obtain virtual money Ж%-)





To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: arp.

[Curt Sampson]

On Mon, 5 Apr 1999, andrea wrote:

 [etc.]

If I read you correctly, what you want to do is something like this:

 internet
|
main router
192.168.1.1/24  
|
|-- other hosts on 192.168.1.0/25 subnet
|
192.168.1.2/25
sub-router 
192.168.1.129/25
|
|-- other hosts on 192.168.1.128/25 subnet
|

In other words, you have split your network into two subnets, but
because you have no control over the `main router' above, you cannot
inform it of the new subnet mask, so 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 with its own address. The host that
requested the arp then sends all packets to the sub-router, and
normal routing gets it to its destination.

The question is, does NetBSD do this properly? I think it does,
but I'm lacking the AUI/10base-T transceiver I need to test this
out right now. However, in theory, if you have a host 192.168.1.130
that needs to talk to the main router, you type the following
command on the sub-router:

arp -s 192.168.1.130 sub-router's MAC address pub

(The sub-router's MAC address can be gotten from an `ifconfig -a'
or `netstat -i'; it will be a sequence of six hex numbers separated
by colons, such as `8:0:20:1f:77:e0'.)

The unfortunate part about this is that you have to add a separate
arp entry for each host you want to proxy-arp for. On a cisco
router, the proxy-arp option allows you to arp for anything it
knows how to route to. This feature wouldn't be too hard to add to
NetBSD, actually; you'd just have to modify arplookup to generate
and add a new (pub, temp) arp entry for any IP address it can find
a route for in its routing tables. (This would be controlled by a
sysctl that would default to off, of course.) I may look at doing
this after the 1.4 release. Or someone else could do it and save
me the trouble. :-)

cjs
-- 
Curt Sampson  c...@cynic.net   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

arp.

[andrea]

I have to add a gateway to my net for experimental reasons.
Actually there are : a main-router that works as interface to the Internet,
and some hosts on my sub net.

Internet-MyRouterMySubNet

NOw i need to configure one host of MYSubNet to act as a gatway for the
secondary subnet.
Both the 1SubNet and 2 SubNEt share the same ip-range.

 Internet-MyRouterMySubNet-My2SubNet

All the sub.net have to be seen from the Internet so I'll need to add a
route to MainRouter in order to route the Secondary Subnet.
The problem 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 arp request only on a single subnet,without broke any
other subnet connected to the same host.?
thank you!










To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: arp.

[Robin Melville]

At 12:22 pm +0100 5/4/99, andrea wrote:
I have to add a gateway to my net for experimental reasons.
Actually there are : a main-router that works as interface to the Internet,
and some hosts on my sub net.

Internet-MyRouterMySubNet

NOw i need to configure one host of MYSubNet to act as a gatway for the
secondary subnet.
Both the 1SubNet and 2 SubNEt share the same ip-range.

 Internet-MyRouterMySubNet-My2SubNet

All the sub.net have to be seen from the Internet so I'll need to add a
route to MainRouter in order to route the Secondary Subnet.
The problem 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 arp request only on a single subnet,without broke any
other subnet connected to the same host.?
thank you!

Assuming that these are IP routers and not ethernet switches, the arp
tables aren't particularly relevent. If the main router is running 'routed'
or some other RIP routing daemon, all you need to do is run a similar
daemon and your new subnet route will be propagated. Alternatively, or
essentially if you are using unregistered IP, you could use 'natd' on
'MyRouter' to masquerade the internal addresses onto the external interface.

The handbook pages on natd make it very easy to set up.

Good luck

Robin.

--
Robin Melville, Addiction Information Services
Nottingham Alcohol  Drug Team
Tel:  +44 (0)115 952 9478   Fax:  +44 (0)115 952 9421
work: rob...@nadt.org.ukhome: rob...@innotts.co.uk
Pages: http://www.innotts.co.uk/~robmel(home page)
   http://www.innotts.co.uk/nadt   (substance misuse pages)
--




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?

[Luigi Rizzo]

 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?

[Stefan Esser]

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?

[Christopher Masto]

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?

[Archie Cobbs]

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

Network/ARP problem? Maybe pn driver?

[Christopher Masto]

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.

For example, if A tries to ping B, A appears to get no response,
saying that B is down.  But if B pings A, A is now able to ping B.
But A still can't ping C until C pings A as well.

All (two dozen) other machines on the network have been working fine,
some of them for years.  I have ruled out problems with the hub,
cabling, etc., by swapping them.  I have not swapped out the network
card (a PNIC-based NetGear 10/100), but it does work under Windows on
this same machine.

Here is what the routing table looks like during one of these episodes:

DestinationGatewayFlags Refs Use Netif Expire
default209.54.21.129  UGSc00  pn0
127.0.0.1  127.0.0.1  UH  00  lo0
209.54.21  link#1 UC  00  pn0
209.54.21.129  0:e0:b0:e2:bc:79   UHLW10  pn0970
209.54.21.142  link#1 UHRLW   07  pn0
209.54.21.181  link#1 UHRLW   07  pn0
209.54.21.199  0:60:97:a3:63:e6   UHLW1   44  pn0   1159

At this time, it is possible to talk to .129 and .199, but not .142 or
.181.  Attempts to ping other addresses result in them appearing in
the table with link#1 entries.  If I ping A from the other machine,
the link#1 is replaced by the correct hardware address.

Here's the ARP table:

bertha% arp -n -a
? (209.54.21.129) at 0:e0:b0:e2:bc:79
? (209.54.21.142) at (incomplete)
? (209.54.21.181) at (incomplete)
? (209.54.21.199) at 0:60:97:a3:63:e6

bertha% arp -n 209.54.21.142
? (209.54.21.142) at (incomplete)

It's as if machine A isn't hearing the ARP responses.  Here is part of
a tcpdump done from another machine on the same segment during this
time:

17:07:06.751678 arp who-has 209.54.21.142 tell 209.54.21.233
17:07:06.751862 arp reply 209.54.21.142 is-at 0:60:97:a3:63:af
17:07:16.767849 arp who-has 209.54.21.142 tell 209.54.21.233
17:07:16.767997 arp reply 209.54.21.142 is-at 0:60:97:a3:63:af
17:07:26.783799 arp who-has 209.54.21.142 tell 209.54.21.233
17:07:26.783928 arp reply 209.54.21.142 is-at 0:60:97:a3:63:af
17:07:46.796125 arp who-has 209.54.21.142 tell 209.54.21.233
17:07:46.796279 arp reply 209.54.21.142 is-at 0:60:97:a3:63:af

The ARP is being sent out, and so is the response, but it's not being
picked up for some reason.

Here's a boot -v from the machine (at least, the part that fit in the
dmesg buffer):

06-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
chip0: Intel 82439 rev 0x01 on pci0.0.0
found- vendor=0x8086, dev=0x7000, revid=0x00
class=06-01-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
chip1: Intel 82371SB PCI to ISA bridge rev 0x00 on pci0.7.0
I/O Recovery Timing: 8-bit 3 clocks, 16-bit 2 clocks
Extended BIOS: enabled
Lower BIOS: disabled
Coprocessor IRQ13: enabled
Mouse IRQ12: disabled
Interrupt Routing: A: IRQ9, B: IRQ12, C: disabled, D: IRQ11
MB0: IRQ15, MB1: 
found- vendor=0x8086, dev=0x7010, revid=0x00
class=01-01-80, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[0]: type 4, range 32, base 9000, size  4
ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1
intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1
intel_piix_status: primary master fastDMAonly disabled, pre/post enabled,
intel_piix_status:  IORDY sampling enabled,
intel_piix_status:  fast PIO enabled
intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1
intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled,
intel_piix_status:  IORDY sampling disabled,
intel_piix_status:  fast PIO disabled
ide_pci: busmaster 0 status: 04 from port: 9002
intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 3
intel_piix_status: secondary master fastDMAonly disabled, pre/post enabled,
intel_piix_status:  IORDY sampling enabled,
intel_piix_status:  fast PIO enabled
intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 3
intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled,
intel_piix_status:  IORDY sampling disabled,
intel_piix_status:  fast PIO disabled
ide_pci: busmaster 1 status: 04 from port: 900a
found- vendor=0x8086, dev=0x7020, revid=0x00

Re: Network/ARP problem? Maybe pn driver?

[Bill Fenner]

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?

[Christopher Masto]

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?

[Bill Paul]

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?

[Bill Fenner]

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?

[Christopher Masto]

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?

[Archie Cobbs]

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?

[Mike Smith]

 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?

[Christopher Masto]

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