Date: Tue, 23 Aug 2011 21:23:05 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Kang Yin Su <cantona@cantona.net> Cc: freebsd-wireless@freebsd.org Subject: Re: AR5416 beacon issue. Message-ID: <CAJ-Vmo=ZYMW6taa48se-OGBPv1%2BQNB3m5vm-Gnk3650-iEWsvw@mail.gmail.com> In-Reply-To: <CAHjFwoC%2BH91gXOE1V7sYtH3fQHNuSPK5=W=y_5_hQAYUYPa7Rw@mail.gmail.com> References: <CAHjFwoCVwRNyJ_jCgthWFvi%2Bh%2B7xy6-bt=hDrhimMVHS7--dtQ@mail.gmail.com> <CAHjFwoC%2BH91gXOE1V7sYtH3fQHNuSPK5=W=y_5_hQAYUYPa7Rw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! On 23 August 2011 17:37, Kang Yin Su <cantona@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? 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. Would you mind checking for me? :) Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=ZYMW6taa48se-OGBPv1%2BQNB3m5vm-Gnk3650-iEWsvw>