-
Notifications
You must be signed in to change notification settings - Fork 99
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
device on lan cann't get ipv6 address on latest commit #197
Comments
confirm, latest snapshot, with breaks ipv6. clients on any LAN are not issued ipv6 addresses, via dhcp or slaac. |
Logs are spammed with:
iface br-lan:
rebooted, waited 10 minutes, same issue. the only way to get odhcpd to issue addresses is to wait for booting to complete, wait a few minutes, then issue |
Config of the instance?
Il Gio 23 Mar 2023, 09:57 gtxaspec ***@***.***> ha scritto:
… Logs are spammed with:
Thu Mar 23 01:55:38 2023 daemon.notice odhcpd[1816]: Skip sending a RA on lan as no link local address is available
Thu Mar 23 01:55:39 2023 daemon.notice odhcpd[1816]: Skip sending a RA on lan as no link local address is available
iface br-lan:
inet6 addr: fe80::8e3b:adff:fe15:8cd/64 Scope:Link
inet6 addr: fdfc:a30a:2d0::1/60 Scope:Global
—
Reply to this email directly, view it on GitHub
<#197 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQQ3JBAQNIZQKGJWH2TW5QGA5ANCNFSM6AAAAAAWEUN7TY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@gtxaspec ok so a on a running system, restarting odhcpd fix the problem correct? Trying to find a good way to repro this. |
@gtxaspec i guess you are running dnsmasq for ipv4 and odhcpd-ipv6only for ipv6 correct? |
Yes. I believe this is the stock setup that openert does during installation. |
Yes, after booting waiting a few minutes restarting odhcpd fixed it. |
@gtxaspec can you test a patch... i should have found the problem |
I don't have access to a build system at the moment... Though If you can give me a sysupgrade image for the r7800, I'll give it a go. |
@gtxaspec actually i can give you the bin to replace and test on the fly. Ok for you ? (no sysupgrade required) |
Oh yeah sure |
@gtxaspec here https://we.tl/t-qunISCBmbM you need to /etc/init.d/odhcpd stop then in theory a restart should be enough to check if the thing works or not. |
Confirmed, working now |
|
As indicated in the linked bug report on the openwrt issue tracker, this is still (or maybe for the first time, as the last good openwrt commit I was running has been before all the odhcpd updates (68883278ab from 21.03.)) broken. |
@dowe just to make sure. Can you confirm your config and log output with log level 7 ? |
Ok it the log gets spammed with
config is:
|
@dowe any special configuration? (on the network side? can you please post it with the private data removed?) |
@Ansuel well, I get a /56 ipv6 subnet from which the addresses are delegated, but I think this is pretty standard. Other than that I can't think of anything special. |
@dowe asking this to have good repro. Would be good to have also output of this |
network conf:
|
|
Ok thanks for the info should be enough. Now I have to repro it. Think I will use the same way with me building a test bin and asking you to test. Ok for you ? |
sure it's a R7800 |
@dowe r7800 https://we.tl/t-LQUfu4al0j can you test? network restart... interface restart reboot.... ifdown interface ifup interface |
@Ansuel ok, so I replaced the elf file with the version you provided, but on reboot the same thing happens. No client IPv6 and the same error msg in syslog. |
@dowe good to hear! Now I will start cleaning and produce a final version and then I will push the fix. (the main problem of the bug is that it's triggered by luck as one logic to detect linklocal is currently broken and I totally din't notice that) |
sure, so not a race condition with dnsmasq. |
@dowe https://we.tl/t-cVrs3wgYBY can you test? this should be final version. |
@Ansuel something is wrong
|
@Ansuel works again
|
@dowe from the log it looks to be working correctly. Can you confirm? |
yes I get IPs |
but I still get one additional old one one as described above and therefore can't ping |
@dowe mhh i think that is just lease? |
@Ansuel yes but it has the same lease remaining as the old ones with that former prefix.
|
da00 is the old prefix
|
@Ansuel same behaviour as before (on the client)
|
@dowe https://we.tl/t-I7V2yL9SeS this is the old version before all the ra changes. (just a sanity check to make sure this is a regression) |
@Ansuel you're right it behaves the same. |
@dowe worth to understand if it's problematic and why this happens. Any idea? also looking at the log. Maybe the address is added but never removed? |
this is probably only a problem on IPv6 only networks. In my dualstack use case, you don't see a problem due to IPv4 working |
you think the client source address selection gets confused? |
@dowe ip 6 -a ? The confusing part is that in theory odhcpd should not be the culprit... maybe odhcp6c |
ip on router:
|
how does that work together? odhcp6c gets the router ip? and the prefix from the ISP? |
odhcp6c is the one who act as a client so delegate the prefix AFAIK. ip -6 a show only one ipv6... you device have 2? are you sure ipv6 doesn't work? could be that it's just privacy extension with using 2 different ipv6 |
this is the device, now it works cause the old IPs timed out. But I would have thougt that RFC3484 would always prefer the newer ones, so idk why ping is initially not working. |
@dowe eh i think they are unrelated to the problem of RA not working. Also if you notice out of all the ip only 3 are not deprecated (link local, privacy extension and real ipv6) |
hmm, true then I don't understand why there is no ping response. let me check what IP it selects... |
@Ansuel ok, wireshark shows the icmpv6 packages are using the "extra" IP with the old prefix as source. so the response gets lost... |
also now, no ip is marked as deprecated, as there is still lease time remaining |
Use netlink_get_interface_addrs is wrong and doesn't actually work. The function checks only for UNIVERSE address and is not suitable for dumping linklocal address of an interface. Use the new and dedicated function to get interface linklocal address to correctly check if the interface can receive message. Fixes: #197 Fixes: 7c0f603 ("router: skip RA and wait for LINK-LOCAL to be assigned") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
after update commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d2fc620d0a5e0287aa8d60fb10f5d5f590f571f2 , device on lan cann't get ipv6 address anymore
The text was updated successfully, but these errors were encountered: