What's new

IPV6 native DHCP-PD not working

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

SjoerdNLD

Regular Contributor
I'm using Firmware Version:3.0.0.4.354.27 (Merlin build) on my rt-ac66u.
I can't get it to work. (DHCP-PD)

With the stock 270 fw it worked fine.
I'm using my isp modem as bridge for connection.
Can anyone point me into a diagnose direction?


ip addr result:
1: lo: <LOOPBACK,MULTICAST,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 08:60:6e:bf:40:78 brd ff:ff:ff:ff:ff:ff
inet 169.254.172.83/16 brd 169.254.255.255 scope global eth0
45: vlan1@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
link/ether 08:60:6e:bf:40:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a60:6eff:febf:4078/64 scope link
valid_lft forever preferred_lft forever
46: vlan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether 08:60:6e:bf:40:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a60:6eff:febf:4078/64 scope link tentative
valid_lft forever preferred_lft forever
47: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 08:60:6e:bf:40:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a60:6eff:febf:4078/64 scope link
valid_lft forever preferred_lft forever
48: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 08:60:6e:bf:40:7c brd ff:ff:ff:ff:ff:ff
inet6 fe80::a60:6eff:febf:407c/64 scope link
valid_lft forever preferred_lft forever
49: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
link/ether 08:60:6e:bf:40:78 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.254/24 brd 10.0.0.255 scope global br0
inet6 fe80::a60:6eff:febf:4078/64 scope link
valid_lft forever preferred_lft forever
50: ppp0: <POINTOPOINT,MULTICAST,UP,10000> mtu 1492 qdisc htb qlen 3
link/ppp
inet 71.212.218.23 peer 94.19.5.13/32 brd 71.212.218.23 scope global ppp0
inet6 fe80::eccc:7c55:d40c:1354/10 scope link
valid_lft forever preferred_lft forever
 
Last edited:
Did you wait a while for it to configure itself before giving up? It worked for me when I was using that firmware version (I've since gone back to 270.27b, where it works as well), but it didn't start working immediately. It took about 15 minutes. I would think that it could take up to an hour to configure with your ISP and start working.

Just a thought.
 
Try turning off your modem for 5-10 mins, then turning it back on. Could be their DHCP won't hand you a new lease until it gets fully reset.
 
More suggestions are welcome :)
Turned the modem off/on and waited +30mins.
No ip.

Content of dhcp6c.conf:
interface ppp0 {
send ia-pd 247414904;
send ia-na 247414904;
send rapid-commit;
request domain-name-servers;
script "/sbin/dhcp6c-state";
};
id-assoc pd 247414904 {
prefix-interface br0 {
sla-id 1;
sla-len 0;
};
};
id-assoc na 247414904 { };
 
More suggestions are welcome :)
Turned the modem off/on and waited +30mins.
No ip.

Content of dhcp6c.conf:
interface ppp0 {
send ia-pd 247414904;
send ia-na 247414904;
send rapid-commit;
request domain-name-servers;
script "/sbin/dhcp6c-state";
};
id-assoc pd 247414904 {
prefix-interface br0 {
sla-id 1;
sla-len 0;
};
};
id-assoc na 247414904 { };

That looks wrong to me - it refers to ppp0, which would be used for PPPoE or L2TP. Make sure your WAN is set to DHCP.
 
That looks wrong to me - it refers to ppp0, which would be used for PPPoE or L2TP. Make sure your WAN is set to DHCP.

Yes, for 270.27b for me, this is eth0 instead of ppp0.
 
Thanks for checking the conf, I guess the ppp0 is in the file because my modem is configured as bridge, with pppoe connecting from the rt-ac66u.
It worked finally when I woke up this morning.
Then rebooted the unit, and apparently after 2 hrs it was ok again.

A new problem has emerged: the firewall was not blocking.
I checked ip6tables -L the but rules seem to be in place.
This is my firewall script, but I'm no expert, just copy/paste:
(from here:thread)

ip6tables -A INPUT -j DROP
ip6tables -I FORWARD 2 -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i ppp0 -o br0 -p all -j DROP
ip6tables -A FORWARD -i br0 -o any -p all -j ACCEPT
ip6tables -A FORWARD -i br0 -o ppp0 -p all -j ACCEPT
ip6tables -A FORWARD -i any -o br0 -p all -j ACCEPT
ip6tables -A FORWARD -j DROP

And this the output of ip6tables -L:
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all anywhere anywhere rt type:0
ACCEPT all anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all anywhere anywhere state NEW
ACCEPT all anywhere anywhere state NEW
ACCEPT ipv6-nonxt anywhere anywhere length 40
ACCEPT all anywhere anywhere
ACCEPT all anywhere anywhere
ACCEPT udp anywhere anywhere udp dpt:546
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp destination-unreachable
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp packet-too-big
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp time-exceeded
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp parameter-problem
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-request
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-reply
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 130
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 131
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 132
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-advertisement
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 141
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 142
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 143
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 148
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 149
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 151
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 152
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp type 153
DROP all anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all anywhere anywhere rt type:0
DROP all anywhere anywhere
ACCEPT all anywhere anywhere
ACCEPT ipv6-nonxt anywhere anywhere length 40
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp destination-unreachable
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp packet-too-big
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp time-exceeded
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp parameter-problem
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-request
ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-reply

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all anywhere anywhere rt type:0

Chain PControls (0 references)
target prot opt source destination

Chain logaccept (0 references)
target prot opt source destination
LOG all anywhere anywhere state NEW LOG level
warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
ACCEPT all anywhere anywhere

Chain logdrop (0 references)
target prot opt source destination
LOG all anywhere anywhere state NEW LOG level
warning tcp-sequence tcp-options ip-options prefix `DROP'
DROP all anywhere anywhere
 
To be honest, I never heard of an ISP offering DHCP-based IPv6 support over an IPv4 PPPoE connection. Sounds like a weird setup for me if they really do.

The only ISP I know that offers IPv6 over PPPoE requires you to use a different login, and the IPv6 is allocated over the PPPoE session, not through a piggy-backed DHCP.
 
Thanks for the info, I double checked their specs on the web.
Apparently they use a piggy-backed DHCP. :eek::eek::eek:
Translated from here source:
For IPv6 we use the existing PPP connection. The IPv6 is delivered as "dual stack" alongside the regular IPv4. Assigning IPv6 addresses is based on DHCPv6-PD. Furthermore, it is important to know that there are no route-able addresses assigned to the PPP connection itself.
The minimum requirements for a CPE are:
- Support for PPPoA / vcmux (ADSL) / PPPoE
- IPCP and IPv6CP (in the same session)
- DHCPv6 client support for prefix delegation (IA_PD)
Anyway the IPv6 kept working all day so I'm happy with it :)

I tried running the "FORWARD" lines form the script using ssh, they work fine and the incoming connections are blocked.
Is there any reason why the firewall-start script would only execute one line?
(the "INPUT" line in this case)
 
I tried running the "FORWARD" lines form the script using ssh, they work fine and the incoming connections are blocked.
Is there any reason why the firewall-start script would only execute one line?
(the "INPUT" line in this case)

Can you be more specific? What the script does is insert the rules in the firewall. Do you mean the other rules are not being inserted, or that packets all get matched by the first rule and never hit the following rules?
 
I mean e other rules are not being inserted.
To be specific, I put in this "firewall-start" script:
ip6tables -A INPUT -j DROP
ip6tables -I FORWARD 2 -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i ppp0 -o br0 -p all -j DROP
ip6tables -A FORWARD -i br0 -o any -p all -j ACCEPT
ip6tables -A FORWARD -i br0 -o ppp0 -p all -j ACCEPT
ip6tables -A FORWARD -i any -o br0 -p all -j ACCEPT
ip6tables -A FORWARD -j DROP
When I rebooted the router, after the ipv6 was gained, some ports of my local machine was still reachable from the internet.
So I checked ip6tables, where I found that only the INPUT chain was altered, the FORWARD chain was unaltered.
Then I altered it manually using ssh, working fine now.
What I don't understand is why the script was not fully processed.

Will reboot it now to double check.
(I use this to check)
 
Last edited:
I mean e other rules are not being inserted.
To be specific, I put in this "firewall-start" script:

When I rebooted the router, after the ipv6 was gained, some ports of my local machine was still reachable from the internet.
So I checked ip6tables, where I found that only the INPUT chain was altered, the FORWARD chain was unaltered.
Then I altered it manually using ssh, working fine now.
What I don't understand is why the script was not fully processed.

Will reboot it now to double check.
(I use this to check)

Try having the ip6tables redirect their output to a text file to see what error message they return:

Code:
ip6tables blah blah >>/tmp/debug.txt
 
Found it, really stupid. :D
Forgot the "#!/bin/sh" overlooked it when editing in vi.
Script now looks as this:
#!/bin/sh
ip6tables -A INPUT -j DROP
ip6tables -I FORWARD 2 -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i ppp0 -o br0 -p all -j DROP
ip6tables -A FORWARD -i br0 -o any -p all -j ACCEPT
ip6tables -A FORWARD -i br0 -o ppp0 -p all -j ACCEPT
ip6tables -A FORWARD -i any -o br0 -p all -j ACCEPT
ip6tables -A FORWARD -j DROP
echo "Finished firewall start at" `date` >> "/jffs/fw-start.log"
Works superb.
Thanks for all your support.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top