AR5416 beacon issue.

[Adrian Chadd]

I think we'll need some review/testing of that patch before we commit
it to -HEAD.
That, and I'd like to actually document what the drivers are supposed
to do with respect to hardware generated sequence numbers.

Bernhard?



Adrian

On 23 August 2011 19:40, Kang Yin Su <cantona at cantona.net> wrote:
> Please commit my fix, if everything is fine :)
>
> On Tue, Aug 23, 2011 at 7:27 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>>
>> Yes, generation of sequence numbers has to be done in software for 11n
>> aggregation to work correctly.
>>
>>
>> Adrian
>>
>> On 23 August 2011 19:24, Kang Yin Su <cantona at cantona.net> wrote:
>> > My AR9220 datasheet said that "Stops PCU from replacing the sequence
>> > number;
>> > _must_ be set to 1".
>> > There is the register in AR5212, but the datasheet did not say it must
>> > be
>> > set to 1.
>> > Maybe sequence number generated in software is a must for 11n?
>> > -Yin
>> > On Tue, Aug 23, 2011 at 7:12 PM, Adrian Chadd <adrian at freebsd.org>
>> > wrote:
>> >>
>> >> Oh, I just wanted to ensure that was the root cause!
>> >>
>> >> So the real question is: should the drivers assume for now that
>> >> sequence numbers should be generated in software?
>> >> Does all the hardware even support that?
>> >>
>> >>
>> >> Adrian
>> >>
>> >> On 23 August 2011 18:54, Kang Yin Su <cantona at cantona.net> wrote:
>> >> > Tried disable that, it works also. However the sequence number in
>> >> > packet
>> >> > is
>> >> > less controllable. There are some packets like QoS need to fill the
>> >> > sequence
>> >> > number from the TID sequence space.
>> >> >
>> >> > -Yin
>> >> > On Tue, Aug 23, 2011 at 6:29 PM, Adrian Chadd <adrian at freebsd.org>
>> >> > wrote:
>> >> >>
>> >> >> That's a great catch. So from memory:
>> >> >>
>> >> >> * there are bits that control whether the MAC generates sequence
>> >> >> numbers
>> >> >> or not;
>> >> >> * the frame type in the TX descriptor can also modify that.
>> >> >>
>> >> >> AR5416:
>> >> >>
>> >> >> * D_MISC for each DCU, bit 20: Sequence number increment disable;
>> >> >> resets
>> >> >> to 0x0.
>> >> >> * MAC_PCU_STA_ADDR_U16 - (0x8004) bit 29: REG_PRESERVE_SEQNUM: Stops
>> >> >> PCU from replacing the sequence number
>> >> >>
>> >> >> AR5212:
>> >> >>
>> >> >> * D_MISC: same deal: bit 20 - SEQNUMINCDIS
>> >> >> * same deal with MAC_PCU_STA_ADDR_U16 above: bit 29
>> >> >>
>> >> >> 30 seconds with the HAL has shown what's going on:
>> >> >>
>> >> >> ar5416Reset():
>> >> >>
>> >> >>        /*
>> >> >>         * disable seq number generation in hw
>> >> >>         */
>> >> >>         OS_REG_WRITE(ah, AR_STA_ID1,
>> >> >>             OS_REG_READ(ah, AR_STA_ID1) |
>> >> >> AR_STA_ID1_PRESERVE_SEQNUM);
>> >> >>
>> >> >> That bit isn't set for the AR5212.
>> >> >>
>> >> >> Try disabling that, see if it works on the AR5416.
>> >> >>
>> >> >> If it does, then we should (all) have a brief discussion what the
>> >> >> "correct" behaviour is moving forward.
>> >> >>
>> >> >>
>> >> >> Adrian
>> >> >>
>> >> >>
>> >> >> On 23 August 2011 17:37, Kang Yin Su <cantona at cantona.net> wrote:
>> >> >> > Hi all,
>> >> >> > OK, this patch fix the beacons sequence number from AR5416 chips.
>> >> >> > With
>> >> >> > this
>> >> >> > code added, both beacons send from AR5212 and AR5416 chips are
>> >> >> > fine,
>> >> >> > the
>> >> >> > sequence numbers are increase by 1. I have no idea why the AR5212
>> >> >> > chips
>> >> >> > do
>> >> >> > not this require this. The AR5212 hardware probably ignore this
>> >> >> > field
>> >> >> > and
>> >> >> > added the seq no. by itself?
>> >> >> > Thanks,
>> >> >> > Yin
>> >> >> > On Tue, Aug 23, 2011 at 3:50 PM, Kang Yin Su <cantona at cantona.net>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi All,
>> >> >> >> Using FreeBSD HEAD create a AP, found that the beacon frames have
>> >> >> >> no
>> >> >> >> sequence number on AR5416 WiFi card, however there is sequence
>> >> >> >> number
>> >> >> >> on
>> >> >> >> AR5212 WiFi card. Attached is the WiFi capture on both    card.
>> >> >> >>  00:1b:b1:59:ab:4d is AR5416 and 00:0b:6b:2d:f2:cc is AR5212.
>> >> >> >> Thanks,
>> >> >> >> Yin
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>