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#2145 - No IPv4 adresses offered on LAN of GL-AR150 if no LAN cable is plugged during boot #8435
Comments
l3u: Apparently, someone filed the same problem at the same time as me at https://bugs.openwrt.org/index.php?do=details&task_id=2144 ... For now, I would be really happy if there was some workaround until this is fixed as I simply can't use the router at all ... |
l3u: Here are the "vanilla" logs after booting. The only difference is that, after
if the LAN cable is plugged, dnsmasq is restarted, and a line
appears, so the dynamic IPv4 range is set. If no LAN cable is plugged, dnsmasq is not restarted and no IPv4 range is set. |
l3u: Restarting dnsmasq automatically also does not help. I tried to trigger the restart via /etc/rc.local, but still, no IPv4 range is set -- as long as no LAN cable is plugged. When I boot up without a cable, plug it, request an IP address (getting no IPv4 address) and login via IPv6 and THEN restart dnsmasq, the IPv4 range is set. |
l3u: The problem happens/shows up inside the dhcp_check() function of the dnsmasq init script. In both cases (plugged/unplugged), this function is called only once, with $ifname set to "br-lan" and $stamp set to "/var/run/dnsmasq.cfg01411c.br-lan.dhcp". If the LAN cable is plugged, the function completes and returns 0 at the end, which then results in the dhcp-range line being added to the config by dhcp_add(). If no LAN cable is plugged, the function returns at
This causes dhcp_add() to return before the dhcp-range line is added. When the device boots up without a LAN cable plugged and one sets an IP address manually (or uses the IPv6 DHCP address which can be obtained in this case), logs in and runs
it returns "true". So I'm pretty sure that this is some hardware-specific timing problem or similar. I'm not deep enough into OpenWrt (yet), but it looks like the LAN bridge does not have a "carrier" without a LAN cable being plugged when it should have one. |
l3u: This actually seems to be a timing problem. I added the following code before the above check:
Which results in the script to wait for 7 seconds and then starting up as expected, with working DHCPv4:
|
l3u: Another workaround is to add the "force" option to the "lan" section of /etc/config/dhcp. Question is if the default image simply misses this option and it should be pre-set to get a working "vanilla" installation – because by setting it, the dhcp_check() function is skipped and thus the carrier problem does not show up (and is possibly not solved but only hidden). |
l3u: I also filed a bug at Gl-iNet: https://bugs.gl-inet.com/view.php?id=146 They say the problem is known and they work around it by using the "force" option. According to the forum post, the dnsmasq init script should not check for the device state at all if binding 0.0.0.0, so perhaps, the init script should be fixed? |
techmunch: Set the workaround and it's working well now. Still needs to be fixed. |
l3u:
This is 100 % reproducible with a fresh and unchanged installation of OpenWRT 18.06.2 on a GL-Inet GL-AR150, and it gave me quite some headache until I found out what's happening here:
If a LAN cable is plugged during the device's boot process and one does a DHCP request when it's ready, the router offers an IPv4 address (as expected) and one can access it on 192.168.1.1. This is also the case for a DHCP request via WLAN, as soon as one does enable it.
If however the device is powered up without a LAN cable being plugged, no IPv4 address will be offered, neither for a LAN nor for a WLAN connection. One can connect to the router via the IPv6 address to be found in /etc/resov.conf (on the client) though, but not via IPv4. This is also the case if a LAN cable is plugged after booting.
Looking at /var/etc/dnsmasq.conf.cfg01411c, it does contain the line
if a LAN cable has been plugged during bootup, and no such entry if none has been plugged.
This makes the device completely unusable for what I intend to use it ... as this happens with a completely unaltered, fresh installation, I suppose this is no misconfiguration but a bug?
The text was updated successfully, but these errors were encountered: