package to set wan on all ports

[rubo77]

If acceptable, I would build an option into the Config mode, that sets all ports to WAN, so it doesn't matter any more on which port you connect the node with your internet.

In most places nobody needs the LAN ports to get direct Freifunk via LAN, but the most asked question I get is "On which port do I have to connect"? Also this is a commmon mistake that new users make, to mix up the ports.

Sure, if not needed you can already set this setting on the console with:

 uci set network.client.ifname=bat0
 uci set network.wan.ifname='eth0 eth1'
 uci commit network

Source: https://wiki.freifunk.net/Konsole#WAN_auf_allen_Netzwerkports

[christf]

I would appreciate there was a way to set this such that it works across upgrades.
I once had a hacky gluon-luci package for creating that setting, but since this depends on the hardware model and switch configuration there was only an implementation for tl-wr841 and tl-wdr4300. The solution was so nasty I don't even dare to link it here.

Quite a while ago someone mentioned that with a new network configuration infrastructure this could be resolved in a proper way. Is there a roadmap (not in terms of timeline but in terms of the necessary steps) for this already? If not, can we develop & discuss it here?

[tobox]

I would greatly appreciate that option.

It would help to integrate routers into existing setups without free ethernet ports.

It is also a good argument for some people that need a switch somewhere in their growing home network to use a gluon-router instead of a switch.

[kpanic23]

Actually it would be great, if you could configure the ports like in a table. And those settings should be kept over upgrades.
I've made a little mock-up:

Maybe a button could also be included to create VLAN IDs on the ports to carry two or more of the network types.

[tobox]

Such a port table would be great. But if I had to choose between:

• having the "easy" all ports are WAN solution in a reasonable time and
• having the "cool port-table" in a distant future,

I personally would prefer the first option. I would know of very little occasions where the above mentioned setup is required. The only setup that I need frequently is Offloaders with WAN/Client/Mesh on a single NIC with 3 VLANs (or 2 NICs with 2 VLANs on the second NIC). Neither setup is trivial to implement in the GUI.

[rotanid]

furthermore, the advanced solution is impossible for many devices. on many, the 4 switch ports appear as a single port to the OS.

[Adorfer]

even on those devices it would be nth to setup multiple bat ifs on different Vlan ids. (off course we can do this manually via /etc/config/, that is out

[TomTheDragon]

I think its an really good idea and i am waiting for this for years. Why was this not added from the beginning?
I usually switch the interfaces around, since its easy to do and i still have the option to connect a client (pc or a router) over the WAN port. But yeah its really annoying to undone and redo this change for every update.

I think it would be nice to add options so that you can choose what the two interfaces (WAN Port/Lan Switch) are doing and then maybe set it to bridged (all interfaces to WAN/LAN) by default. A separation for every single port would be cool but maybe a but overkill and not as easy to implement.

Here as an example:

[Adorfer]

Why was this not added from the beginning?

Because there was a hackaton for this ("port based lan function"), but the results never surfaced (as far as i know).
perhaps some people are hoping that it might still be rectreived.

other arguments are:

• "It will not work on all devices, since some internal switches are limited. And it would be unfair for the users of those devices if the feature would be implemented, leaving them behind"
• "since switches and layout of devices are so different we would be able on the first run to implement it only for 841, 1043 and a few others. That would break the confidence of users of for example device x, y or z."

(this how i understood it)

[neocturne]

The feature will definitely be implemented. There are two reasons this has not happened yet and is not on a short-term roadmap:

• There is a plan to migrate the current swconfig-based network configuration to DSA (Distributed Switch Architecture) in OpenWrt, which will expose each switch port as a separate network interface. We will need to provide scripts for automatic migration. To allow this migration to work smoothly, we permit only very limited changes to the configuration
• We try to keep model-specific code in Gluon to a minimum. The reason is simple: It is impossible to maintain. When a more generic change requires model-specific code to be adjusted, it would need to be tested on each supported model separately; as Gluon and OpenWrt are community-driven projects, there is no single party with the necessary funding to create a testbed with all supported hardware.

There is still some preparation necessary in OpenWrt: AFAIK, there is no DSA-capable driver for the ag71xx Ethernet yet, and the migration of ar71xx to device trees (new target ath79) should be dealt with first.

[rubo77]

There is a plan to migrate the current swconfig-based network configuration to DSA (Distributed Switch Architecture) in OpenWrt, which will expose each switch port as a separate network interface.

How far is this probably in the future?

[AiyionPrime]

@rubo77 please have a look at recent nightly builds, I think this issue has been resolved since #2688 has been merged. If you agree, I'd appreciate if you marked this issue as resolved and close it :)

Here are hanovers nightly images: https://build.ffh.zone/job/gluon-nightly-wireguard/lastSuccessfulBuild/artifact/

[maurerle]

I can confirm that this works very well since #2688. So maybe, we should just close the issue?

[AiyionPrime]

@rubo77 in case you disagree, just let us know.