svn commit: r257133 - head/sys/dev/iwn

[Adrian Chadd]

Hi!

Yup! So, the difference is in the rate being selected.

It looks like the remote end is just plainly not ACKing the 11n
management frame being sent; but it totally ACKs the 11b CCK frame
being sent.

So, thanks for pointing that out. I'll go and err, "fix" this mistake.
The driver should be doing what the stack says. Bernhard figured out a
couple years ago that doing 11n management frames to 11n devices is
not guaranteed to work, so we "fixed" that. I will go and figure out
why this is now broken for iwn.

Thanks!

Would you mind filing a PR with what we've gathered?



-adrian



On 28 October 2013 12:27, Stefan Farfeleder <stefanf at freebsd.org> wrote:
> On Mon, Oct 28, 2013 at 12:07:17PM -0700, Adrian Chadd wrote:
>> Yeah:
>>
>> Oct 28 19:43:43 mole kernel: iwn5000_tx_done: qid 3 idx 4 retries 7
>> nkill 0 rate a902 duration 686 status 83
>>
>> status 0x83 is LONG_LIMIT, which meant it tried to transmit and it
>> failed to get an ACK each time.
>>
>> The rate control says:
>>
>> 0x02: the rate in question
>> bit 8: MCS
>> bit 11: HT40
>> bits 14+15: transmit antennas A+B
>>
>> .. and it's an association/management frame, which is odd as they're
>> not supposed to be sent as 11n HT40 frames like this.
>>
>> can you do the same experiment but with the patch reverted? I'd like
>> to see what the selected rate is.
>
> Ok, here's the output with r257155 and r257133 reverted:
>
> http://pastebin.com/CJzsTANv
>
> Stefan