Automatic LAN subnet reassignment upon conflict with WAN

[psherman]

So to be clear, I am not married to this idea. In fact, I originally thought it was an unnecessary and silly request (if you refer to the links in the RFC description). However, I came around because I realized we actually see this issue quite often in the forums from people who are network and/or OpenWrt novices. It felt like there could be some 'automatic' means of helping them.

@clutch2sft

Marking the WAN down (or changing metric to make it appear down) seems logical and easier.

But, unless this process easily leads the (novice) user to a solution (and helps them learn), it doesn't seem to actually solve the issue (i.e. "internet doesn't work from the OpenWrt lan, but OpenWrt's diagnostics work just fine").

@clutch2sft

Then some sort of documenation or notification of the problem to the end user is also logical to point the user in the right direction.

Documentation of WAN/LAN subnet conflicts already exists, but that doesn't seem to help many novice users who don't really understand why it isn't working and don't know that there is ample information in the OpenWrt documentation.

Detecting the problem and providing a link from within LuCI may not be all that useful since the user may not have the ability to reach the internet due to the address conflict.

@patrakov

You are correct about the return traffic being the problem here. The existence or non-existence of the ARP entry about the client on the router does not affect the decision about the outgoing interface - it is purely a routing decision, based on the routing table only, and nothing else.

In all the years I've been helping on the forums here (and it's been quite some time), I cannot recall a single instance of a user saying that they couldn't reach the OpenWrt router. I do agree that there is a theoretical possibility that it could happen, but I think it is very much the exception rather than the rule. If you can point me to users who have actually been unable to reach their OpenWrt router from a directly connected computer when they have this subnet conflict, I will absolutely admit that this is real and that I was mistaken. But I really think the concern is theoretical only.

@patrakov

And yes, 192.168.1.1 is entrenched into documentation, and we can't change the LAN network automatically even if a conflict is detected.

I held this opinion at first, too. But now I very much disagree with this philosophy. Here's why:

• 192.168.1.1 will still be the default.
• The address/subnet will only change in the event of a conflict.
• There would only need to be one alternate address by default, so it the router would either be 192.168.1.1 or (just throwing it out there) 10.0.0.1.
• We can clearly document the default alternate address/subnet.
• saying that "we can't change the LAN network" is a thing of dogma.
  • Just because there is historical use of one network address doesn't mean that it can't be changed.
  • Other things have changed over time that were 'always' a certain way, until they weren't.
    • swconfig is being deprecated for more platforms with every new release, but we always used swconfig until DSA came around.
      • now we have new documentation explaining how to use DSA.
    • There are syntax constructs that have changed over the years, even though some of them had been very well entrenched and used for many many versions of OpenWrt (for example: the bridge used to be defined inside the network interface stanza, but now a bridge must be defined as a separate device)
    • IIRC (and I may be wrong about this) wifi was enabled by default on early versions of OpenWrt, but obviously now it is off by default for good reasons.
  • Nobody is proposing changing the actual default address, just adding an alternate that will be known and allow normal routing/internet to work in the event of a wan/lan conflict.
• If we update the documentation to prefer using openwrt.lan as to reach the router in the default state rather than by an IP address, that makes the potentially different LAN IP address a non-issue.
  • This can become 'entrenched' in the documentation moving forward (as can the default-alternate address).
  • The openwrt.lan idea (proposed by @richb-hanover-priv here was literally the moment I was convinced... it's so simple and will 'just work!'

@patrakov

The best that we can try to achieve is to make sure that the client can communicate with the router (to reconfigure it) even when the WAN network conflicts - by changing the metric, and displaying a warning.

I think that this would be preferable compared to the current situation since novice users don't understand why the internet isn't working, and some warning or guidance would help point them in the right direction), but I don't think changing the metric really solves any real problems (again, I cannot recall ever seeing a thread where the downstream OpenWrt router itself had become unreachable), and it certainly doesn't resolve the problem of routing not working without user intervention. And novice users may still be really frustrated since this may be beyond their current skill set to resolve.

Also, and I cannot stress this enough: this feature is not for us (by us, I mean those of us discussing in this thread, with the possible exception of travel-router carrying road-warriors). This is for the person who is completely new to OpenWrt and may not have much, if any, real network configuration experience. OpenWrt is billed as a superior option compared to most vendor firmware (and it really is, in most cases), but the new and novice user just sees a router that doesn't work and is super frustrated. When you look at it from a beginner's perspective, this can really improve their initial experience with OpenWrt.