AR5416 beacon issue.

[Adrian Chadd]

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
>