Currently, the padding position is based on
ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
padding on RX (and expect the same padding to be present on TX) at the
following position :
- management : 24 + 6 if 4-addr format
- control: 24 + 6 if 4-addr format
- data
Bob Copeland a écrit :
> On Sat, Feb 27, 2010 at 01:58:38PM +0100, Benoit Papillault wrote:
>
>> Currently, the padding position is based on
>> ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
>> padding on RX (and expect the same padding to be present on TX) at the
>> foll
On Sat, Feb 27, 2010 at 01:58:38PM +0100, Benoit Papillault wrote:
> Currently, the padding position is based on
> ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
> padding on RX (and expect the same padding to be present on TX) at the
> following position :
>
> - management
Currently, the padding position is based on
ieee80211_get_hdrlen_from_skb(). This is not correct since the HW does
padding on RX (and expect the same padding to be present on TX) at the
following position :
- management : 24 + 6 if 4-addr format
- control: 24 + 6 if 4-addr format
- data
On Tue, Feb 16, 2010 at 09:39:25PM +0100, Benoit PAPILLAULT wrote:
> I don't have an ath5k based card at hand. I will try to grab one and
> will give an example of said frame. Basically, I followed the same
> strategy for ath9k already.
Are you saying that this patch has not actually been tested a
Jouni Malinen a écrit :
> On Tue, Feb 16, 2010 at 09:39:25PM +0100, Benoit PAPILLAULT wrote:
>
>> I don't have an ath5k based card at hand. I will try to grab one and
>> will give an example of said frame. Basically, I followed the same
>> strategy for ath9k already.
>>
>
> Are you saying t
Bob Copeland a écrit :
> On Mon, Feb 15, 2010 at 11:06:29PM +0100, Benoit PAPILLAULT wrote:
>
>>> Can you tell what the functional difference is between the old code and new
>>> code? E.g. a padding that would be incorrectly computed from before?
>>>
>>>
>>>
>> Correct. On some frames
On Mon, Feb 15, 2010 at 11:06:29PM +0100, Benoit PAPILLAULT wrote:
>> Can you tell what the functional difference is between the old code and new
>> code? E.g. a padding that would be incorrectly computed from before?
>>
>>
> Correct. On some frames padding is incorrect. This patch is more for
Bob Copeland a écrit :
> On Sun, Feb 14, 2010 at 6:36 PM, Benoit Papillault
> wrote:
>
>> Instead of computing the padding size based on the IEEE 802.11 header length,
>> we directly compute the padding position first and then the padding size
>> next.
>> We have changed some functions to pass
On Sun, Feb 14, 2010 at 6:36 PM, Benoit Papillault
wrote:
> Instead of computing the padding size based on the IEEE 802.11 header length,
> we directly compute the padding position first and then the padding size next.
> We have changed some functions to pass them the padding size directly. It has
Instead of computing the padding size based on the IEEE 802.11 header length,
we directly compute the padding position first and then the padding size next.
We have changed some functions to pass them the padding size directly. It has
been tested using a monitor interface in TX and RX against a dif
11 matches
Mail list logo
