I am running firmware version 4.7.4 beta 1/release 1 to resolve WireGuard configuration issues.
Everything was working fine until I left for vacation. Before traveling, I unplugged the Beryl AX and packed it in my suitcase. When I powered it up during my trip, client devices could no longer access the internet. Now that I'm back home, the issue persists—clients connected to the Beryl AX cannot reach the internet.
The Beryl AX is in repeater mode, extending the Wi-Fi signal and obtaining an IP address on the host network's LAN. VPN tunnels are disabled, and I've tested different DNS settings in the GUI, but it remains in automatic mode.
Although the Beryl AX itself can access the internet and resolve DNS via the host network’s DNS server/gateway it is not routing client traffic. Connected clients cannot ping or access anything online. I have attached a screenshot of my SSH session showing the router's internet connectivity and confirming it is operating in repeater mode—however, client traffic is not being routed.
The LAN network for my clients is 192.168.10.0/24. Does anyone have a solution to fix the clients not being able to access the internet? I'm not too familiar with networking or openwrt.
I would like to fix this issue instead of a reset of the router, since it will help get to the root cause.
EDIT: After searching the forums, this seems to be a very common problem with the beryl ax/firmware. I think there is a bug somewhere when a power event happens.
To have an exact view , please give precise description of the connection.
There is no such thing as "repeater mode".
There are 4 internet connection methods: repeater, ethernet, thetering, cellular.
There are 3 network modes: router, access point, extender
The Beryl AX is in repeater mode, extending the Wi-Fi signal and obtaining an IP address on the host network's LAN.
OK the connection is "repeater", the network mode is "extender".
In extender mode client traffic is not routed and not NATted, it is a Layer 2 bridge. IP adresses are not touched, packets are sent between the WAN and LAN interface.
However wifi 802.11 enforces the use of the GL.inet WAN interfaceMAC address, with the clients IP address. The host LAN can get very confused, its DHCP leases show the clients MAC addresses, but the packet must be sent to the routers (wifi) MAC address.
Sometimes this works, sometimes however this setup fails. The Beryl must translate the MAC address in reverse direction, and forward the packet to the correct client. (Based on a table cached with MAC&IP addresses built with the initial connection in the other direction (from the client) )
Connection initiated from the client should work, if they get a proper IP address from the host LAN. (DHCP sometimes fails because the DHCP answer does not reach the client device). Some DHCP servers refuse to give more IP addresses to that same MAC address. Transfer from a host LAN to the client will fail if the MAC&IP address table times out.
The Beryl AX is repeating the hotel WiFi and is set to router mode. I hope that clarifies things.
I suspect there’s a bug where LAN-side clients lose the ability to route to the WAN after [xyz event]. The cause of this configuration loss is unclear, so I’ll need to deepen my understanding of Linux routing to analyze how br-lan is being used and routed to the WAN.
After posting, I found several similar reports of the same issue.
I would try "traceroute" to find out where the connection stops.
"tracert", "mtr" or other similar command eg: "C:> tracert -d 8.8.8.8"
Router mode will indeed show the router step in this connection.
The route is starting from your client device with an by the Beryl assigned LAN IP address, or a static IP address in that Beryl LAN subnet, with the Beryl IP address (like 192.168.8.1) as the next step. Then follows the uplink AP IP address, etc etc
If the Beryl AX loses the uplink connection, it might drop and restart the local wifi, if on the same radio.
Is 192.168.10.0/24 your Beryl LAN subnet or the uplink subnet ?
thanks for the info, due to time constraints, i had to reset the router. I'm sure this bug will eventually crop up again. Yes i do understand that it has to hit the gateway of my LAN first which in this case is 192.168.10.1. I am not sure if understand correctly the drop and restart local wifi comment. There doesn't seem to be a radio device start or stop. But i'll pay closer attention to that next time. I think it's a linux routing issue/bug that happens where the route gets deleted or changed.
Drop and restart is a reaction to loss of internet connection (as detected per Multiwan setting, like ping to a public IP address, designed for automatic failover/balancing to another uplink (WAN port, thetering)). Failure mechanism is according the "multi WAN" setting. The "hotplug" action stops the current connections and sessions, and reloads the firewall, also is taking quite some time to rebuild the local wifi.
The multiwan interface status tracking can be disabled
