OpenWrt 21.02 - Connection issue in client mode

I have found an issue in the new version regarding client mode connections.
I am using a Netgear R6260 device that should connect as client to my main internet router.
As this device was not supported in older versions I have used OpenWRT 19.07 for the R6350.
This worked fine.
I have two identical R6260 - just to have a spare part in case of trouble.
Now I have one of them upgraded to 21.02 and the connection to the main router does not work as expected. After power on or reboot the two client connections to the main router are associated but the routing does not work. The main network with the gateway can't be reached.
But when I restart the radio devices then it is working. Strange.
After several tests I had the idea to compare the configurations of both versions.
That did the trick. :slight_smile:
With version 19.07 joining the WLAN assigns each radio device to it's own network.
Radio0 / wlan0 and radio1 / wlan1. This works fine.

The new version 21.02 assigns both devices to one network.
As a result the routing does not work after boot.
This is a bug and I kindly ask the team for a fix.

Here is my workaround:
Delete the offending interface wlan.
Add two interfaces wlan0 and wlan1 manually.
Assign to firewall zone.
Configure both client mode connections to use their own network wlan0/1.

Now we have the same configuration as on 19.07.
Apply all changes and reboot.
Then everything is working again. :slight_smile:

Were both networks

If so, routing will not work.

This is normal (i.e. the default config - they're also setup as APs and disabled). Maybe it was different on your model??? :confused:

No, the main router provides and the Netgear
The WLAN interfaces get and 0.6 via DHCP.
This configuration is working now.
But the original with one WLAN interface did not after boot. There was no route to 0.1. Restarting the radios fixes that until next boot.

I spent some time to collect further information.
The R6260 was cleared and flashed again with
Now there is only one interface "WWAN".
Added client mode connections for both radios and joined the main network.
Reboot the router. No route to the main network.
But now I see what is going on. :slight_smile:
With both radios on using client mode the WWAN interface does not get an IP address. See first picture.

When one radio is disabled then the active device is assigned and WWAN gets the IP. Then the routing works fine.

I think it is not possible to have two client mode connections on one interface. We need to have an IP and the default gateway from DHCP.
This might be an unusual case. But I was looking for some redundancy with two independent WLANs.

I did not check the behavior of version 19.07 again.
But I think it came up with two WLAN devices.

My guess is that this is messing with the routing tables (2 WANs with the same subnet).

How is it redundant? I get that you have 2 wifi uplinks, but are the going to the same AP? If so, you don't actually have redundancy -- you have 2 connections with a single point of failure.

Well, I am still testing what is possible with OpenWRT.
The final configuration will use two WLANs from different providers.

Then you will need mwan3 to make that work.

Yes, that sounds very good.
Thank you.

I am also wondering what the DHCP server is doing.
I have just used the default configuration that seems to be
Start 100
Limit 150

But the first client - my PC - gets :frowning:
Is this intended and why that?

And what about the USB-Port of the router?
I would expect to see a share of a storage device like the original firmware does.
Or a printer share.
Has this been forgotten?

Yes... because:

indicates the start of the range. So is the first IP in the DHCP pool.

is the size of (number of IPs in) the DHCP pool.
So, 192.168.100 starting address with 150 addresses in the pool means the range is: - 192.168.249

It is still available to you, but you need to install the appropriate packages.

What you install depends on what you will be using...

in this case, you would install USB storage, file system, and file sharing packages.

here you would install a print server (instead of the above, unless you have multiple devices connected to your USB port).

Not forgotten, but not installed by default. They are installable packages, though. All packages take up some space, and not all devices have a lot of storage. The idea is to optimize space utilization by only including a core set of functions and then allow the user to install packages as needed (and based on what will fit).

Yes, this was my expectation.
But it starts at 1.172.

The pool starts at 100. The actual addresses that are handed out are non-sequential by default -- there is a hashing algorithm that uses the MAC address of the DHCP client and assigns an IP to the client based on the result. This helps devices have pseudo-static DHCP assignments (if you want actual static DHCP assignments, you can set that, too).

If you want to have sequential assignments, there is a setting for that.

Thanks for your explanations.
Which setting controls the generation of addresses?

In the /etc/config/dhcp file, under the dnsmasq configuration stanza, this option:
option sequential_ip '1'

Or, via LuCI: Network > DHCP and DNS > Advanced Settings > Allocate IP sequentially

Hmm, did not work.
Still have the for my computer after reboot.

Try rebooting the router. Then force the computer to renew the ip.

I did this several times.
No change.

The computer is likely asking for a renewal of the same IP it is currently using (172), so you may have to resort to more forceful methods. You might try (temporarily) making the limit value smaller (say 50) such that it excludes 172. Then force the computer to renew (best method may be to physically bounce the connection -- unplug the ethernet or toggle wifi off/on).

EDIT: Just tried exactly this method, and it worked. I could then expand the pool again and the sequential assignment stuck.