DHCPv6 / odhcp6c problem

My ISP has assigned me a /56 prefix, and I had been using this for a while. Recently we had a major power outage and when things came back up my router was no longer setting up the IPv6 prefix. I added a "-v" to odhc6c and from the logs it looks like my ISP is offering the prefix...

Tue Apr 19 13:33:52 2022 daemon.notice netifd: Network device 'pppoe-wan' link is up
Tue Apr 19 13:33:52 2022 daemon.notice netifd: Interface 'wan' is now up
Tue Apr 19 13:33:53 2022 daemon.notice netifd: Network alias 'pppoe-wan' link is up
Tue Apr 19 13:33:53 2022 daemon.notice netifd: Interface 'wan_6' is enabled
Tue Apr 19 13:33:53 2022 daemon.notice netifd: Interface 'wan_6' has link connectivity
Tue Apr 19 13:33:53 2022 daemon.notice netifd: Interface 'wan_6' is setting up now
Tue Apr 19 13:33:53 2022 daemon.notice odhcp6c[6777]: (re)starting transaction on pppoe-wan
Tue Apr 19 13:33:53 2022 user.info dhcpv6.script: run with pppoe-wan started
Tue Apr 19 13:33:53 2022 daemon.notice odhcp6c[6777]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
Tue Apr 19 13:33:53 2022 daemon.notice odhcp6c[6777]: Got a valid ADVERTISE after 5ms
Tue Apr 19 13:33:53 2022 daemon.info odhcp6c[6777]: IA_PD 0001 T1 129600 T2 207360
Tue Apr 19 13:33:53 2022 daemon.info odhcp6c[6777]: 2804:81dc:30::/56 preferred 233280 valid 259200
Tue Apr 19 13:33:54 2022 daemon.warn dnsmasq-dhcp[2764]: DHCP packet received on wan which has no address
Tue Apr 19 13:33:54 2022 daemon.notice odhcp6c[6777]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
Tue Apr 19 13:33:54 2022 daemon.notice odhcp6c[6777]: Got a valid ADVERTISE after 5ms
Tue Apr 19 13:33:54 2022 daemon.info odhcp6c[6777]: IA_PD 0001 T1 129600 T2 207360
Tue Apr 19 13:33:54 2022 daemon.info odhcp6c[6777]: 2804:81dc:30::/56 preferred 233280 valid 259200
Tue Apr 19 13:33:55 2022 daemon.notice odhcp6c[6777]: Starting REQUEST transaction (timeout 4294967295s, max rc 10)
Tue Apr 19 13:33:55 2022 daemon.notice odhcp6c[6777]: Send REQUEST message (elapsed 0ms, rc 0)
Tue Apr 19 13:33:55 2022 daemon.notice odhcp6c[6777]: Got a valid REPLY after 6ms
Tue Apr 19 13:33:55 2022 daemon.info odhcp6c[6777]: IA_PD 0001 T1 129600 T2 207360
Tue Apr 19 13:33:55 2022 daemon.info odhcp6c[6777]: 2804:81dc:30::/56 preferred 0 valid 0
Tue Apr 19 13:33:55 2022 daemon.notice odhcp6c[6777]: (re)starting transaction on pppoe-wan

And then it repeats. 2804:81dc:30::/56 is the correct prefix. Why isn't it getting set up?
Here's what the relevant interfaces look like...

br-lan    Link encap:Ethernet  HWaddr 48:8F:5A:DF:D9:1A  
          inet addr:172.23.0.1  Bcast:172.23.255.255  Mask:255.255.0.0
          inet6 addr: fd06:633c:9029::1/64 Scope:Global
          inet6 addr: fe80::4a8f:5aff:fedf:d91a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9931 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9379 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2421248 (2.3 MiB)  TX bytes:3355834 (3.2 MiB)

eth0      Link encap:Ethernet  HWaddr 96:1C:DC:92:A7:F5  
          inet6 addr: fe80::941c:dcff:fe92:a7f5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1504  Metric:1
          RX packets:413044 errors:1 dropped:0 overruns:0 frame:0
          TX packets:478122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:203360989 (193.9 MiB)  TX bytes:236448023 (225.4 MiB)
          Interrupt:22 

pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:5.180.148.57  P-t-P:100.65.0.1  Mask:255.255.255.255
          inet6 addr: fe80::75ff:1a15:29a7:2170/128 Scope:Link
          inet6 addr: fd06:633c:9029:1::1/64 Scope:Global
          inet6 addr: 2804:81dc:0:8000:75ff:1a15:29a7:2170/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1480  Metric:1
          RX packets:15385 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27704 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:4201769 (4.0 MiB)  TX bytes:4694807 (4.4 MiB)

wan       Link encap:Ethernet  HWaddr 64:D1:54:43:11:E5  
          inet6 addr: fe80::66d1:54ff:fe43:11e5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:247619 errors:0 dropped:4866 overruns:0 frame:0
          TX packets:231124 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:166219223 (158.5 MiB)  TX bytes:41651017 (39.7 MiB)

Note the 2804:81dc:0:8000:75ff:1a15:29a7:2170/64 on the pppoe-wan interface; that is also assigned by the ISP and seems to get added after the virtual 'wan_6' interface comes up.

The relevant parts of my /etc/config/network file are straight forward enough...

config globals 'globals'
	option packet_steering '1'
	option ula_prefix 'fd06:633c:9029::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'lan5'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	list dns '172.23.0.1'
	list ipaddr '172.23.0.1/16'
	option ip6assign '64'
	option metric '10'

config interface 'wan'
	option device 'wan'
	option proto 'pppoe'
	option ipv6 'auto'
	option password 'xxxxxxxx'
	option username 'yyyyyyy'
	option peerdns '0'
	option ip6assign '64'

My ISP has this config...

Remove ip6assign from wan interface.
Also under lan interface remove the dns 172.23.0.1, which is the router itself. Use dns forwarding to specify the local nameserver.

Thanks for the reply, but removing the ip6assign from wan if didn't solve my problem. You're right about the extraneous 'dns' entry of course, but that's unrelated. Any other ideas?

The prefix in the reply message has 0 value in preferred and valid. Therefore it cannot be used. Can you run a packet capture and verify the contents?
opkg update; opkg install tcpdump; tcpdump -evni any udp port 547 & sleep 5; killall -SIGUSR1 odhcp6c; sleep 5; killall tcpdump

OK, this is strange... doing the tcpdump exactly as you gave it I get nothing at all...

root@router5:~# tcpdump -evni any udp port 547 or port 546 & sleep 5; killall -SIGUSR1 odhcp6c; sleep 5; killall tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel

What's more...

root@router5:~# tcpdump -evni any ip6 & sleep 5; killall tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel

Using any expression involving IPv4 gives me lots of output, but if I try to limit to anything involving IPv6 I get nothing at all.

However, if give tcpdump no expression and use grep to filter, I get this...

tcpdump -evni any | grep fe80::dd02:f44c:4b57:5142 | grep 547
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
10:44:07.092031 Out 64:d1:54:43:11:e5 ethertype PPPoE S (0x8864), length 174: PPPoE  [ses 0xeb9] IP6 (0x0057), length 152: (flowlabel 0xeff11, hlim 1, next-header UDP (17) payload length: 110) fe80::dd02:f44c:4b57:5142.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=965c9f (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 488f5adfd91a) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0))
10:44:07.096093  In 4c:5e:0c:f6:8e:d0 ethertype PPPoE S (0x8864), length 154: PPPoE  [ses 0xeb9] IP6 (0x0057), length 132: (hlim 64, next-header UDP (17) payload length: 90) fe80::f0:eea.547 > fe80::dd02:f44c:4b57:5142.546: [udp sum ok] dhcp6 advertise (xid=965c9f (client-ID hwaddr type 1 488f5adfd91a) (server-ID hwaddr type 1 4c5e0cf68ec8) (preference 255) (IA_PD IAID:1 T1:129600 T2:207360 (IA_PD-prefix 2804:81dc:30::/56 pltime:233280 vltime:259200)))

Try it one more time with this one

tcpdump -evni pppoe-wan udp port 547 & sleep 5; killall -SIGUSR1 odhcp6c; sleep 10; killall tcpdump

Same result, no output. Just doing tcpdump -evni pppoe-wan without a pcap expression gives plenty of output, but this gives nothing.

That's odd, I had tried the command on my system and produced the expected output.

root@magiatiko:[~]#tcpdump -evni pppoe-wan udp port 547 & sleep 5; killall -SIGUSR1 odhcp6c; sleep 10; killall tcpdump
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
17:41:04.802393 Out ethertype IPv6 (0x86dd), length 189: (flowlabel 0x6dd35, hlim 1, next-header UDP (17) payload length: 133) fe80::64af:7acd:337d:6f16.546 > ff02::1:2.547: [udp sum ok] dhcp6 renew (xid=d4bf18 (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 001e101f0000) (server-ID hwaddr type 1 6c3b6bee0d46) (Client-FQDN) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix 2a0f:aaaa:273:7500::/56 pltime:0 vltime:0)))
17:41:04.806561  In ethertype IPv6 (0x86dd), length 177: (hlim 64, next-header UDP (17) payload length: 121) fe80::30.547 > fe80::64af:7acd:337d:6f16.546: [udp sum ok] dhcp6 reply (xid=d4bf18 (client-ID hwaddr type 1 001e101f0000) (server-ID hwaddr type 1 6c3b6bee0d46) (DNS-server 2001:4860:4860::8888 2001:4860:4860::8844) (IA_PD IAID:1 T1:150 T2:240 (IA_PD-prefix 2a0f:aaaa:273:7500::/56 pltime:270 vltime:300)))

2 packets captured
2 packets received by filter
0 packets dropped by kernel

Are you certain you installed the tcpdump and not tcpdump-mini?
Anyway, I guess we can try with:
tcpdump -i ppoe-wan -vn udp port 547 in case it doesn't like the mac headers.

Yeah, I'm sure, and I reinstalled it just in case, so I'm really sure.

tcpdump -i ppoe-wan -vn udp port 547

No better. I'm about to try tcpdump on another OpenWrt device to see if that provides some clarity as to what's going on here.

I had a typo in the previous command, should be pppoe-wan not ppoe

So I figured out that if I do tcpdump -i br-lan ip6, then I do see a bunch of IPv6 traffic, but if I do tcpdump -i any ip6, then I don't. Nor do I see any traffic with either tcpdump -i wan ip6 or tcpdump -i pppoe-wan ip6.

br-lan Is not useful in our case.
Do you have another router to try? I see a lot of weird things here.

I know br-lan isn't useful here, but at least now we know that tcpdump a) sort of works, and b) -i br-lan shows stuff that -i any doesn't.

Yeah, I have another router, later today I'm going to try that.

1 Like

After swapping out my router for another one (same model, MikroTik RB 750Gr3) with a fresh install of OpenWrt my original problem of not getting the IPv6 prefix went away. tcpdump still behaves strangely on the newly installed router, so that's a separate issue (I'll investigate further).

1 Like

Then maybe a backup, erase, and reconfigure of the original router will help.