Bug 187241 - VLAN support in ATH10k
Summary: VLAN support in ATH10k
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-07 18:34 UTC by Bruno
Modified: 2016-11-16 16:15 UTC (History)
0 users

See Also:
Kernel Version: 4.4.14
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Iperf3 testing (1.16 KB, text/plain)
2016-11-07 18:34 UTC, Bruno
Details

Description Bruno 2016-11-07 18:34:37 UTC
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.
Comment 1 Bruno 2016-11-16 16:15:11 UTC
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

Note You need to log in before you can comment on or make changes to this bug.