Access Point with VLANs on Raspberry Pi

Hi,

I have an old air conditioner with a WiFi module that only supports WPS. For a long time I used a repurposed BT (British Telecom) Home Hub (Router), but this died. I've looked for several alternative solutions including buying 3 different APs with WPS. I was able to get my RPi to connect to the air conditioner, so I know it should work, but I was unable to configure Raspbian with VLANs and dumb AP, so I've installed OpenWrt...

I have a fairly mature home network and I'm trying to configure a Raspberry Pi as a "dumb" access point where I can access the RPi on VLAN10 for configuration/management and the wireless talks on VLAN35 - which is an untrusted IOT network segment.

I've put together a quick diagram of the relevant components:

The switch port/interface from the switch to RPi is configured as a trunk with VLAN10 & VLAN 35 tagged.

Current status:

  1. I can connect to the RPi (172.16.10.9) from a device on 172.16.50.0/24, so I assume the VLANs are correctly configured.
  2. See the SSID from my phone. AP is up.
  3. Connect to the SSID - if I remove security and set it to Open. Upstream DHCP/ routing is working.

Issues:

What I cannot do is connect to the AP with security configured (WPA2-PSK). From Android, I get Incorrect password. From working with other APs, this is normally a sign of something misconfigured on the network side.

I don't know if this is a red herring, but on the console, I see:
br-lan: received packet on phy0-ap0 with own address as source address (addr:ba:27:ee:2d:aa:1d, vlan:35) repeated every ~5 minutes. I have tried to assign local MAC addresses to the devices, but the message persists.

I've spent about 3 weeks on this, and consumed lots of forum posts and videos. I've got closer with OpenWrt, but I'm still not quite there.

I've been using LuCI for config. This is my first post, so I hope I'm including the required config files/logs:

logread

Whilst trying to connect from Android device.
logger_stdout_level=1

Wed Nov  1 14:33:21 2023 daemon.info hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c IEEE 802.11: associated
Wed Nov  1 14:33:21 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: event 1 notification
Wed Nov  1 14:33:21 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: start authentication
Wed Nov  1 14:33:21 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c IEEE 802.1X: unauthorizing port
Wed Nov  1 14:33:21 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: sending 1/4 msg of 4-Way Handshake
Wed Nov  1 14:33:22 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: EAPOL-Key timeout
Wed Nov  1 14:33:22 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: sending 1/4 msg of 4-Way Handshake
Wed Nov  1 14:33:23 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: EAPOL-Key timeout
Wed Nov  1 14:33:23 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: sending 1/4 msg of 4-Way Handshake
Wed Nov  1 14:33:24 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: EAPOL-Key timeout
Wed Nov  1 14:33:24 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: sending 1/4 msg of 4-Way Handshake
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: EAPOL-Key timeout
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: PTKSTART: Retry limit 4 reached
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: event 3 notification
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c IEEE 802.1X: unauthorizing port
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c MLME: MLME-DEAUTHENTICATE.indication(00:1d:a1:ee:9e:1c, 15)
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c MLME: MLME-DELETEKEYS.request(00:1d:a1:ee:9e:1c)
Wed Nov  1 14:33:25 2023 daemon.info hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c IEEE 802.11: disassociated
Wed Nov  1 14:33:25 2023 daemon.debug hostapd: phy0-ap0: STA 00:1d:a1:ee:9e:1c WPA: event 2 notification

/etc/openwrt_release

r23497-6637af95aa
root@wwap03:/etc# cat openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='23.05.0'
DISTRIB_REVISION='r23497-6637af95aa'
DISTRIB_TARGET='bcm27xx/bcm2710'
DISTRIB_ARCH='aarch64_cortex-a53'
DISTRIB_DESCRIPTION='OpenWrt 23.05.0 r23497-6637af95aa'
DISTRIB_TAINTS=''

/etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd46:1a8f:41e7::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'
        option ipv6 '0'

config interface 'lan'
        option device 'br-lan.10'
        option proto 'static'
        option ipaddr '172.16.10.9'
        option netmask '255.255.255.240'
        option gateway '172.16.10.1'
        option ip6assign '60'
        list dns '172.16.60.5'
        option broadcast '172.16.10.15'

config bridge-vlan
        option device 'br-lan'
        option vlan '10'
        list ports 'eth0:t*'

config bridge-vlan
        option device 'br-lan'
        option vlan '35'
        list ports 'eth0:t'

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

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

config interface 'HA_WLAN'
        option proto 'none'
        option device 'br-lan.35'

config device
        option name 'phy0-ap0'
        option ipv6 '0'

/etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/soc/3f300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
        option channel '7'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
        option country 'GB'
        option log_level '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'HA_WLAN'
        option mode 'ap'
        option ssid 'BTVHA'
        option encryption 'psk2'
        option key 'passw0rd'
        option wmm '0'

The following services are disabled:

  • dnsmasq
  • firewall
  • odhcpd

LuCI screenshots:

Sorry. Not allowed to post screenshots. Grrrr.

Sorry for the long post, but I wanted to include information that I thought would be relevant.

If anyone could point me in the right direction, I'd be most grateful. I am a newbie to OpenWrt, so please assume I know nothing.

Thanks

W.

Delete all of the following:

Next, edit your lan to use eth0.10 like this:

config interface 'lan'
        option device 'eth0.10'
        option proto 'static'
        option ipaddr '172.16.10.9'
        option netmask '255.255.255.240'
        option gateway '172.16.10.1'
        option ip6assign '60'
        list dns '172.16.60.5'
        option broadcast '172.16.10.15'

Create a bridge for the ha_wlan network like this:

config device
        option name 'br-hawlan'
        option type 'bridge'
        list ports 'eth0.35'

And edit your ha_wlan network to use the new bridge:

config interface 'HA_WLAN'
        option proto 'none'
        option device 'br-hawlan'

Restart and give it a shot.

The recommended approach is to leave these enabled. The most important one is dnsmasq which will become re-enabled upon upgrading to a new version of OpenWrt (at some point in the future). The key here is to disable the lan DHCP server explicitly (using the ignore option)... this will prevent it from ever suprirsing you with a rogue DHCP server on your lan.

1 Like

Thank you so very much @psherman. All working now.

Do I need to do anything with the Bridge VLAN filtering on br-hawlan?

On to WPS config :slight_smile:

Once you have the IoT configured by WPS to connect to one AP, it should move to another AP with the same SSID and PSK without needing WPS active on the new AP. Especially if you clone the BSSID of the AP into the new one.

2 Likes

Nope. Bridge-VLAN filtering is not required in this situation.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.