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.
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.
No, the main router provides 192.168.0.0/24 and the Netgear 192.168.1.0/24.
The WLAN interfaces get 192.168.0.5 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 21.0.2.1.
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.
With both radios on using client mode the WWAN interface does not get an IP address. See first picture.
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.
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?
indicates the start of the range. So 192.168.1.100 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.1.100 - 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).
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.
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.