Hi,
On 25 October 2016 at 22:56, Johannes Berg wrote:
>
>> The intel 7260 and later parts also allow user controllable rate
>> control and provide transmit completion feedback, but I don't know
>> whether it's enough for your needs.
>
> Perhaps. However, existing rate control is *very* tightly co
The bug appears that vlan-tx-stripping is unconditionally enabled in
at least my firmware. I have re-compiled w/out that flag set, and it appears
to work for me.
Please download this firmware, rename it firmware-2.bin, make sure you
remove/rename
any firmware-5.bin (etc) so mine will load, and
I can reproduce this in my CT firmware. I'll see if I can fix it,
but for stock firmware, it might be that changing the driver to use Ethernet
packet type
of native-wifi would make .1q vlans work.
Thanks,
Ben
On 11/04/2016 10:28 AM, yu-chieh kung wrote:
I met the same problem before,
if i mod
Bruno Antunes writes:
> Old thread but I think the issue is still present.
>
> I'm running a setup with VLANs with WDS and ath10k cards.
>
> To make it work both cards must be loaded in rawmode, AP
> and Sta, and with no security.
>
> I'm using a OpenWrt trunk r49941 and the most recent firmware,
I met the same problem before,
if i modify the 1q header to other value (0xaa00) before go into firmware.
I can capture the packet in the air
I think the vlan packet is dropped in firmware.
2016-11-04 22:41 GMT+08:00 Bruno Antunes :
> On 4 November 2016 at 14:18, Mauro Mozzarelli wrote:
>> Since
On 4 November 2016 at 14:18, Mauro Mozzarelli wrote:
> Since the capability is implemented in software you might be testing the
> limit of your router's CPU i/o speed.
By loading the module in rawmode?
The AP is an APU and Sta is an APU2.
>
>
>
> On 04/11/16 14:13, Bruno Antunes wrote:
>>
>> Hi
Hi all,
Old thread but I think the issue is still present.
I'm running a setup with VLANs with WDS and ath10k cards.
To make it work both cards must be loaded in rawmode, AP
and Sta, and with no security.
I'm using a OpenWrt trunk r49941 and the most recent firmware,
10.2.4.70.58, from Kalle at
Joe Perches writes:
> On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
>> Code is 80 characters wide, and comments are /* */ never the ugly C++
>> crap.
>
> You might look at the recent Linus Torvalds authored commit
> 5e467652ffef (?printk: re-organize log_output() to be more legible")
> wh
Felix Fietkau writes:
> A-MSDU aggregation alters the QoS header after a frame has been
> enqueued, so it needs to be ready before enqueue and not overwritten
> again afterwards
Acked-by: Toke Høiland-Jørgensen
Felix Fietkau writes:
> The call to ieee80211_txq_enqueue overwrites the vif pointer with the
> codel enqueue time, so setting it just before that call makes no
> sense.
Yeah, I think this was leftover from earlier version when the flow was
different. Or maybe I just missed it...
Acked-by: Toke
Felix Fietkau writes:
> The sequence number counter is used to derive the starting sequence
> number. Since that counter is updated on tx dequeue, the A-MPDU flag
> needs to be up to date at the tme of dequeue as well.
>
> This patch prevents sending more A-MPDU frames after the session has
> bee
The sequence number counter is used to derive the starting sequence
number. Since that counter is updated on tx dequeue, the A-MPDU flag
needs to be up to date at the tme of dequeue as well.
This patch prevents sending more A-MPDU frames after the session has
been terminated and also ensures that
A-MSDU aggregation alters the QoS header after a frame has been
enqueued, so it needs to be ready before enqueue and not overwritten
again afterwards
Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ
dequeue")
Signed-off-by: Felix Fietkau
---
net/mac80211/tx.c | 6
The call to ieee80211_txq_enqueue overwrites the vif pointer with the
codel enqueue time, so setting it just before that call makes no sense.
Signed-off-by: Felix Fietkau
---
net/mac80211/tx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c380e
From: Mohammed Shafi Shajakhan
This fixes the below crash when ath10k probe firmware fails,
NAPI polling tries to access a rx ring resource which was never
allocated, fix this by disabling NAPI right away once the probe
firmware fails
BUG: unable to handle kernel NULL pointer dereference at (nul
15 matches
Mail list logo
