Detailed logs for upstream DHCPv6 to WAN6 interface on Router

I have a Linksys WRT1200AC that I've been running with OpenWRT for about a year and a half now. The last time I made any changes to my router was in spring of this year when I upgraded to OpenWrt 19.07.1 from OpenWrt 18.06.5. I only mention that to point out that I haven't made changes in about 6 months or maybe longer.

IPv6 with prefix delegation has been working fine on this router for that whole time, until recently. I noticed that IPv6 connectivity stopped working on my desktop PC under both Linux and Windows, and I noticed that the PC wasn't being assigned a public IPv6 address.

So, I checked the router, and noticed that it appears I'm no longer getting an IPv6 prefix delegation from DHCPv6 from my ISP, Spectrum Cable, which I had been in the past. Screenshot below (slightly redacted to obscure most but not all of my public IPv6 address for the router itself, the IPv6 gateway of my ISP, and the mac address of my router's WAN6 interface). Note that it doesn't show any delegated prefix. I swear this box used to show a delegated prefix, but no longer does.


Here is the configuration for the WAN6 interface (from Luci):


So what I want to know, is there any logging either already enabled, or that I can turn on to increase the logging, to capture the DHCPv6 request & response (from the upstream DHCPv6 server), that can be used to prove that Spectrum's DHCPv6 isn't working right?

I need to hand them something that proves that the problem isn't the configuration of my router (or maybe it is, and the log will show me that, and that's helpful too), but that my router isn't getting a proper prefix delegation from DHCPv6.

what happens when you set request length to automatic...

ubus call network.interface.wan6 status | grep -Ev '(address|source)'
uci show network
uci show dhcp
ifstatus wan6
killall tcpdump
tcpdump -env -i $(uci get network.wan6.ifname) udp port 546 or icmp6 &
killall -SIGUSR1 odhcp6c

I tried 64, 56, and Automatic from Luci (and did Save & Apply after changing it each time, and also restarted the WAN6 interface). Didn't make any difference.

The 64 setting worked in the past. So did 56 - I used both at different times.

1 Like

well... i'll share a similar story...

had almost identical symptoms to you... worked for several months then stopped working... for a few months ( well, it would obtain PD on boot then drop it around the first renewal time/RA... )... thought it was a software bug...

one day I redo my network settings from scratch... leaving all ipv6 stuff default... what do you know... it starts working again :wink:

there are odd occasions now when at certain times ( usually boot ) it doesn't pick anything up... but 'ifup wan6' did the job last time...

one of the community build users is also having issues with ppp-wan6...

so... whether or not your isp has something unique... there is definately some 'fussyness' going on that seems timing/process order related... between the access server/modem/router and ipv6 negotiations... ip6 usually comes up tens of seconds after ipv4 also... ( for me... again... no idea whether it's isp/modem/process timing etc... or a combination of all the above... if I had to guess i'd say timing/modem )

( disclaimer: above is referring to master with a usb wan nic... which adds one more layer of complexity... although no issues with ipv4 so... probably not too influential... )

also, admittedly I have not tried to tweak / investigate settings on my side... so there is possibly some simple setting I can increase / lower to make the whole thing crisp

1 Like

i have absolutely no idea of this will work maybe @vgaetera can tweak it a little ( or alot :wink: ) ( if i'm reading correctly you are only comfortable with luci )

you can paste this in luci in startup... ( rc.local then save and reboot ) wait a day though in case someone spots bugs / improvements... wait 3minutes and got to http://IP/logs/tcpdump.txt

mkdir /tmp/wwwlogs; ln -s /tmp/wwwlogs /www/logs

############# @vgae
ifstatus wan6
killall tcpdump 2>/dev/null
tcpdump -env -i $(uci get network.wan6.ifname) udp port 546 or icmp6 2>&1 >> /tmp/wwwlogs/tcpdump.txt &
killall -SIGUSR1 odhcp6c

cat <<'EOF' > /tmp/
DS=$(date +%Y%m%d%H%M)
tmpspace() { df /tmp | tr -s '\t' ' ' | tail -n1 | cut -d' ' -f4; }

pdrange=$(ubus call network.interface.wan6 status 2>/dev/null | jsonfilter -e '@["ipv6-prefix"][0].address' 2>/dev/null)
while [ -z "$pdrange" ] && [ "$(tmpspace)" -gt 5412 ]; do
	DS=$(date +%Y%m%d%H%M)
	logger -t pdgotme "$DS reqPD tmpspace:$(tmpspace)"
	ifup wan6
	sleep 21
	pdrange=$(ubus call network.interface.wan6 status 2>/dev/null | jsonfilter -e '@["ipv6-prefix"][0].address' 2>/dev/null)
	sleep 120

logger -t pdgotme "$DS $pdrange"
#killall tcpdump 2>/dev/null
chmod +x /tmp/

(sleep 30; /bin/sh /tmp/ &

#NOTE: leave the last line of the file 'exit 0'

after 20 minutes or so remove it from 'startup' save the tcpdump.txt and reboot...

1 Like

interesting... just ran the script above ( sorry to hijack your thread )...

what are these... is 33:xx something special like ff:ff for ipv6? dont think it's the servers mac... ( everything worked ok... tho' ) edit: seems like destip is multicast...

i can recognize the server link-local etc.

mac-33 and unknown-option-14-rapid-commit?
13:14:44.385635 00:11:32:96:42:6x > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 244: (flowlabel 0x4a7bb, hlim 1, next-header UDP
 (17) payload length: 190) fe80::xxx:xxff:xxxx:xxx5.546 > ff02::1:2.547: 
[bad udp cksum 0x7462 -> 0x5a98!]

x 10 (every interval)

13:14:44.850502 00:11:32:96:42:6x > 33:33:ff:bf:93:5c, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload l
ength: 32)
 :: > ff02::1:xxxx:935c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2403:xxxx:xxxx:xxx:f7b5:dd5e:73bf:93
          unknown option (14), length 8 (1): 
          0x0000:  ec34 cf74 e75f
1 Like

Having the exact same issue as you. Everything worked fine for years with prefix delegation, now I cant get it working.

1 Like

Sometimes it's just an incorrect configuration on the ISP side:
IPv6 not working in 19.07 in standard configuration, only disable Firewall rules helped
May be there's a similar issue for the OP, so testing with disabled firewall is worth to try.


Hi - sorry, been busy the past few days and didn't get a chance to follow up. So, when I do that (I ommitted icmp6 from the tcpdump, because that was very chatty), and then restart the interface, I see something that I think is interesting (snip starts after ifdown wan6 followed by ifup wan6):

root@OpenWrt:~# ifup wan6
root@OpenWrt:~# 13:03:56.365922 c0:[redacted]:a9 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 193: (flowlabel 0x43da4, hlim 1, next-header UDP (17) payload length: 139) fe80::c256:27ff:fe6f:eaa9.546 > ff02::1:2.547: [bad udp cksum 0xd192 -> 0x390d!] dhcp6 solicit (xid=fc5826 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 c056276feaa9) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
13:03:56.415449 00:01:5c:69:32:46 > c0:[redacted]:a9, ethertype IPv6 (0x86dd), length 210: (hlim 64, next-header UDP (17) payload length: 156) fe80::201:5cff:fe69:3246.547 > fe80::c256:27ff:fe6f:eaa9.546: [udp sum ok] dhcp6 advertise (xid=fc5826 (client-ID hwaddr type 1 c056276feaa9) (server-ID hwaddr/time type 1 time 494686384 0050569d91e3) (IA_NA IAID:1 T1:302386 T2:483817 (IA_ADDR 2605:a000:[redacted]:48e7 pltime:604772 vltime:604772)) (IA_PD IAID:1 T1:0 T2:0 (status-code NoPrefixAvail)) (preference 255))
13:03:58.340289 c0:[redacted]:a9 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 192: (flowlabel 0x43da4, hlim 1, next-header UDP (17) payload length: 138) fe80::c256:27ff:fe6f:eaa9.546 > ff02::1:2.547: [bad udp cksum 0xd191 -> 0x0236!] dhcp6 request (xid=8c7694 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96) (client-ID hwaddr type 1 c056276feaa9) (server-ID hwaddr/time type 1 time 494686384 0050569d91e3) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0 (IA_ADDR 2605:a000:[redacted]:48e7 pltime:604772 vltime:604772)))
13:03:58.395331 00:01:5c:69:32:46 > c0:[redacted]:a9, ethertype IPv6 (0x86dd), length 142: (hlim 64, next-header UDP (17) payload length: 88) fe80::201:5cff:fe69:3246.547 > fe80::c256:27ff:fe6f:eaa9.546: [udp sum ok] dhcp6 reply (xid=8c7694 (client-ID hwaddr type 1 c056276feaa9) (server-ID hwaddr/time type 1 time 494686384 0050569d91e3) (IA_NA IAID:1 T1:302400 T2:483840 (IA_ADDR 2605:a000:[redacted]:48e7 pltime:604800 vltime:604800)))

**** End Paste ****
What specifically looks possibly interesting to me is this bit:

status-code NoPrefixAvail

Am I correct in interpretting this to mean that DHCPv6 server is explicitly responding that it is not providing a prefix delegation to my router, even though the router did ask for one?

1 Like

Also, sorry, didn't have a chance to run the commands before, but have now:

root@OpenWrt:~# ubus call network.interface.wan6 status | grep -Ev '(address|source)'
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 615,
	"l3_device": "eth1.2",
	"proto": "dhcpv6",
	"device": "eth1.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
			"mask": 128,
			"preferred": 604185,
			"valid": 604185
	"ipv6-prefix": [
	"ipv6-prefix-assignment": [
	"route": [
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::201:5cff:fe69:3246",
			"metric": 512,
			"valid": 1797,
	"dns-server": [
	"dns-search": [
	"neighbors": [
	"inactive": {
		"route": [
		"dns-server": [
		"dns-search": [
		"neighbors": [
	"data": {

*** End Paste ***

root@OpenWrt:~# uci show network
network.@switch_vlan[0].ports='0 1 2 3 5t'
network.@switch_vlan[1].ports='4 6t'

*** End Paste ***

root@OpenWrt:~# uci show dhcp

Please use the "Preformatted text </>" button for logs, scripts, configs and general console output.
Please edit your post accordingly. Thank you! :slight_smile:

That is correct. You'll need to contact your ISP to fix that.


also, your dhcp config is missing the odhcpd ( ipv6 server ) entries...

1 Like

Can you expand on this? Which bit were you looking at, and what do you think it should be showing? Is this something that means a misconfiguration in OpenWRT, or is it caused by a lack of proper response from the dhcpv6 server at my ISP? Thanks.

Thanks! I've been looking for some sort of smoking gun to provide my ISP, because they just wanted to claim that it was my router that wasn't configured right.

dhcp.lan.dns='fd00:bbbb::2' 'fd00:bbbb::3'

Regardless you can configure the wan6 interface a bit better.

network.wan6.reqprefix='auto' <- or use a specific prefix here.
1 Like

I'm a little confused here, because, Luci shows:


Which shows that it is ALREADY configured the way you are suggesting I configure it. Are you saying that Luci isn't showing the real, correct configuration, and isn't changing the configuration in the way I requested? I wonder why Luci and uci would show up differently?

Also, that tcpdump I showed earlier, with the status-code: NoPrefixAvail doesn't that show that dhcpv6 is actually happening?

nope... we are saying that your config is far from 'default'... and that your dump shows that auto is asking for /64 which is 'not available'...

I really thing before going any further...

  1. Install from scratch with default settings a recent 19.07.4? release

a search of the forum for that error interestingly turns up one other thread... which by coincedence? is quite similar model to yours... so if a fresh 19 is no good... i'd be trying the most recent 18 also...

all the actual dhcp to client stuff is really supplimental and should be addressed as a separate issue... messing with both at the same time will complicate things...

1 Like

You know what might be worth a quick test - This router has two firmware 'partitions' - and I still have my old 18.x install in the other partition. I have Luci's advanced reboot plugin which allows me to reboot to the other partition, so I'm going to give that a try, and see how that behaves.

1 Like

It is using the defaults:

|reqaddress |[try,force,none] |no |try |Behaviour for requesting addresses|
|reqprefix |[auto,no,0-64] |no |auto |Behaviour for requesting prefixes (numbers denote hinted prefix length). Use 'no' if you only want a single IPv6 address for the AP itself without a subnet for routing |

However I had a similar issue some time ago and it turned out it was not properly configured from my ISP.