AR5416 beacon issue.

[Kang Yin Su]

On Tue, Aug 23, 2011 at 9:23 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> Hi!
>
> 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?
>
>
Can you just verify that both the TDMA and non-TDMA beacon send code
> in ath(4) actually generates a new beacon each time, and thus will
> -get- an updated sequence number?
>
> Both the TDMA and non-TDMA  call ath_beacon_generate() before TX beacon.
See below:

I'm worried that the current ath(4) beacon code only fires off a new
> beacon to the hardware if the beacon contents needed changing, and
> just re-uses the same frame over and over, expecting the hardware to
> bump the sequence number.
>
> Disabled REG_PRESERVE_SEQNUM. Hardware bump the beacon sequence number
without the software sequence number fix in net80211 layer.
Enable REG_PRESERVE_SEQNUM (thats in ar5416 hal currently), you need my
sequence number fix in net80211. That's what I tested and mentioned
yesterday.  So the hardware sequence should work.

Would you mind checking for me? :)
>
> Thanks,
>
>
> Adrian

Please let me know if that is what you concern and anything want to test.

Thanks,
Yin