The specific case we are trying to address is where one OpenWrt router is behind another one (effectively). In other words, the upstream gateway for the second router (192.168.1.1) is the same as the second router’s LAN IP address. I guess that you could do the following?
Metric 0 route for 192.168.1.1/32 dev wan
Metric 10 route for 192.168.1.0/24 dev br-lan
Metric 100 route for 192.168.1.1/32 dev br-lan
Similarly, since wan would be assigned an address in 192.168.1.0/24 say .1.100, you might need to add:
Metric 0 route for 192.168.1.100/32 dev br-lan
Metric 100 route for 192.168.1.100 dev wan
to deprioritize the locally attached IP addresses (wan and br-lan interfaces) over the reachable ones on the attached networks. Will have to spin up a couple of devices to test if this actually works.
There are 3 distinct, never overlapping RFC1918 address ranges:
10.0.0.0/8, 172.16.0.012, 192.168.0.0/16
The logic could be quite simple:
If the current LAN subnet conflicts with the WAN network, select any /24 from one of the other ranges.
In fact, it can be even more simple -- set a preferred and a backup subnet. The preferred and backup have one requirement - they must be from different ranges. That's it. If the preferred conflicts, it moves to the backup. There could be a set of defaults defined by the OpenWrt developers (192.168.1.0/24 probably preferred because of history, any other as backup). The user could then change these. That's all it needs to do.
Now to deal with the actual renumbering fallout. If there are clients connected to the lan, they need to be told that their IP address is no longer valid. Can the dhcp server inform clients that they should request a new address?
In the process of getting a new address, the clients dns cache should be flushed, and OpenWrt.lan should then resolve to the new address.
No, the DHCP server cannot recall the leases, and the DHCP cannot "inform" clients to request a new IP. DHCP servers can only respond out when there is a discovery packet (the DORA process). So this could present an issue, and it is not one that would be easy to solve directly.
There are a few possible ways to handle it (not complete solutions)...
If the LAN needs to be changed, the router could bounce the wifi and ethernet ports in the process. This would force all clients that have a direct connection to the router to request a new lease.
this would not solve the issue for devices that are connected to an external switch, or that are connected wirelessly to another AP on the network.
Upon initial boot, it would also be possible to delay the bring-up of the LAN until either the WAN has been issued a DHCP lease or a timeout has occurred (maybe 10 seconds or so)
this still doesn't address the earlier issue for devices not directly connected to the router
and it only covers the case where the WAN gets a lease on boot. Connecting the WAN post-boot would have to rely on the bounce method.
But, if we assume that this issue is not going to be encountered frequently -- really just when people setup a new device for the first time (for example in a home scenario) or connect to a random WAN in a travel/road-warrior type environment, maybe there won't be many devices connected (and hopefully all directly attached). After all, in the default configuration of OpenWrt, wifi is disabled, and typically someone will connect a single wired device directly to the router for initial setup.
Yes, reboot is reasonable, after determination of non-overlapping nets.
Frankly speaking, that is expected by me, anyway.
However, I have the more complicated case with: VPN, WAN, WWAN and WIFIWAN. So, your proposed "basic" approach will not work.
I am aware already, that for a valid solution I even have to assume 192.168.0.0/24.
I think that anything for the "default" setup of OpenWrt should be designed against the simplest scenario. Mainly for the user that doesn't know that a unique subnet is required on the LAN relative to the WAN.
The multiple WAN (and VPN) scenarios would not come up in the default situation. But this could still be handled by the same general logic -- and in the case of multiple networks outside the users control, an option could be available to select a random non-overlapping subnet (this option would be disabled by default so that the behavior would be deterministic for the new setup).
Although I did poo-poo the idea earlier, I can see some value to this, especially for novice users and/or road warriors. And I think that there is a set of workable ideas here and fairly straightforward logic. It's not perfect, but it should generally work.
The next question is really about adoption into OpenWrt as a base feature. Someone could easily create some scripts and/or packages to do what we've discussed, but I'd love to hear from some of the core developers about the possibility of this being developed and bundled into the default configuration.
@richb-hanover-priv (tagging you because you had made an earlier request, and some good ideas, and are a leader on the forums) -- any thoughts on the latest ideas/discussion? And if it looks good, does this get filed as a feature request in a bug or do we tag in some of the core developers to comment further here?
Thanks for the kind words... I am glad to see a consensus evolving toward a solution that makes initial setup for a newcomer to OpenWrt simpler (mostly, that they not worry about subnets as the very first thing they do). Road Warriors are another interesting use case.
I imagine the next steps to be:
Lay out a short description of what we have in mind (I've lost track of the details of this discussion)
Invite notable core developers to comment (I have a couple people in mind, but would wait for #1 before inviting them.)
Test it, perhaps as an optional package, to see if it actually makes anyone's life easier
If #3 pans out, figure out how to make it part of the standard build.
Here's my attempt:
Idea:
Method of automatic LAN network reassignment upon conflict with WAN
Purpose:
Prevent a conflict where the LAN and WAN occupy the same or overlapping subnets.
This issue will cause routing to fail. Most often impacts novice/new OpenWrt users when they connect an OpenWrt device to an existing network using the common 192.168.1.0/24 subnet.
Can also impact road-warrior type users with travel routers since the upstream network may be unknown and may change frequently based on the location.
Assumptions:
Network configuration exists with one LAN and one WAN.
WAN uses DHCP client or PPPoE for address assignment.
LAN uses static IP.
Upstream network will be a properly configured RFC1918 IP such that there will always be some RFC1918 address that is available.
If upstream network is publicly routable or CG-NAT, this issue will not present.
Basic Logical Flow:
On boot, do not bring up LAN interface until WAN is up with an address or an n-second timeout has occurred without a WAN address assignment.
If WAN is not up, continue with ifup for LAN.
The following occurs when WAN comes up (maybe as a hotplug event):
-- Evaluate the WAN's assigned IP address AND subnet
---- If upstream is publicly routable or CG-NAT, do nothing.
---- If WAN has RFC1918 address, calculate the upstream network range.
---- Compare the LAN (address + subnet) with that of the WAN network. If no collision/overlap occurs, do nothing.
---- If there is a conflict, assign an alternate IP/subnet to the LAN.
------- Bounce LAN related interfaces (ethernet and/or wifi, if enabled) to cause new DHCP client requests.
Basic Functional Configuration Elements:
Preferred LAN address/subnet (default value 192.168.1.1/24)
Alternate LAN address/subnet (default value: ideally any /24 from RFC1918 10.0.0.0/8 or 172.16.0.0/12 ranges)
Enabled on the default installation of OpenWrt (some future major release version).
Option to cover additional WAN networks (to allow multi-wan and/or VPN upstream coverage).
Option to disable this feature.
Possible feature: automatic update of the preferred LAN address if the user changes the LAN in /etc/config/network)
User configurable alternate LAN addresses, list of any number of elements allowed.
Option to enable random address assignment in the event that the above list does not prevent conflict.
Not Covered:
VLANs/multiple LANs would not be covered.
-- It is likely a reasonable assumption that this is not common for a road-warrior travel router config, and most likely users implementing multiple networks would know to avoid conflicts.
No guarantees about forcing DHCP renewals after LAN address change.
-- Bouncing the LAN interfaces should work, but will not help for devices that are not directly connected (i.e. via a downstream switch or AP).
Cannot force reassignments of static IP based hosts (obviously).
May cause issues with static DHCP host assignments.
Other:
All configuration would be in a new config file (i.e. /etc/config/auto_lan_address or similar)
Update documentation to indicate that https://openwrt.lan is the easiest way to access router
Update documentation to indicate the default address for the alternate LAN address.
Update documentation to describe options, parameters, operating principle of this feature.
A quick google search finds a list like this: common router address list
I am sure there is a more extensive list, but can't we just default to something like 192.168.99.1/24 which is not on that list? That should cover 99% of the cases, doesn't need any serious change, except the references in the documentation pointing to 192.168.1.1. (or a 10.y.x.1) which might be even more unlikely to overlap by default.
IMHO, if the user can't figure out how to change the standard IP range in the of chance that there is a conflict, maybe they shouldn't be using openWrt at all.
Sorry, this is one of the reasons of the unfortunate decline in software quality. From an old, good German engineer, who in his youth was already used to >99.98% availability of the whole computer system (hw+sw), he was participating in to develop. (99.98% availability to be demonstrated to the client by means of statistics, kept during first year of operation, 24h/365d) .
How reliable is a software system, consisting out of 100 modules, for example, in case every small module is just built for 99% correctness/reliability ?
By that logic ANY router I buy of the shelves will have a default IP address and would therefor not qualify for "correctness/reliability" ?? Your suggestion to even "randomly" assign a new IP (range) every boot. On the same logic even "openwrt.lan" might be wrong: I could be connecting a router behind another OpenWrt device which also is associated with "openwrt.lan".
All of these "features" are bloating the basic OpenWrt. I am still annoyed EVERY TIME! by the "feature" that when I change the basic IP address and don't change it fast enough in my browser it will revert back the change! My simple workaround is NOT to use LUCI and just SSH into the router and get it done properly. I can probably find lots of examples where there is a lot left to be desired on the GUI part.
So instead of automatic renumbering the LAN in case of conflict with WAN, why not focus on things that are actually broken or (still) not working properly? (Which doesn't exclude that fact that we could change the default IP to a less used one as I suggested).
One of my TODO projects is to have a better DSA GUI switch interface (more similar to the old one) and to allow users to easier manage VLAN etc.
Why is it a problem here, to keep this as the "default" behaviour, after every boot ?
Just in case, the router is connected to another LAN. NOT to do it on every boot, means, its not "Plug and Play" any more.
The user then needs to know about the routers internals. Which I do not consider a good principle, if it can be avoided.
So, again, where is the problem here ?
Eh...doesn't that go against the whole OpenWrt principle: The freedom to configure and install user/use-case specific packages. Doesn't that imply that the user needs to know about the routers internals??
Ok: you started with a use-case of daisy chaining two routers. Normally one would connect LAN (device 1) - LAN (device 2). Disable DHCP on of them. That doesn't answer the question about automatic renumbering as the problem doesn't exist anymore. Further more it will eliminate double NAT.
To have an OpenWrt router check and renumber its own LAN on every boot if it detects a conflict with the WAN connection is not something I would like to see as standard feature. What if the "second" router boots faster than the first? It would have to wait to hand out IP addresses until it has a WAN connection. Leaving the device unreachable to even troubleshoot "why" there is no WAN connection. The "first" device is also running OpenWrt, so that one is also not handing out any IP addresses until the WWAN connection is establish.
Another issue with renumbering the LAN every reboot is "Static Addresses". All those would be invalid. How would you handle that in a script?