Bug 187241
| Summary: | VLAN support in ATH10k | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Bruno (baantunes) |
| Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.4.14 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | Iperf3 testing | ||
It turn out that the poor performance was related to a faulty switch port. So I can confirm that the firmware compiled with disabled vlan-tx-strip works fine. Comment on beta release of candelatech firmware: "Disable vlan-tx-strip flag. It is not configurable currently, and was hard-coded to true. This broke sending 802.1q vlan packets it seems. Set this flag to zero to fix vlans." Using the same scenario as above client1 --- SW1 ---- AP ...... Sta ---- SW2 --- client2 The AP is an APU with dual core and the Sta is an APU2 with quad core TCP throughput using Vlan 4. Testing with 2 different firmwares: firmware-5.bin_10.2.4.70.58 (from git repo without security and rawmode=1) firmware-2.bin_10.1.467-ct-_fW-018-8881bce (from Candelatech with security) client1 --> client2 307,33 Mbps firmware-5.bin_10.2.4.70.58 308,33 Mbps firmware-2.bin_10.1.467-ct-_fW-018-8881bce client1 <-- client2 436,77 Mbps firmware-5.bin_10.2.4.70.58 420,33 Mbps firmware-2.bin_10.1.467-ct-_fW-018-8881bce |
Created attachment 243851 [details] Iperf3 testing Running a setup with VLAN, WDS and ath10k cards. The main ideia is to create a wireless bridge. The setup is this: client1 --- SW1 ---- AP ...... Sta ---- SW2 --- client2 Currently to make it work both cards must be loaded in rawmode, AP and Sta, and with no security. I'm using a OpenWrt trunk r4994, with kernel 4.4.14, and the most recent firmware, 10.2.4.70.58, from Kalle ath10k firmware tree. Although it works the throughput is very bad. All devices receive IP address in the respective vlan. All devices can ping the others while loosing an occasioanal ping. One user reported that modifying the 1q header to other value (0xaa00) before go into firmware, the packet can be captured in the air. According to other user, with access to firmware source code, the bug appears that vlan-tx-stripping is unconditionally enabled. At least in versions based on 10.1.467. Re-compiling it with out that flag set would solve the issue. Testing with out this flag set allows to connect the AP and Sta with security enabled and the driver does not need to be loaded in rawmode.