Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FS#656 - IPv6 relay mode does not work #5651

Closed
openwrt-bot opened this issue Mar 26, 2017 · 9 comments
Closed

FS#656 - IPv6 relay mode does not work #5651

openwrt-bot opened this issue Mar 26, 2017 · 9 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

mlongbrake:

My ISP does not support DHCPv6, so I need to use IPv6 relay mode to enable my devices to obtain IPv6 addresses via SLAAC. I have configured relay mode as indicated in the documentation on a HooToo TM-02 for the time being. If I can get all this to work I will upgrade to a more capable device.

Running tcpdump on the WLAN interface I can see the router solicitation requests coming from my clients. When I run tcpdump on the WAN interface I don't see any router solicitations and, therefore, no router advertisements coming back from my ISP modem. The router itself gets an address from the modem, but the relaying of requests from clients is not happening.

I have posted my config files below, but they are basically stock. Is this a problem with the DHCPv6 server or some kind of firewall problem preventing the requests from getting out?

/etc/config/network:

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd20:0787:2c66::/48'

config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option _orig_ifname 'eth0'
option _orig_bridge 'false'
option ip6assign '64'

config device 'lan_dev'
option name 'eth0'
option macaddr '00:1c:c2:13:6f:05'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '0'

config interface 'wan'
option proto 'dhcp'
option ifname 'eth0'

config interface 'wan6'
option proto 'dhcpv6'
option ifname 'eth0'
option reqaddress 'try'
option reqprefix 'auto'

/etc/config/dhcp:

config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option localservice '1'

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'relay'
option ra 'relay'
option ndp 'relay'

config dhcp 'wan'
option interface 'wan'
option ignore '1'

config dhcp 'wan6'
option dhcpv6 'relay'
option ra 'relay'
option ndp 'relay'
option master '1'

config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'

/etc/config/firewall:

config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'

config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'

config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'

config forwarding
option src 'lan'
option dest 'wan'

config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'

config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config include
option path '/etc/firewall.user'

config rule
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

config rule
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
@openwrt-bot
Copy link
Author

netprince:

Did you should see this? maybe it will help:

https://bugs.lede-project.org/index.php?do=details&task_id=389

@openwrt-bot
Copy link
Author

dedeckeh:

Can you make odhcpd more verbose by adding the option -l 7 to the odhcpd init script ?
Thus in /etc/init.d/odhcpd change the following line : procd_set_param command /usr/sbin/odhcpd -l 7.
Attach the output of logread to this ticket. It will display the incoming router solicitations in odhcpd and to which interface they're forwarded; similar for dhcpv6 messages and ndp messages.

@openwrt-bot
Copy link
Author

mlongbrake:

I increased the logging verbosity as requested. In the process I discovered that restarting odhcpd makes it work correctly, it just does not work directly after bootup.

The attached file "pre-restart.txt" is the logread output after bootup. It appears that odhcpd is receiving packets but not doing anything with them. The first set of requests coming from ...:6789 are my laptop. I then turned on my Android phone around 18:57:30 and you can see the requests from it as well.

I then turned the phone off again and issued "/etc/init.d/odhcpd restart". I turned the phone on again around 19:00:00. In "post-restart.txt" the logread shows that odhcpd is now properly relaying requests and my phone now gets two IPv6 addresses. I did manage to get my laptop to obtain an IPv6 address once, but it hasn't been reproducible. I don't think it's an odhcpd problem though, I'm just not sure how to force Windows to try IPv6 again.

Based on this information, it seems like odhcpd is starting up in a weird state by default. Restarting it once the router is up and running seems to fix it.

@openwrt-bot
Copy link
Author

mlongbrake:

Looks like I spoke too soon. Although restarting odhcpd after bootup allows my devices to obtain IPv6 addresses, they cannot communicate with the internet. It appears to be [[https://github.com/openwrt/odhcpd/issues/92|this]] bug. I tried adding the neighbor proxy manually as described in the bug report and it allowed IPv6 communication briefly before the proxy entry disappeared.

@openwrt-bot
Copy link
Author

mlongbrake:

The problem continues to exist in 17.01.1

@openwrt-bot
Copy link
Author

dedeckeh:

Updated odhcpd in trunk (https://git.lede-project.org/?p=source.git;a=commit;h=c45ef702ff3d4fd79b788823719cda356b9088c5); version includes IPv6 relayd mode fixes.
Can you give a try in your setup ?

@openwrt-bot
Copy link
Author

mlongbrake:

I installed the latest developer snapshot, which I believe should include the changes you made. I'm still seeing the same behavior. I have attached a logread of a couple minutes after router boot. There is only one device trying to connect, but there are two IP addresses because of Windows' temporary address.

Note that nothing works until I manually restart odhcpd. You can see this at 21:34:25 in the log. At that point the prefix advertisement makes it to my computer and IPv6 addresses get assigned. No communication is possible over IPv6 however. The logs seem to indicate that the neighbor proxy entries get deleted immediately after being added.

@openwrt-bot
Copy link
Author

dedeckeh:

The dhcpv6/ra/ndp uci parameters for the wan interface need to be set; they need to have similar values as the wan6 interface has :

config dhcp 'wan'
option interface 'wan'
option ignore '1'
option dhcpv6 'relay'
option ra 'relay'
option ndp 'relay'
option master '1'

config dhcp 'wan6'
option dhcpv6 'relay'
option ra 'relay'
option ndp 'relay'
option master '1'

Can you change the uci parameters accordingly and report back ?

@openwrt-bot
Copy link
Author

tomkins:

Sorry for replying to a closed bug - but I believe this is the exact problem I've had. My ISP provides a /56 and a DSL router, but sadly that router doesn't support prefix delegation, which means DHCPv6 and RAs being served from a /64.

OpenWrt 15.05 was absolutely fine, however upgrading to LEDE 17.01.4 relay mode was unreliable. RAs were being received, my Linux server receiving these seemed just fine, my MacOS laptop received the address - but mtr showed the lack of a default gateway.

One thing which fixed it for me - removing ula_prefix entirely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openwrt-bot