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
FS#3771 - odhcpd fails to send Router Advertisements #8785
Comments
bjonglez: It looks like br-lan has no link-local address, and there is a mixup between br-lan and lan. Please provide the full output of "ip addr show" and the content of /etc/config/network Is it a clean configuration from a 21.02 install, or did you keep settings from a previous install? |
dedeckeh: The trace "lan@br-lan" must not be interpreted as the linux device; it must be interpreted as "logical OpenWrt interface@linux device". So in this case the logical OpenWrt interface is lan while the linux device is br-lan; which is correct. |
cvmiller: Thank you for looking into this. I think it is odhcpd getting confused with the new interface names. But there the full IP addr output:
And the /etc/config/network
Thanks for looking into this. |
cvmiller:
This is a clean install, as was suggested by LuCI when I did the upgrade from 19.07. |
cvmiller: BTW, I also upgraded (clean install) of a GL-iNET USB150 (router on a thumb drive), and I see the same RA problem (none sent out, not even in response to a RS) and error messages in logread as the Linksys EA3500 |
cvmiller: Loaded the SNAPSHOT onto the Linksys EA3500, and it is sending RAs. Downstream hosts get IPv6 addresses. I note that I see similar lines in the logread. So I presume the errors in the log are not the problem with 21.02.0rc1
|
cvmiller: I just wanted to say that the work-around of installing luci-mod-network to git-21.110.65613 or later, as per the release notes, does work. I now have a router running 21.02.0-rc1 sending RAs. Thanks. |
Sorry to resurrect this issue, but I think I am experiencing the same thing or something similar. OpenWrt version: 21.02.3 What happens: After abut 24 hours of router up time, the router stops sending unsolicited router advertisements from my LAN interfaces. I notice a drop in ipv6 connectivity first, then open Wireshark and wait for the max RA interval and don't receive any router advertisements. If I disconnect and reconnect to wifi, I will get a router advertisement in response to a router solicitation, but no unsolicited advertisements (i.e. with dest IP ff02::1). Different devices respond differently to this. My Windows 10 laptop will still have IPv6 connectivity (I can "ping -6" anything on the internet) but will prefer IPv4 in all circumstances. A Raspberry Pi on my network will still have IPv6 addresses on the correct prefixes and on-link routes to its own /64, but no default route. It can ping the router itself and other machines on its same subnet but no machines on any other LAN subnets or anything else. The router itself still has full IPv6 connectivity. "ip -6 route show" shows a default route, and the IPv6 ping and traceroute diagnostics work from LuCI. I noticed this after I updated from 19.07. I updated to 21.02.1 with a fresh configuration and recreated all interfaces manually, then updated to 21.02.3 by uploading the configuration archive from 21.02.1. What I've tried so far: Rebooting the router restores router advertisements and default routes on all devices for a couple of days until they stop again. I honestly don't know what to look for in logs to identify the problem, but I'm happy to search. Configuration: /etc/config/network (with some sensitive info redacted)
/etc/config/dhcp (with some sensitive info redacted)
|
I ran into something similar on my DSL router running 21.02.3 as well. After a reconnect I loose IPV6 for my clients and see the same error. So the issue seems to still exists. Is there any way for me to help narrow this down? |
cvmiller:
Supply the following if possible:
Device problem occurs on
Linksys EA3500
Software versions of OpenWrt/LEDE release, packages, etc.
21.02.0rc1
Steps to reproduce
logread | grep odhcp
Sun Apr 18 03:07:34 2021 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/odhcpd
Sun Apr 18 03:07:38 2021 daemon.err odhcpd[1799]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Apr 18 03:07:41 2021 daemon.err odhcpd[1799]: Failed to send to fe80::9ed6:43ff:feae:1915%lan@br-lan (Address not available)
Sun Apr 18 03:07:41 2021 daemon.err odhcp6c[2528]: Failed to send RS (Address not available)
Sun Apr 18 03:07:42 2021 daemon.err odhcpd[1799]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Apr 18 03:07:42 2021 daemon.err odhcp6c[2528]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Sun Apr 18 03:07:48 2021 daemon.info dnsmasq[2569]: read /tmp/hosts/odhcpd - 0 addresses
The router does NOT, in fact, have the interface ff02::1%lan@br-lan
After installing ip-full, it is possible to see 'ip maddr' and see the correct interfaces on the router:
ip maddr
1: lo
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
...
13: br-lan
link 33:33:00:00:00:01
link 33:33:00:00:00:02
link 01:00:5e:00:00:01
link 33:33:ff:01:70:f1
link 33:33:ff:00:00:01
link 33:33:ff:00:00:00
link 33:33:00:00:00:09
inet 224.0.0.1
inet6 ff02::9
inet6 ff02::1:ff00:0 users 3
inet6 ff02::1:ff00:1 users 2
inet6 ff02::1:ff01:70f1
inet6 ff02::2
inet6 ff02::1
inet6 ff01::1
IMPACT: No attached device can receive an IPv6 address from the router
The text was updated successfully, but these errors were encountered: