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.
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
NDP relay not working because NDP proxy entries are not added #92
Comments
I experience the same behavior. Is it a bug or a configuration problem? |
When VLAN is enabled, /proc/sys/net/ipv6/conf/eth0.X/proxy_ndp is 0 for me, setting it to 1 manually gives me the very same behavior as in the original report. |
I am experiencing the very same behavior. Could someone have a look at this, please? |
This issue has been fixed in the odhcpd version in use by Lede (https://git.lede-project.org/?p=project/odhcpd.git;a=summary) |
@dedeckeh wonders if that's incorporated in 17.01.2? |
@dedeckeh That's a great news, thanks! I should have probably mentioned that I am on LEDE 17.01.0. However, since the patchversions share the packages (http://downloads.lede-project.org/releases/), I am on the latest stable odhcpd (2017-04-28-9268ca65-1). I'll give the snapshot version a try. |
So it works now by putting the same config in the |
FYI, the solution on #37 (comment) actually work but one may need patience waiting for subnet to come online. On version 2017-10-02-c6f3d5d4-2 @ LEDE 17.01.3, after |
My provider is assigning some IPv6 prefix (bigger than /64) to my cable modem that is then handing out addresses from one /64 prefix onto its LAN ports (where my OpenWrt router is connected to) via DHCPv6.
I have configured
/etc/config/dhcp
like this:My router is assigning the following addresses:
So it basically has the same addresses on LAN and WAN side (which seems reasonable). odhcpd seems to create routes for the hosts it sees on both interfaces:
Proxy NDP is also enabled for both interfaces:
However, odhcpd does not seem to create NDP proxy entries for the host it sees on
br-lan
(which is required so that the modem actually knows where to send packets):(In this case
...:1734
is the modem and...:75e3
is the router. I'm not sure what the other entry is.)Because of this, I'm not able to access any global IPv6 addresses behind the WAN (eth0) interface (not even the modem).
When I add an entry manually for my computer:
I'm able to connect to global IPv6 addresses for some time but after about a minute or so odhcpd actually seems to remove that entry on its own and it won't work anymore.
This seems like a bug to me.
The text was updated successfully, but these errors were encountered: