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).
OK, sounds reasonable.
Random selection of a subnet might be the easiest way to go in my case, I guess.
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:
Who wants to take a stab at #1? Thanks.
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:
Basic Logical Flow:
Basic Functional Configuration Elements:
Not Covered:
Other:
Yes, but... this should be done only during the "first boot", or untill a user configures the router properly.
Do not think so. Should happen on every boot. As the router might be attached to another WAN.
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.
Strongly disagree.
Firstboot only, and then maybe an opt in configuration item that can be useful for roadwarrior setups.
No way should it be a default behaviour at all times
I'm wondering.
In the flow of logic, I read
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??
I will appreciate, first to receive answer to my question. Then you can expect an answer to your question, of course.
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?
Not necessarily. More logical from users standpoint of view is LAN(1) -> WAN(2). I also do it this way, although (or because ?) having a few years expirience already. Double NAT usually not a problem nowadays.
And ? 2'nd router can not connect to internet, anyway. Regarding maintenance, in "Basic Logical Flow" there is a timeout, to bring up LAN, in case WAN comes not up. So you can login.
Thus, until now your arguments do not really apply.
Sorry, I do not understand your last paragraph. Please, elaborate.
I wonder about this, will the system know if multi interface applies and what does it do then?
And if no interface called lan exist to begin with?
I still feel that if this function is made is should be default OFF.
Probably 99% of the world doesn’t even have this problem if the ISP does their job to begin with.
Wouldn’t it be better to block the whole wan connection if the system feels a conflict with the address it is given by upstream DHCP server. Instead of messing around inside the whole internal network.
Then the user will have to log in and fix the problem.
Wow... quite the discussion!!
I'll try to address comments here. For the record, I was not fond of this idea at first, but I came around to see the value, especially for novice users. And it is really important to note that my proposed solution is not intended to address every possible permutation of network conflicts... it just tries to handle the most common WAN/LAN conflict scenario that negatively affects new/novice users.
I'm not 'attached' to this, though -- if the OpenWrt community (or maybe more accurately the primary dev team) deems this to be a risky/problematic/confusing feature and it doesn't get implemented, so be it.
For this to work, I think that it needs to be on at all times until disabled. If it only runs on "first boot" it means that the feature won't be useful to many new users. Example: a new user doesn't connect a WAN at first, but sets up things like wifi and time zone or whatever, but does not change the LAN. The user llater connects WAN but has a conflict... if the detection only happens for first boot, the (novice) user may not understand why things are not working properly and they will still come to the forum with this basic question. That is what we are trying to help resolve.
I think that there would be a lot of pushback to change the default OpenWrt LAN address... in large part because it is known and well documented everywhere on the web -- well beyond the scope of OpenWrt.org. Not to say that we should live with dogma forever. But this idea of conflict detection would allow the default to remain the same while offering a (deterministic by default) alternative address if a conflict is detected.
I'll be honest that sometimes I have this feeling, too. But then I remember that we all had to learn this stuff at some point. And there are many reasons someone may use OpenWrt, even if they are a novice user. If I look back on my own progression of networking knowledge, it is clear that I had to use more advanced environments (OpenWrt, EdgeOS, Unifi, others) in order to have the features available to learn in the first place... I surely made lots of mistakes and had lots of gaps in my knowledge... but by using these platforms, I learned a ton. The idea here is to alleviate one of the common pain points that happens for new/novice users.
The logic I laid out would either use the existing default (192.168.1.1/24) or a known/default alternate (say 10.9.8.1/24 as an example), based on what is happening upstream. If there is no conflict wit the current WAN address/status, the address would not change. Therefore, it is not changing randomly on every boot. The only 'random' feature here would be if engaged by the user for a situation like the road warrior context because the upstream networks are unknown, may change frequently, and there could be several concurrent connections (cellular, wifi wan, wired wan, VPN).
That could happen. But in the default state, the DHCP issued DNS resolver would be the router to which a client is directly attached, and that resolver should theoretically not look upstream since it will (by default) have the local entry for openwrt.lan.
As I mentioned earlier, IMO the problem could very easily occur after the first boot has happened. Keep in mind -- the proposed logic is to do nothing unless there actually is a conflict.
We should always remember that people who are new to OpenWrt (and/or networking in general) may be using this platform to learn. Some people just want to have a more secure alternative than the vendor supplied firmware. Others want to extend the functionality -- sometimes with basic config changes or simple package installations that are not available in the vendor firmware. Still others want to dive in deep. Not everyone knows the internals, but they can/will learn it as needed.
I agree with @reinerotto here -- many (especially novice) users connect LAN(1) > WAN(2) and end up with a conflict. That is what we are trying to address here.
The default configuration always includes an interface called lan. This is the context for which I am proposing a solution. If the user has changed this interface, or if they have multiple LANs configured, it is probably a safe assumption that they have enough networking knowledge to understand the issue with overlapping subnets. Further, if you're dealing with multiple networks, you may have numbered them in a particular way, so we don't necessarily want to start changing those other networks.
If it is default off, it defeats the purpose of trying to help novice users get 'unstuck' with a cascaded router situation that isn't routing. Obviously this could just be an optional package instead -- maybe implemented within TravelMate or something similar for the road warriors. However, this is intended to solve the problem of the cascaded routers for the newbie.
If you mean that the ISPs themselves aren't directly issuing addresses in the 192.168.1.0/24 network -- yeah, that's not a problem. ISPs should always be using public IPs or CG-NAT. Some use the 10.0.0.0/8 range (even though they're not really supposed to), so again, no conflict. But many ISP supplied routers use this subnet. So, if a new user plugs an OpenWrt router into their ISP router (a device that may be required and may not have a bridge mode option), that is when they will see the problem.
Again, remember the proposed logic only changes things if there is actually a conflict. Otherwise it does nothing, so there is no downside to having this enabled by default, IMO.
I am just one of those users that hates when software makes magic decisions on my behalf, no matter how well intended. If I decided to configure WAN and LAN on the same IP segment, I want OpenWrt to respect that decision, no matter the catastrophic consequences.
Besides, this whole idea is only valid as long as there is one WAN interface, named "WAN", and configured as a DHCP client, plus one LAN interface, named "LAN", and configured as a DHCP server... OpenWrt should not assume that the current configuration matches the default configuration, and can make changes based on assumptions about the default configuration.
This is why I think it would be a bad idea to make unsuspected changes to the configuration, after the user has configured the router to meet their needs.