search

BPI-SINOVOIP / THG6500-TAX2-OPENWRT-BSP

Other
27 stars 8 forks source link

WDS mode and Monitor mode do not work/ are not supported #2

Open phpaiva opened 5 months ago

phpaiva commented 5 months ago

I am trying to put to work a radio with a Multi-AP STA interface (EasyMesh link), the connectivity at Layer 1/2 seems to work well but at least IP traffic is not being forwarded to/from the Multi-AP WDS link. The UCI configuration is:

wireless.bh_sta=wifi-iface
wireless.bh_sta.device='radio1'
wireless.bh_sta.mode='sta'
wireless.bh_sta.network='lan'
wireless.bh_sta.ssid='SMBackhaulSSID_54:af:97:c5:c0:8d'
wireless.bh_sta.key='tFKUEAtQ4zwV3uk6'
wireless.bh_sta.macaddr='2c:11:52:4f:41:04'
wireless.bh_sta.encryption='psk2+ccmp'
wireless.bh_sta.multi_ap='1'
wireless.bh_sta.wps_pushbutton='1'
wireless.bh_sta.ifname='sta0'

The MAC address should be overrided because the default value was "00:00:00:00:00:00" and that leads to a failure. As I said, with wpa_cli all seems to work well and also the bridge shows the interface:

<3>Trying to associate with 60:a4:b7:7c:6c:8f (SSID='SMBackhaulSSID_54:af:97:c5:c0:8d' freq=5260 MHz)
<3>Associated with 60:a4:b7:7c:6c:8f
<3>CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
<3>WPA: Key negotiation completed with 60:a4:b7:7c:6c:8f [PTK=CCMP GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 60:a4:b7:7c:6c:8f completed [id=0 id_str=]

root@OpenWrt:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.d4772b555557       no              lan1
                                                        lan2
                                                        lan3
                                                        p-1905
                                                        sta0
                                                        wan

In LUCI:

image

But a ping to the IP of the device working as a WDS AP fails (and also, any kind of traffic expected to go through that link):

root@OpenWrt:~# ping -I sta0 192.168.0.44
PING 192.168.0.44 (192.168.0.44): 56 data bytes
^C
--- 192.168.0.44 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

With a tcpdump in the client interface (sta0) and br-lan, we can see ARP requests from the device which runs the Multi-AP WDS AP (192.168.0.44), but no response:

root@OpenWrt:~# tcpdump -vvv -i sta0 | grep 192.168.0.44
tcpdump: listening on sta0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:19:36.413026 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:37.452643 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:38.492548 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:39.533129 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:40.573055 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:41.613377 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:42.653261 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:43.692417 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:44.732137 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:47.904990 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:48.972169 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:50.013555 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:51.862394 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:52.892419 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:53.932962 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:19:56.222445 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
^C264 packets captured
266 packets received by filter
0 packets dropped by kernel
root@OpenWrt:~# ^C
root@OpenWrt:~# tcpdump -vvv -i br-lan | grep 192.168.0.44
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
09:20:02.492561 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:03.532611 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:04.579466 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:05.612608 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:06.651959 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:07.692552 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:08.732910 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:09.773520 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:10.812390 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:11.852520 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:12.892041 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
09:20:13.932065 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.44, length 28
^C216 packets captured
229 packets received by filter
0 packets dropped by kernel

This shows that the inbound traffic is being received but the system is unable to forward it properly. Also the outbound traffic won't go out for the same reason, the system can't forward properly to the WDS link to send it out.

Regarding the monitor mode, simply there is no capability using an iw list command. There is only "managed" and "AP" modes.

Wiphy phy0
        wiphy index: 0
        max # scan SSIDs: 8
        max scan IEs length: 1000 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * managed
                 * AP

And also by creating one interface in monitor mode does not work.

Am I doing something wrong? There will be support for MultiAP links? And what about monitor mode?

Thanks in advance.

Pablo.

phpaiva commented 5 months ago

I can confirm that The Multi-AP mode from the AP role is also not being supported.

OpenWRT supports this by the hostapd/wpa_supplicant for the handshake process (a little addition to the association process), the details are below:

https://github.com/vanhoefm/dragonslayer/blob/master/hostapd/README-MULTI-AP

This part seems to be working, but after the handshake the association is being made as a regular connection (3 addresses), so the WDS bridging capability does not work.

The achieve the 4 mac address connection (WDS) to work, OpenWRT relies in the softmac driver "mac80211" and its capability known as "4addr" which is in charge to forward properly the 4-MAC address frames, as the 802.11 specification says.

Since I see that mac80211 module in not running in this device, the support of 4addr should be added to the triductor driver or the driver should start to work with mac80211 in the canonical SoftMAC architecture defined by Linux.

I tried to compile a firmware including mac80211 but it fails, it triggers a lot of errors of kernel versions of diferent components.

If there is no change in this source code, the WiFi capability is really limited, just to use as a regular AP and a regular STA. No multi-ap/wds, no ad-hoc, no mesh (802.11s), etc...