Thank you very much for your answer and advice. I think the WLAN is ingenious and I will try it out with “hostapd” to see if it works. But I have seen /read that I should /must enter a so-called “device” there. what is this device called under your image?
AND!
What do I have to install for the external 5 GHz module? I have not yet fully understood / been able to comprehend this.
I have a quick question regarding your Bulleyes image. What is the best way for the WLAN0 configuration? Via /etc/systemd/network or rather via /etc/network/interfaces.d/ ?
For hostapd and any other configs (wpa supplicant,iw,…) you need an interface (shown in “ip a”), not device (in /dev)
/etc/network/interfaces (and interfaces.d directory) need ifupdown installed and it is the legacy way. my image has systemd-networkd activated and you should not mix these configuration-daemons. if you install/enable ifupdown you have to configure all in this and disable systemd-networkd
with both you configure interface-state and ip-configuation
hostapd needs to be configured separately
for systemd you can look into my existing configfiles in /etc/systemd/network (link-files sind for link layer, e.g. interface-state and vlan-creation, network-files are for protocol configuration like ip-adress/dhcp)
for hostapd you’ll find examples in my wiki (and maybe i have added configfile to image…do not remember).
basicly you need to set interface up with ip-adress, an dhcp-server (e.g. dnsmasq or systemd-dhcp) and hostapd running for Wifi-AP itself
I’m still having a bit of trouble with the bullseye image and I hope you can help me:
Yesterday I had the interface WLAN0 under “ifconfig -a” and after a restart (cold start) of the system it is no longer present. What could be the reason for this?
I would like to activate the external WLAN interface, but unfortunately I don’t know exactly how to do this. Could you possibly help me here?
Frank, I read that you do not attach wlan0 to the bridge. I guess under most circumstances this will be ok, but I think it will break 802.11r fast transition, at least with ft_over_ds enabled. Anyway if someone chooses to implement it.
Both access points setup with the same SSID and mobility domain Nas identifier needs to be different on each access point.
You need layer 2 connected access points for ft_over_ds to work. It might however work without layer 2 wihen ft over air, since ft_psk is also generated locally.
I’ve seen some ft activity in the debug logs, so it looks like it works on internal mt7622. I’m working on a tool to make ft and other inter-ap options more accessible, without the need of openwrt or dbus. I still need to add a possibility to show the debug logs concerning FT, as these messages are normally not shown (log level).
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 IEEE 802.11: binding station to interface 'wlan0'
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 IEEE 802.11: authentication OK (FT)
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 MLME: MLME-AUTHENTICATE.indication(34:de:1a:bc:55:25, FT)
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 IEEE 802.11: association OK (aid 2)
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 IEEE 802.11: associated (aid 2)
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 MLME: MLME-REASSOCIATE.indication(34:de:1a:bc:55:25)
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 IEEE 802.11: binding station to interface 'wlan0'
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 WPA: event 6 notification
Dec 17 16:35:04 bpir64 hostapd[1311]: wlan0: STA 34:de:1a:bc:55:25 WPA: FT authentication already completed - do not start 4-way handshake
So it is working ok on mt7622 internal wifi.
Anyway, not even noticing when my phone roams.Only change in signal strength, but wifi seems uninterrupted
Sadly I do not receive these as events on the ctrl_iface, so I can not make them visible in my tool…
Come to think if it, I think you need layer 2 network also for ft over air. The client needs to contact the central DHCP server from any access point. It continues to use the same DHCP lease after roaming.