Hello,
i'd like to propose a change of the default LAN network address from the traditional 192.168.1.1/24 to something more uncommon (for example: 192.168.123.234/24).
The reason for this is, that apparently not so few people connect their OpenWrt router to another (ISP) router which sometimes uses the same address.
This way the OpenWrt router becomes unaccessible.
This might be a benefit for those people that don't have a solid knowledge about networking and OpenWrt.
Although, in general you are correct, I think a better solution would be to dyn check own upstream IP (i.g. WAN) on boot, and, in case a conflict with 192.168.1.0 detected, change own LAN adrs. Not too difficult, as in worst case it requires an auto reboot after change of LAN-IP.
if the IPs/subnets overlap, don't bring up WAN, generate popup saying LAN subnet must be changed, and a "Confirm" button ?
Might have been a good idea for 15.05 
Because no solution, when using different (W)WANs …
there's only one WAN post install, I fail to see why it wouldn't work.
once you've started tweaking, all bets are off anyway.
Whenever having alternate (W)WAN, i.e. WAN-Wifi, WAN-lte, WAN-eth, you might need to re-arrange LAN-IP after boot. Not only after install. Or not.
Of course, mwan3/4 eben complicates the scenario, but should be handled using hotplug tricks.
this was for newcomers, people that hadn't used openwrt (much) in the past ?
if you have multiple WANs set up, you (probably) know what you're doing.
One more arg, to keep it fully automatic.
sorry, but I disagree, if it's automagic, people will start asking why they can't reach their router at 192.168.1.1.
Can you log on to the webinterface by going to openwrt.lan?
Does not work for me.
openwrt.lan might not be reliable, if browser/OS uses DoH, DoT, etc.
it does work for me, but I've disabled secure DNS in my browser.
it's also unrelated to the default IP discussion.
It's not possible (and wouldn't be a good idea either) to dynamically change the lan address.
On the one hand wan comes up in an asynchronous fashion, usually much later than lan (or never), on the other hand it can change any time on the whim of the uplink provider. But once clients are connected, you can't change the router's lan address anymore - DHCP leases can't be invalidates before they run out naturally (12h by default), static addresses not at all (and I don't even want to think about static DHCP leases and other DHCP/ DNS configurations).
As frollic implied, any changes will be a major documentation issue - and how much time would that buy you anyways, considering that (almost) all commercial modems and routers are using OpenWrt as their base (and therefore might follow the change in 2-5 years). Nothing to be won here, just even more needless pain.
Yes, it is smart not to use any of the common IPv4 subnets often used by other networking devices, but which actually are safe can only be a deliberate administrative decision. And judging from personal experience, I had to renumber my network several times in the past, be it because cellular ISPs thought 10.0.0.0/8 would be fair game - or because I had to accomodate for remote business networks via VPN and had to change my network to deal with those.
What I learned out of that, is to never use any statically configured IPs at all (apart from my central router's lan IP). Everything -exclusively- using DHCP (with heavy use of locally assigned static DHCP leases and local DNS usage). That way, I can at least do the renumbering once, on my router (with bulk changes via awk/ sed), with all the clients at worst needing a reboot (well DHCP release/ refresh).
I believe the concern you raise is valid, especially for users installing OpenWrt behind an ISP router where the 192.168.1.0/24 subnet is already in use. This is one of the most common situations where access is temporarily lost after changing the LAN subnet.
However, it's important to note that OpenWrt doesn't perform true "conflict detection" between the LAN and the upstream network in the strictest sense. In most typical configurations, it has very limited visibility into the actual upstream network topology, especially when the WAN is behind another NAT router or a modem/router combination. Therefore, LuCI’s behavior is more of a safety mechanism related to the configuration change itself, rather than an analysis of the external network.
This is also why the current behavior is intentionally conservative: the system tries to prevent accidental lockouts when changing the LAN subnet, rather than automatically adapting to what it assumes is the upstream network.
That said, your idea of improving the default experience is still very valid. In practice, the initial setup process tends to favor explicit user control and predictable behavior, which helps ensure that the router remains accessible even in edge cases.
Agreed, this would invalidate a hotplug-solution for running system. However, we are more talking about install or boot time. And then it is possible, opposed to your comment. As soon, as WAN is up and has IP, to check against LAN. And, in case of conflict, mod LAN-IP, and reboot.
Not to forget, in case of problems, users often powercycle the router. And then the network conflict will be taken care of, in case it still persists.
TL;DR
Short form:
Not necessary
Full story:
Actually, no, it does not make the router inaccessible, it only makes upstream (aka Internet) access (mostly) inaccessible - on ipv4, ipv6 will work just fine.
There is also the argument that if you do not understand ip addressing, you should research it properly before flashing your router...
Your argument is used by some manufacturers, GL-inet being an example with their custom forks of OpenWrt - ie 192.168.8.1.
They do this because a large number of target users are typical domestic users with little or no knowledge of the ins and out of routers and they strive to reduce support questions.
In summary of what I just said:
