Routed AP configuration - WiFi adapters - DHCP issues in OpenWrt 23.05.2 (and 22.x.x)

[helloyello]

Hi,

since around OpenWRT 18.x when I discovered that I can un-bridge the WiFi from the LAN Switch(bridge) I've been following the Routed AP configuration for all further installations up to OpenWrt 21.x.x
Reference:

Routed AP

At that time (around OpenWRT 18.x.x), my first (and still actual) target was a D-Link DIR-860L B1 which comes with 2,4GHz & 5GHz WiFi adapters. I didn't know how to bridge them in a unique/atomic "WiFi network (device bridge)" and went on to split them in two different networks.
Summary in LuCi: - defined two WiFi interfaces/networks "wifi2" & "wifi5" each pointing at the appropriate HW WiFi adapter and assigned these networks to two different (again, named them wif2 & wifi5) firewall zones. LAN network (eth bridge) was 192.168.10.0, wifi2 192.168.20.0 and wifi5 192.168.30.0
Dropped the forward between these networks (LuCi - firewall section) and only allowed particular and preferential traffic between them (also themselves) and LAN with iptables custom rules.

Now, some time ago, noticing that OpenWrt 21.x.x is not maintained anymore I gave OpenWrt 22.x.x a try and learned that I cannot make it work in the same fashion like OpenWrt 21.x.x
Specifically, the whole configuration form above works - LuCi permits me to configure it, but apparently the DHCP service only works for the wifi2 network. Actually it looks to work only for the first defined (LuCi order) WiFi interface. Basically I only have two DHCP sessions serving, one for LAN, one for wifi2 and none for wifi5.
Went further and tried to bridge the 2,4GHz&5GHz WiFi adapters by creating a new interface in Network>Interfaces>Devices, only to find out that I cannot choose it in the drop-down while editing the newly defined wifi interface in Network>Interfaces.
The same issue is present in OpenWrt 23.05.2, which I tried now.

I guess it's a bug either in LuCi or in the OpenWrt conf/subsytem. Haven't checked the network config file as I'm not particularly savvy with its format and syntax.

Would be thankful for any hints/advice.

[psherman]

Just make an empty bridge, then use that bridge as the device for the network interface. From there, you can assign multiple ssids/radios to the same network.

If that doesn’t answer the question, I’ll give you guidance based on your config.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

[helloyello]

Thank you very much for your prompt reply. Will try your advice later in the evening and come back with the results.
Currently I need the router (it's my main router) as it is for my work and it's running OpenWrt 21.x.x

[helloyello]

I haven't had a chance to play with the empty bridge you proposed. Looks like a hack and I don't understand why a "non empty" bridge, actually a fully defined one with both wifi adapters like I already defined, didn't do the job. That's why it wasn't listed in the drop-down menu from the field Device in Interfaces » wifi (so I could assign/use it).

Meanwhile I inspected /etc/config/dhcp from the actually running OpenWrt 21.x.x:

config dhcp 'wifi2'
	option interface 'wifi2'
	option start '100'
	option leasetime '12h'
	option limit '50'
	list ra_flags 'none'

config dhcp 'wifi5'
	option interface 'wifi5'
	option start '100'
	option leasetime '12h'
	option limit '50'
	list ra_flags 'none'

and started to consider that maybe due to a glitch in LuCi from OpenWrt 23.x.x there was no entry for the wifi5 interface populated in /etc/config/dhcp. That would explain why the DHCP server was not serving the wifi5 interface.

However, unfortunately due to the latest adoption of nftables and the ... lets' say "inconveniences" I have with it, I'm disconsidering the further use/upgrade of OpenWrt. Will stick to the actual OpenWrt 21.x.x and meanwhile considering to switch to another solution. More on this here:

Nftables compatibility and performace issues in OpenWrt 23.05.2 (and 22.x.x)

Hi, ATM I'm still stuck with OpenWrt 21.x.x on a D-Link DIR-860L B1 and since I noticed some developments with the possibility to add a custom firewall in OpenWrt 23.x.x I considered to switch to the latter. Reference: Now, since I'm very comfortable with iptables, have more than 2 decades of system/network admin experience (that's accustomed with laggy remote shells/terminals, rather dumb editors like vi in which you don't really look to produce fancy accolades indentations ... and happy to…

Again, thanks for your prompt help, hope the discussion here will aid some other users experiencing the issue I described in the OP.

[psherman]

@helloyello

Looks like a hack and I don't understand why a "non empty" bridge, actually a fully defined one with both wifi adapters like I already defined, didn't do the job.

To be clear, it's not a hack. If you don't understand it, it's best to ask why I recommended it... I'll go ahead and tell you since it is important and will benefit future readers.

The wifi adapters should not be defined in /etc/config/network -- they should only appear in /etc/config/wireless -- SSIDs and their respective networks are defined within the latter file.

Likewise, the default state (for most devices) has the lan defined as a bridge with the ethernet port(s) specified but not the radios.

Maybe this makes it more clear why you need a bridge that has no apparent entries. In this case, you're not using the ethernet for the lan, so that wouldn't appear there. But as described earlier, the radios should not be in this file, either. Therefore, you have a bridge that appears to be empty within the config file, and is actually empty in the early stages of the network initialization.

In certain situations, the bridge will not be created because there's nothing to attach. That's where the empty bridge option comes in... it ensures that the bridge is created even if the radios+SSIDs haven't yet been initialized. It tells the kernel to bring up the empty bridge anyway, such that the radios, as they actually come up fully, can attach to the network (via the bridge) as would be expected.

@helloyello

and started to consider that maybe due to a glitch in LuCi from OpenWrt 23.x.x there was no entry for the wifi5 interface populated in /etc/config/dhcp. That would explain why the DHCP server was not serving the wifi5 interface.

I'd be surprised if there was a glitch of this type. It is certainly possible that a DHCP server was not created for a specific interface, but that is more likely related to possibly forgetting to save and apply changes than a glitch/bug in LuCI. If there was such a glitch, it would likely be rather well documented by now -- this is not an uncommon task, and this would be reported by many users if there was an issue.

If you truly believe there is a bug of this nature, please try again and then provide the steps to reproduce it. It's important that it is discovered and fixed.

That said, if you were attempting to connect more than one radio to a given network without a bridge, that would have been the root of the issue you were experiencing. That I can say with great confidence.

@helloyello

However, unfortunately due to the latest adoption of nftables and the ... lets' say "inconveniences" I have with it, I'm disconsidering the further use/upgrade of OpenWrt

It would be useful if you could describe what specific things you wish to achieve with the firewall. In many cases, standard UCI firewall rules can do what you want, and then there is no need to worry about the nftables underpinnings. In other words, unless your firewall rules are rather complicated, you don't need to touch the lower level firewall implementations in the first place. And the UCI firewall syntax/rulesets have largely been the same for many revisions.

I'd also like to point out that 21.02 is EOL and unsupported. It is now beginning to become vulnerable to attack due to the fact that it has not been patched (and will not be patched) for CVEs that have been (or will be) discovered since May 1, 2023.

[helloyello]

Hey! Thanks again for your inputs!

It looks you're fluent in English, might be your native language. Having said that, please do read again what I wrote in detail in the OP (the steps in LuCi, the bridge I tried to create containing both WiFi HW adapters ... etc).
Reading your last reply now It looks like you missed all those details.
For the nftables part, please do read that whole thread, there are many details provided there,

[psherman]

@helloyello

the steps in LuCi, the bridge I tried to create containing both WiFi HW adapters ... etc

I thought I addressed that...
A bridge (which is defined in /etc/config/network) should never contain the radio hardware.

@helloyello

Went further and tried to bridge the 2,4GHz&5GHz WiFi adapters by creating a new interface in Network>Interfaces>Devices, only to find out that I cannot choose it in the drop-down while editing the newly defined wifi interface in Network>Interfaces

This was the case because you are not supposed to do it this way. You don't bridge the radios. You do the following:

1. create a bridge (/etc/config/network)
2. use the bridge as the device for a network interface (/etc/config/network)
3. assign an SSID to use the network interface by name (/etc/config/wireless)
4. assign a second SSID (on another radio) to the same network by name (again in /etc/config/wireless)

@helloyello

For the nftables part, please do read that whole thread, there are many details provided there,

Which thread?

[helloyello]

You did, but quite confusing ... like I'm LuCi myself editing those config files
Told you I don't touch the config files, and only using LuCi for the initial setup. Disabling everything I'd never need and then just playing with my custom firewall (iptables) for further "developments". I guess you weren't explicit enough and I mean the LuCi menus/sections:

The wifi adapters should not be defined in /etc/config/network -- they should only appear in /etc/config/wireless -- SSIDs and their respective networks are defined
within the latter file.
...
Likewise, the default state (for most devices) has the lan defined as a bridge with the ethernet port(s) specified but not the radios.
...
Maybe this makes it more clear why you need a bridge that has no apparent entries. In this case, you're not using the ethernet for the lan, so that wouldn't appear there. But as described earlier, the radios should not be in this file, either. Therefore, you have a bridge that appears to be empty within the config file, and is actually empty in the early stages of the network initialization.

And then in your very first reply:

Just make an empty bridge, then use that bridge as the device for the network interface. From there, you can assign multiple ssids/radios to the same network.

From where? Which section of Network - LuCi? I guess there's a confusion here between your "radios" and my "HW adapters". For me a HW adapter is for instance phy0-ap0 (just had a look in TP-Link TL-WR841N v13). That's the actual HW adapter the Linux(kernel) is seeing and this is the one I would bundle in a bridge (if the router would have a second one on 5GHz) or use it as the "HW device" which an Interface (called like that in LuCi) would use. Note that apparently interface is the same with network in LuCi/OpenWrt abstractions.

Now, in the default setup OpenWrt comes with lan & wifi HW adapters all bundled in a bridge. In OpenWrt 21 I have to split them (break the bridge) and then define one interface/network for each WiFi HW Adpater. This is also working in OpenWrt 22/23, but the second WiFi Interface network (Luci terms) while properly defined is not offering DHCP to its clients. And here is where I suspect a bug in Luci OpenWrt 22/23.

On nftables - that thread I already inserted in the post above as reference:

Nftables compatibility and performace issues in OpenWrt 23.05.2 (and 22.x.x)

Hi, ATM I'm still stuck with OpenWrt 21.x.x on a D-Link DIR-860L B1 and since I noticed some developments with the possibility to add a custom firewall in OpenWrt 23.x.x I considered to switch to the latter. Reference: Now, since I'm very comfortable with iptables, have more than 2 decades of system/network admin experience (that's accustomed with laggy remote shells/terminals, rather dumb editors like vi in which you don't really look to produce fancy accolades indentations ... and happy to…

[psherman]

@helloyello

From where?

Network > Interfaces > Devices > Add device configuration

@helloyello

Now, in the default setup OpenWrt comes with lan & wifi HW adapters all bundled in a bridge

ethernet yes, wireless no. If you're seeing wireless hardware included in a bridge in a default OpenWrt configuration, it is either very old or it is not official OpenWrt.

[helloyello]

Got it. It's there I tried to bridge the WiFi HW adapters and I understand now this is a no go
But then again, in the OP I said I never did it before, was just attempting it while experiencing the DHCP issues in OpenWrt 22/23 with the Routed AP mode. Considered it as a compromise solution, having both WiFi networks served by the same DHCP server/instance.

I fear I'm a little confused about in which version I saw lan&wifi in the same bridge in LuCi (or at least the symbols/icons bundled together in br-lan). I guess this recent GUI change in LuCi with interfaces and devices is to be blamed

[psherman]

Regarding your other thread - it is not clear what your specific firewall goals are - just that you have 200 lines / rules written in nftables. If is possible that these could be simplified and implemented as uci rules, making it much easier to configure and maintain.

[helloyello]

Summarized in the latest (pretty long) post already.

Nftables compatibility and performace issues in OpenWrt 23.05.2 (and 22.x.x)

I genuinely believed you were interested in what I exposed in my original post and looking to add value to the discussion, hope you still are. In this respect, please do not spread false information and false personal attacks/accusations, read again more carefully my original post instead. Just to clear your confusion, I reiterate: I do have around 200 iptables rules, around half of which are simple traffic integrity checks, flood protections and co., I provided already a snippet from these in …

Just to clear your confusion, I reiterate: I do have around 200 iptables rules, around half of which are simple traffic integrity checks, flood protections and co., I provided already a snippet from these in my original post. The other half are normal interconnection allowances (local services) between Wi-Fi, LAN stations and some forward (to the internet) filters, the latter mainly taming Redmond and some smart devices that want to call home.

But this is my personal FW in this very particular setup. I don't see how one could simplify an iptables rule in uci rules, a rather wasteful unification standard serving internally in OpenWrt/LuCi.
Then there is the flexibility I have - regarding OpenWrt as a simple console router/firewall - ssh into it and add/delete some rules, solve the problem elegant and easy.

I'm sorry I simply can't respect unfinished work - that's nftables.
Furthermore, the syntax and usability is a total PITA (described some details already in that thread) and the performance impact is really high.
I'll be OK now with some SH affordable fanless thin clients (quad core celerons and such) at ~ 60EUR and will be running Slackware on them. Perfect for VPN tunnels too. Don't really need VLAN functionality, a USB gigabit Ethernet adapter is ~ 10EUR + a gigabit switch costs also ~ 10EUR nowadays. A little waste of resources for a router/front end firewall, but then no more painful (major versions) OpenWrt upgrades and fully functional Linux tools/toys. The WiFi part will be a little tricky, on 2.4GHz I already own a bunch of good USB WiFi adapters, 5GHz will be a challenge.

[Lynx]

Urban Dictionary: Last Word Troll

[helloyello]

You have posted exactly after my last post marked as solution. Actually polluting this thread with false accusations.
Please see your other such useless post:

Nftables compatibility and performace issues in OpenWrt 23.05.2 (and 22.x.x)

While the moderators were asleep, understandably during weekend, I took the initiative (and my right) to fight back personal false accusations (call them attacks) from some users and indeed I stepped over my last "ending" argument/post. However, I didn't take offense to your false accusation, considering that maybe you're affected by functional illiteracy (specifically able to read but not having the necessary background to also understand what you read) and unable to understand what trolling m…

[Lynx]

That was @bluewavenet, but it seemed apt, and your responses appear to confirm the same. Look, this is a community of enthusiasts and hurling insults directed at OpenWrt, nftables or members is never going to go down well.

[helloyello]

I am the original poster and I was replying to psherman open question to a different topic, again out of respect. Please look in the dictionary after what respect means. Then I took the decision to close the discussion, because the original question was already answered.

Please do contain your emotions as you're blatantly and falsely accusing me of exactly why you're doing - hurling personal insults.

[psherman]

This thread is now veering way off topic so it will be closed.

I would like to remind everyone about the community guidelines -- please keep it civil, keep it on topic, and keep the conversation moving forward. There are many posts here that do not adhere to our guidelines and I would urge the authors of said posts to consider editing the content to keep them on point. Thank you.