The content of this topic has been archived on 4 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
I seeing the same message throughout my system log...
Sun Oct 22 21:48:51 2017 daemon.warn odhcpd[1027]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128 I have the impression this is a ipv6 dhcp request that is being answered by the router. But I just don't understand why it doesn't stop. And the machine doesn't show up in the list of attached devices in luci.
Thanks in advance for any insights!
How often do you see this log entry. Could it be tied to the lease length of a DHCPv6 address?
If it isn't showing up on your LuCI DHCPv6 lease list, then probably the device has a bad DHCPv6 client, and although the router has offered an address, the client isn't acknowledging it. The last part of the DUID is usually the MAC address of the device.
I would suggest looking at your ARP table on the router for the device who's MAC address ends in 22:b8 And you should see an IPv4 address that is associated with that MAC address.
I was thinking the same thing about the lease length but the defaults are as provided. The client is a MS Server 2012 machine. It does have a IPv4 address listed.
I literally see it every 20 seconds in the log.
Tue Oct 31 21:32:17 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:32:49 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:33:20 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000300013c52822aeecf on br-lan: ok fdbd:3bc1:f0fd::b46/128
Tue Oct 31 21:35:20 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000300013c52822aeecf on br-lan: ok fdbd:3bc1:f0fd::b46/128
Tue Oct 31 21:37:20 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000300013c52822aeecf on br-lan: ok fdbd:3bc1:f0fd::b46/128
Tue Oct 31 21:38:53 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:38:54 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:38:55 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:38:57 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:39:01 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:39:09 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000100011a916c7c180373d922b8 on br-lan: ok fdbd:3bc1:f0fd::db2/128
Tue Oct 31 21:39:20 2017 daemon.warn odhcpd[1059]: DHCPV6 SOLICIT IA_NA from 000300013c52822aeecf on br-lan: ok fdbd:3bc1:f0fd::b46/128I rebooted my router so lost all my dhcp leases... :-( I need to figure out how to save that stuff across reboots.
Do you think this can be something in the firewall or dhcp config files?
This might be a lame solution, but I ended up just disabling DHCPV6 via https://wiki.openwrt.org/doc/techref/odhcpd
So far, no more DCHPV6 messages...
I feel like I really do not need IPv6 at home that I can think of at the moment.
This might be a lame solution, but I ended up just disabling DHCPV6 via https://wiki.openwrt.org/doc/techref/odhcpd
So far, no more DCHPV6 messages...
I feel like I really do not need IPv6 at home that I can think of at the moment.
LOL I think ipv6 is kinda like the millennium bug. There was all this hootin and hollarin goin on bout how we were gonna be all out of addresses in like i dunno 3 or 4 days. but...... nada
LOL I think ipv6 is kinda like the millennium bug. There was all this hootin and hollarin goin on bout how we were gonna be all out of addresses in like i dunno 3 or 4 days. but...... nada
Actually we have run out of IPv4 addresses. It is _impossible_ to get an IPv4 block in North America. Businesses which need IP addresses, like ISPs have adopted IPv6 in order to expand their customer base.
But IPv6 is not without bugs, and it would appear this DHCPv6 issue is a bug. JR_TTG, have you been able to identify the hosts that are having a problem? (by looking at the MAC address)
I have looked at my log, and I don't see those kind of errors. But then I don't run Windows on my LAN.
(Last edited by cvmiller on 2 Nov 2017, 00:16)
@WWTK That is funny.
@cvmiller It was a SERVER 2012 machine as the client. I'm not sure how to make progress beyond that.
Here is my newest surprise for this thing... This openwrt is a little more tricky than I hoped. lol
[34226.895036] ------------[ cut here ]------------
[34226.899709] WARNING: CPU: 0 PID: 1478 at /home/buildbot/slave-local/bcm53xx_generic/build/build_dir/target-arm_cortex-a9_uClibc-0.9.33.2_eabi/linux-bcm53xx/compat-wireless-2015-03-09/drivers/net/wireless/brcm80211/brcmfmac/core.c:1181 brcmf_netdev_wait_pend8021x+0xf0/0x100 [brcmfmac]()
[34226.925070] Modules linked in: pppoe ppp_async iptable_nat brcmfmac b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt compat brcmutil ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables vfat fat ntfs nls_iso8859_1 nls_cp437 ipv6 arc4 crypto_blkcipher usb_storage xhci_plat_hcd xhci_pci xhci_hcd uhci_hcd ehci_platform ehci_hcd sd_mod scsi_mod ext4 jbd2 mbcache bcma_hcd crypto_hash leds_gpio gpio_button_hotplug usbcore nls_base usb_common
[34227.006727] CPU: 0 PID: 1478 Comm: hostapd Not tainted 3.18.23 #1
[34227.012836] Backtrace:
[34227.015323] [<c0015414>] (dump_backtrace) from [<c0015620>] (show_stack+0x18/0x1c)
[34227.022933] r6:bf3962f8 r5:00000009 r4:00000000 r3:00400140
[34227.028683] [<c0015608>] (show_stack) from [<c016787c>] (dump_stack+0x7c/0x98)
[34227.035958] [<c0167800>] (dump_stack) from [<c001fe04>] (warn_slowpath_common+0x70/0x94)
[34227.044081] r4:00000000 r3:00000000
[34227.047727] [<c001fd94>] (warn_slowpath_common) from [<c001fecc>] (warn_slowpath_null+0x24/0x2c)
[34227.056552] r8:c793c380 r7:00000002 r6:c697c524 r5:c697c480 r4:00000001
[34227.063377] [<c001fea8>] (warn_slowpath_null) from [<bf389a80>] (brcmf_netdev_wait_pend8021x+0xf0/0x100 [brcmfmac])
[34227.073882] [<bf389990>] (brcmf_netdev_wait_pend8021x [brcmfmac]) from [<bf37a62c>] (brcmf_cfg80211_get_key+0x1d0/0x398 [brcmfmac])
[34227.085762] r6:c697c480 r5:c793c3b0 r4:c697c480
[34227.090477] [<bf37a598>] (brcmf_cfg80211_get_key [brcmfmac]) from [<bf37c5f0>] (brcmf_cfg80211_add_key+0x1cc/0x278 [brcmfmac])
[34227.101923] r5:00000004 r4:c793c388
[34227.105585] [<bf37c424>] (brcmf_cfg80211_add_key [brcmfmac]) from [<bf281d00>] (nl80211_new_key+0xf8/0x11c [cfg80211])
[34227.116345] r8:00000000 r7:c6500000 r6:c6047c30 r5:c697c000 r4:00000000
[34227.123123] [<bf281c08>] (nl80211_new_key [cfg80211]) from [<c0256b8c>] (genl_rcv_msg+0x25c/0x2f4)
[34227.132117] r8:00000000 r7:c6b93e80 r6:c7284214 r5:bf2907ac r4:bf29950c
[34227.138922] [<c0256930>] (genl_rcv_msg) from [<c025605c>] (netlink_rcv_skb+0x60/0xb4)
[34227.146784] r10:c6047dd8 r9:00000000 r8:c6047d14 r7:00000048 r6:c0256930 r5:c6b93e80
[34227.154694] r4:c7284200
[34227.157265] [<c0255ffc>] (netlink_rcv_skb) from [<c025691c>] (genl_rcv+0x28/0x3c)
[34227.164765] r6:c6b7cc00 r5:c6b93e80 r4:c03d9610 r3:00000001
[34227.170542] [<c02568f4>] (genl_rcv) from [<c02559d0>] (netlink_unicast+0x138/0x22c)
[34227.178235] r5:c6b93e80 r4:c7a0ec00
[34227.181845] [<c0255898>] (netlink_unicast) from [<c0255e98>] (netlink_sendmsg+0x32c/0x394)
[34227.190163] r9:00000048 r8:c6047f5c r7:c6b7cc00 r6:00000000 r5:00000000 r4:c6b93e80
[34227.198012] [<c0255b6c>] (netlink_sendmsg) from [<c02199e8>] (sock_sendmsg+0x78/0x8c)
[34227.205883] r10:c6047e60 r9:c7554200 r8:00000000 r7:c73e0440 r6:c6047f5c r5:00000048
[34227.213776] r4:c7554200
[34227.216364] [<c0219970>] (sock_sendmsg) from [<c021b214>] (___sys_sendmsg.part.4+0x18c/0x210)
[34227.224919] r7:c6047e40 r6:00000000 r5:00000048 r4:c6047f5c
[34227.230667] [<c021b088>] (___sys_sendmsg.part.4) from [<c021c208>] (__sys_sendmsg+0x54/0x78)
[34227.239144] r10:00000000 r9:c6046000 r8:c0008aa4 r7:00000128 r6:be97fefc r5:00000000
[34227.247078] r4:c7554200
[34227.249644] [<c021c1b4>] (__sys_sendmsg) from [<c021c23c>] (SyS_sendmsg+0x10/0x14)
[34227.257264] r6:00c43d98 r5:be97fefc r4:00c43d98
[34227.261976] [<c021c22c>] (SyS_sendmsg) from [<c0008900>] (ret_fast_syscall+0x0/0x38)
[34227.269757] ---[ end trace 4f630fc3ee61acc7 ]---Looks like your router is pretty unhappy about the broadcom MAC (hence the stack trace).
It looks like a Windows 2012 Server issue, which I doubt will be fixed. I believe you said SLAAC is OK, so you could disable the M bit in your RA, but then you would have to manually assign an IPv6 address to your 2012 server, since it doesn't support SLAAC-only.
From the odhcpd doc:
ra_management integer 1 RA management mode
0: no M-Flag but A-Flag
1: both M and A
2: M but not AThe discussion might have continued from here.