[BPI-R4] Encryption not working when VLAN enabled in SDK35 and SDK40 (OpenWrt)

Autom8 · September 6, 2024, 1:30pm

Hi, I’m running OpenWrt since many years on different devices. (tp-link, totolink, d-link) I configure separate SSIDs for Home-, Guest- and IOT-usage and assigned them to different VLANS. Everything works fine with the “mtk-bpi-r4-MT76-SD-20240202.img” provided in the “OpenWRT MTK MP3.1 wifi SDK or MT76 wifi driver for BE14000 Wifi Card”. (https://wiki.banana-pi.org/Banana_Pi_BPI-R4#Release_image)

BUT: it is not working neither with “OpenWRT MTK MP3.1 wifi SDK” nor with “OpenWRT MTK MP4.0 wifi SDK wifi driver for BE14000 Wifi Card”

As soon as I enable VLAN-Filtering on the “br-lan” Bridge, Authentication with the WiFi is not possible anymore. When I try to connect with an iPhone for example, it shows: “Invalid password for AP_MTK_MT7990_2G_2” Neither password I’m entering is accepted anymore. No link possible. This is true for all types of encryption. Tested wpa2, psk2ccmp, sae…

Here is what I can do to reproduce. (based on SDK40-sd-image)

Flashed new sd image (mtk-bpi-r4-SD-20240620.img) on empty SD card
Tested unencrypted connection to “AP_MTK_MT7990_2G_2” : works
changed to encrypted

 
#/etc/config/wireless
config wifi-iface 'ra1'
        option device 'MT7990_1_1'
        option network 'lan'
        option mode 'ap'
        option disabled '0'
        option ssid 'AP_MTK_MT7990_2G_2'
        option encryption 'none'
		...
# -->> 
        option encryption 'sae'
		option key '12345678'	(example)
		...

Test: connection works with encryption

added VLAN added VLAN-Filtering to br-lan bridge, assigned lan-Interface to

	
#/etc/config/network
# <-- old
config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'eth1'
	
config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

# --> new
config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'eth1'
	
config interface 'lan'
	option device 'br-lan.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	
config bridge-vlan
	option device 'br-lan'
	option vlan '1'
	list ports 'lan1:t'
	list ports 'lan3:u*'

--- optional: (implicitely created)

config device
        option name 'br-lan.1'
        option type '8021q'
        option ifname 'br-lan'
        option vid '1'
        option ipv6 '0'

Afterwards VLAN is working (can use tagged frames on LAN1 and untagged on LAN3 for example), but authentication is not working anymore.

When I switch off encryption (option encryption ‘none’) - wifi-connection is established. But I’d like to avoid unencrypted communication

Any ideas? It seems to be a bug in MTK-Driver, since same setting for encryption and VLAN is working with mt76-Driver on same old OpenWrt (OpenWrt 21.02-SNAPSHOT) provided by MTK in their download.

Autom8 · September 6, 2024, 1:39pm

@Betonmischer : Thanks for providing your settings. As you can see above - in my case it was the VLAN config which prevents my encryption / authentication.

ericwoud · September 6, 2024, 2:03pm

I also want to do some more experiments with vlan and stumbled upon:

rsn_preauth_interfaces

Setting in hostapd.conf.

Normally hostapd will use br-lan master interface to send rsn_preauth, but it has to use br-lan.1 now. I hope this setting will change all required packets to the correct interface to do authentication. But I have yet still to try this…

So in your case:

rsn_preauth_interfaces=br-lan.1

Autom8 · September 6, 2024, 3:04pm

Hi Eric, rsn_preauth is used for roaming purposes. I.e. if you have more than one AP and want to “Fast Transition” from one AP to the next AP there are two methods like “FT over Air” and “FT over DS”. FT over DS means, that the APs communicate with each other before in a direct way or with the help of a controller. https://wireless.wiki.kernel.org/en/users/documentation/hostapd#ieee_80211irsnwpa2_pre-authentication For this it might be relevant to select the bridge for sending these management frames.

But this has nothing todo with my case. But thanks for the idea.

P.S.: as I said: same setting works on the mt76 driver included in the 3.5SDK

P.P.S: I didn’t wanted to confuse here all, but I even tried to connect to my radius-server before. (I have one for testing purposes and it works well for other APs). But the authentication frames from the Banana-Pi have not even been reached by that server. (they were not send)

ericwoud · September 6, 2024, 8:05pm

I thought re-auth was seperate from FT, but details anyway.

Come to think of it, I do have that setup (in linux distro, not openwrt) on R3 and that works ok. I will need to do that extra interface setting for roaming indeed.

Do you have hardware offloading enabled? It may give trouble when combining vlan-devices and vlan-aware bridges, I recently found out. But it is probably to early in the connection for flowtables to cause trouble (it only does IP/IP6)

Autom8 · September 7, 2024, 9:26am

I guess you mean the hardware offloading in the firewall config. No, it’s not enabled. But this should also not be relevant in “wifi-encryption” and authentication handshakes. Because: Firewall, NAT etc. are working on OSI Layer 3. Hostapd instead is working on Layer 2 only. It’s pure bridging and direct communication on Logical Link sublayer. No routing involved, no firewall involved. (The only IP communication involved is probably when connecting to an external RADIUS.) So the issue is only popping up, when I bind a Wifi-Interface to a bridge with “option type ‘8021q’” instead of “option type ‘bridge’”.

ericwoud · September 7, 2024, 11:08am

What is the output of:

bridge vlan

And:

ip a

Autom8 · September 7, 2024, 8:45pm

root@OpenWrt:/# bridge vlan
port              vlan-id
eth2              1 PVID Egress Untagged
lan0              1 PVID Egress Untagged
lan1              1 PVID Egress Untagged
lan2              1 PVID Egress Untagged
lan3              1 PVID Egress Untagged
ra0               1 PVID Egress Untagged
rai0              1 PVID Egress Untagged
rax0              1 PVID Egress Untagged
apcli0            1 PVID Egress Untagged
br-wan            1 PVID Egress Untagged
apclii0           1 PVID Egress Untagged
apclix0           1 PVID Egress Untagged
br-lan            1

this seems to be correct because on a working OpenWrt (totolink XR5000 with OpenWrt 23.05.04) with more VLANs I get for example.

root@wrt-toto1:~# bridge vlan
port              vlan-id
lan1              101 PVID Egress Untagged
lan2              106 PVID Egress Untagged
lan3              1 PVID Egress Untagged
lan4              1
                  101
                  106
br-bbone          1
                  101
                  106
w5apps            101 PVID Egress Untagged
w5mesh            101 PVID Egress Untagged
w2apps            101 PVID Egress Untagged
w2guest           106 PVID Egress Untagged
w2iot             101 PVID Egress Untagged

PVID and Egress are not shown.

And here is the ip -a output. (I have replaced the middle bytes in the MACs with XX - the rest is unique) The IP is 192.168.1.3 That’s OK, that’s my setup when connected to my Network.

root@OpenWrt:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6e:XX:XX:XX:XX:68 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::XXXX:XXXX:XXXX:XX68/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000
    link/ether aa:XX:XX:XX:XX:c0 brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-wan state DOWN group default qlen 1000
    link/ether ae:XX:XX:XX:XX:ab brd ff:ff:ff:ff:ff:ff
5: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-wan state LOWERLAYERDOWN group default qlen 1000
    link/ether 6e:XX:XX:XX:XX:68 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
    link/ether 6e:XX:XX:XX:XX:68 brd ff:ff:ff:ff:ff:ff
7: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN group default qlen 1000
    link/ether 6e:XX:XX:XX:XX:68 brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 6e:XX:XX:XX:XX:68 brd ff:ff:ff:ff:ff:ff
9: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
    link/tunnel6 :: brd ::
10: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
11: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: ip6gre0@NONE: <NOARP> mtu 1448 qdisc noop state DOWN group default qlen 1000
    link/gre6 :: brd ::
14: ra0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether 00:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
15: rai0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether 00:XX:XX:XX:XX:f0 brd ff:ff:ff:ff:ff:ff
16: rax0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether 00:XX:XX:XX:XX:e0 brd ff:ff:ff:ff:ff:ff
17: apcli0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master br-lan state DOWN group default qlen 1000
    link/ether 06:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
20: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 6e:XX:XX:XX:XX:68 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::XXXX:XXXX:XXXX:XX68/64 scope link
       valid_lft forever preferred_lft forever
21: apclii0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master br-lan state DOWN group default qlen 1000
    link/ether 06:XX:XX:XX:XX:f0 brd ff:ff:ff:ff:ff:ff
22: apclix0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master br-lan state DOWN group default qlen 1000
    link/ether 06:XX:XX:XX:XX:e0 brd ff:ff:ff:ff:ff:ff
23: br-lan: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
24: br-lan.1@br-lan: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global br-lan.1
       valid_lft forever preferred_lft forever

I’m curious, how this information is relevant. Because: when I switch off negotiation, connect is working fine and data flows even over the vlan-bridge. (tagged / untagged…)

ericwoud · September 8, 2024, 5:42am

Do you kniw which interface is your wifi ap? Not all (to me unknown interface names) have master bridge. But for the others, that does seem ok setup.

Also check that that interface has unique mac (not same as br-lan or any other)

Autom8 · September 8, 2024, 4:23pm

Hi Eric, thank you very much for your engagement trying to help me. But I don’t think, that fiddling with the bridges will help here further. Let me quickly explain why: Attached you can see a typical setup I have with other OpenWrt-based Accesspoints like

TP-Link WRT4300 (this is special for VLAN-tagging, since it has a Hardware-Switch)
TotoLink X5000R
D-Link DIR882

with all of them I had the following, similar setup (beside of the mesh)

As you can see, I use several “wifi-iface” to provide up to 8 SSIDs per AP. (there are some limitations of the Hardware). That means, I share “MY_APP” on 2,4 GHz and on 5 GHz. I can even use different encryption, passwords etc. in parallel for the same network. These multiple “wifi-iface” are connected to a “network”-Interface, and these network interface(s) are connected to VLAN-bridges. The network interfaces even don’t have an IP ! They are pure Bridging interfaces. At the end, all traffic from the WiFis passes through 1 single LAN-Port. Each Packet is tagged and passed via tagged ethernet to other systems. This is called Dumb AP Setup. For the requires services like Firewall, DHCP, DNS, Intrusion detection etc. I use a virtual pfSense instance, which is also connected via tagged VLAN.

Regarding hostapd I found the following schematic diagram (old!) on the site of the maintainer. https://w1.fi/hostapd/devel/index.html and I see the folliwong explanation
https://wireless.wiki.kernel.org/en/users/documentation/hostapd It says

In the old days, receiving and sending management frames required a monitor mode interface. You needed one interface running in master mode for standard traffic and another one for authentication, keys management, etc. The second one didn’t require any specific API; it was accessed using a standard Linux socket. This method is still supported by nl80211 driver as a fallback.

Later, nl80211 implemented special commands for sending management frames (NL80211_CMD_FRAME) and subscribing to them (NL80211_CMD_REGISTER_FRAME). This allowed user space to handle wireless infrastructure using a single interface only. This is currently the preferred method that can be used with all mac80211 drivers implementing AP mode.

Based on my experiences: TP-Link, OpenWrt 18.06.1 - 23.05.4: Driver type “mac80211”:

D-Link, OpenWrt 21.02.1 - 23.05.4: Driver type “mac80211”:

Totolink: OpenWrt 21.02.1 - 23.05.4: Driver type “mac80211”:

BananaPi R4 with wifi7 board: OpenWrt 21.02.1 Driver type “mac80211”: (as provided “BPI-R4-BE1350-WIFI_MT76-20240202.zip”)

BananaPi R4 with wifi7 board: OpenWrt 21.02.1 Driver type “mtkwifi”:

That’s why I think, the MTK provided driver is not correctly implementing the interfaces. … at least not in the case that hostapd is utilizing VLAN-bridges. might be there is an option I can set in the “wifi-device” section of the MTK drivers… or maybe there is a fix… so if anybody has established a VLAN-connection, please provide your experiences.

ericwoud · September 8, 2024, 7:13pm

I do the same one the R64 (R3 soon) on archlinux with systemd-networkd / hostapd setup.