Re: dhcpcd doesn't remove alias address on interface-down?
On Fri, 31 Jul 2015, Roy Marples wrote: This is not normal or expected! I'm very bogged down in my personal life atm, but it would help if you could capture a tcpdump of the bootp messages on the client whilst rebooting the router. dhcpcd output with the debug directive in dhcpcd.conf would be of benefit as well whilst the reboot happens. I can get the tcpdump info with tcpdump -i re0 -s 2000 port bootps or port bootpc But how can I capture the dhcpcd output? Even with -w it forks to the background as soon as it has an address, so it doesn't log any further info in stdout/stderr In any case, the situation might be more complicated. I just rebooted, and got one of the earlier addresses (192.168.1.3) and dhcpcd reported re0: IP address 192.168.1.3/24 already exists I don't know why, but all those addresses and aliases seem to have survived the dhcpcd restart. So I guess I need to find some time when I can conduct some more detailed experiments. :) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -
Re: dhcpcd doesn't remove alias address on interface-down?
Hi Paul On 2015-07-31 00:43, Paul Goyette wrote: (Running amd64 7.99.19 with kernel and userland from sources that were updated on 2015-06-26 at 00:40:42 UTC) I have a fairly simple network environment, with a single internet connection via a ISP-supplied WiFi/NAT router. I have _nothing_ in my /etc/ifconfig.re0 file, and /etc/rc.conf has the following line dhcpcd=YES ; dhcpcd_flags="-C resolv.conf -L" (The -C option is there because the ISP has [at least] one broken nameserver, so I hard-code resolv.conf to point to known good servers!) Occassionally I need to reboot the router. It seems that when I do, I end up with a new "alias" entry for the interface, but the previous alias is still there. After a while, I seem to be accumulating aliases: # ifconfig re0: flags=8843 mtu 1500 ... inet 192.168.1.10 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.9 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.7 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.6 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 ... # arp -an ? (192.168.1.1) at 18:1e:78:97:11:ad on re0 ? (192.168.1.3) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.6) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.7) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.9) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.10) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.13) at a0:a8:cd:0d:e7:ec on re0 # Since the reboot also causes other devices to re-acquire addresses, I'm having difficulty talking to anything that gets one of my earlier alias addresses. :) Is this expected/normal behavior? If not, can it be corrected? :) This is not normal or expected! I'm very bogged down in my personal life atm, but it would help if you could capture a tcpdump of the bootp messages on the client whilst rebooting the router. dhcpcd output with the debug directive in dhcpcd.conf would be of benefit as well whilst the reboot happens. Thanks Roy
dhcpcd doesn't remove alias address on interface-down?
(Running amd64 7.99.19 with kernel and userland from sources that were updated on 2015-06-26 at 00:40:42 UTC) I have a fairly simple network environment, with a single internet connection via a ISP-supplied WiFi/NAT router. I have _nothing_ in my /etc/ifconfig.re0 file, and /etc/rc.conf has the following line dhcpcd=YES ; dhcpcd_flags="-C resolv.conf -L" (The -C option is there because the ISP has [at least] one broken nameserver, so I hard-code resolv.conf to point to known good servers!) Occassionally I need to reboot the router. It seems that when I do, I end up with a new "alias" entry for the interface, but the previous alias is still there. After a while, I seem to be accumulating aliases: # ifconfig re0: flags=8843 mtu 1500 ... inet 192.168.1.10 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.9 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.7 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.6 netmask 0xff00 broadcast 192.168.1.255 inet alias 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 ... # arp -an ? (192.168.1.1) at 18:1e:78:97:11:ad on re0 ? (192.168.1.3) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.6) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.7) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.9) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.10) at 30:b5:c2:05:0e:66 on re0 permanent ? (192.168.1.13) at a0:a8:cd:0d:e7:ec on re0 # Since the reboot also causes other devices to re-acquire addresses, I'm having difficulty talking to anything that gets one of my earlier alias addresses. :) Is this expected/normal behavior? If not, can it be corrected? :) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -
Re: agr issue in netbsd-7
> I tried to configure a port channel (agr0). > When I configure the port channel only with bnx0 or only with bnx1 > everything works. If I use bnx0 and bnx1, the Cisco switch sets one of > the two links to suspended mode. If I'm not terribly mistaken, the problem is that both physical interfaces are supposed to pick one of the ethernet addresses and use it as the source MAC for all the traffic passed on the aggregate logical interface. Apparently, the bnx driver in NetBSD doesn't (yet) have the ability to change the source MAC address. > Partner's information: > > LACP portAdmin Oper Port Port > Port Flags Priority Dev ID Age key Key Number State > Gi7/44 SA 32768 0019.b9b0.f145 14s 0x0 0xD0 0x1 0x3D > Gi7/46 SA 32768 0019.b9b0.f143 14s 0x0 0xD0 0x4 0xD > > Maybe the problem is the device ID. I think the device ID should be > the same for all ports in a port channel. Yep, I think that's correct. Regards, - Håvard
daily CVS update output
Updating src tree: P src/crypto/external/bsd/openssh/dist/auth2-chall.c P src/distrib/sets/lists/base/mi P src/distrib/sets/lists/debug/mi P src/distrib/sets/lists/tests/mi P src/distrib/sets/lists/xcomp/md.amd64 P src/distrib/sets/lists/xdebug/md.amd64 P src/etc/mtree/NetBSD.dist.tests P src/external/mit/xorg/server/drivers/xf86-video-r128/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/int10/Makefile P src/lib/libc/time/strptime.c P src/sbin/ifconfig/ifconfig.c P src/share/man/man7/tests.atf.7 P src/share/man/man7/tests.kyua.7 P src/share/mk/bsd.lib.mk P src/sys/arch/arm/broadcom/bcm2835_dmac.c P src/sys/arch/arm/broadcom/bcm2835_dwctwo.c P src/sys/arch/arm/broadcom/bcm2835_emmc.c P src/sys/arch/arm/broadcom/bcm2835_intr.h P src/sys/arch/arm/broadcom/bcm2835_mbox.c P src/sys/arch/arm/broadcom/bcm2835_plcom.c P src/sys/arch/arm/broadcom/bcm2835_spi.c P src/sys/arch/arm/broadcom/bcm2835_tmr.c P src/sys/arch/arm/imx/imxuart.c P src/sys/arch/arm/nvidia/tegra_car.c P src/sys/arch/arm/nvidia/tegra_sdhc.c P src/sys/arch/sun68k/stand/netboot/conf.c P src/sys/dev/adb/adb_kbd.c P src/sys/dev/sdmmc/sdhc.c P src/sys/dev/sdmmc/sdhcreg.h P src/sys/dev/sdmmc/sdhcvar.h P src/sys/external/bsd/vchiq/dist/interface/vchiq_arm/vchiq_kmod_netbsd.c P src/tests/net/Makefile U src/tests/net/arp/Makefile U src/tests/net/arp/t_arp.sh U src/tests/net/arp/t_dad.sh P src/tests/usr.bin/xlint/lint1/Makefile U src/tests/usr.bin/xlint/lint1/d_type_question_colon.c P src/usr.bin/xlint/lint1/err.c P src/usr.bin/xlint/lint1/tree.c P src/usr.sbin/arp/Makefile P src/usr.sbin/arp/arp.c U src/usr.sbin/arp/arp_hostops.c U src/usr.sbin/arp/arp_rumpops.c U src/usr.sbin/arp/prog_ops.h Updating xsrc tree: P xsrc/external/mit/xf86-video-r128/dist/src/r128.h P xsrc/external/mit/xf86-video-r128/dist/src/r128_driver.c P xsrc/external/mit/xf86-video-r128/dist/src/r128_output.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Thu Jul 30 04:35:10 2015 SUP Scan for current completed at Thu Jul 30 06:22:35 2015 SUP Scan for mirror starting at Thu Jul 30 06:22:35 2015 SUP Scan for mirror completed at Thu Jul 30 10:56:50 2015 Updating file list: cp: /tmp/ls-lRA.gz: No such file or directory -rw-rw-r-- 1 srcmastr netbsd 51137090 Jul 30 13:43 ls-lRA.gz
agr issue in netbsd-7
hello, I tried to configure a port channel (agr0). When I configure the port channel only with bnx0 or only with bnx1 everything works. If I use bnx0 and bnx1, the Cisco switch sets one of the two links to suspended mode. bnx0: flags=8843 mtu 1500 capabilities=3f00 capabilities=3f00 enabled=0 ec_capabilities=7 ec_enabled=0 address: 00:19:b9:b0:f1:45 media: Ethernet autoselect (1000baseT full-duplex,master) status: active bnx1: flags=8843 mtu 1500 capabilities=3f00 capabilities=3f00 enabled=0 ec_capabilities=7 ec_enabled=0 address: 00:19:b9:b0:f1:43 media: Ethernet autoselect (1000baseT full-duplex) status: active agr0: flags=8843 mtu 1500 capabilities=3f00 capabilities=3f00 enabled=0 agrport: bnx0, flags=0x3 agrport: bnx1, flags=0x0 address: 00:19:b9:b0:f1:45 inet 139.18.25.36 netmask 0xfff8 broadcast 139.18.25.39 inet6 fe80::219:b9ff:feb0:f145%agr0 prefixlen 64 scopeid 0x6 The cisco catalyst reports: Channel group 4 neighbors Partner's information: LACP portAdmin Oper Port Port Port Flags Priority Dev ID AgekeyKeyNumber State Gi7/44SA 32768 0019.b9b0.f145 14s0x00xD0 0x1 0x3D Gi7/46SA 32768 0019.b9b0.f143 14s0x00xD0 0x4 0xD Maybe the problem is the device ID. I think the device ID should be the same for all ports in a port channel. Can someone take a look at the problem? Thank you for your efforts Regards Uwe
