Date: Tue, 23 Aug 2011 19:24:29 +0800 From: Kang Yin Su <cantona@cantona.net> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: AR5416 beacon issue. Message-ID: <CAHjFwoD2KLi9QcBDBBs_f-6RWreWEO8S3VY_QjN1dY9B0%2B%2Brkw@mail.gmail.com> In-Reply-To: <CAJ-VmokJWgy9U1JoO-NWRqEnnfZ8AjGWYKeN5urvEA2r8tNG_g@mail.gmail.com> References: <CAHjFwoCVwRNyJ_jCgthWFvi%2Bh%2B7xy6-bt=hDrhimMVHS7--dtQ@mail.gmail.com> <CAHjFwoC%2BH91gXOE1V7sYtH3fQHNuSPK5=W=y_5_hQAYUYPa7Rw@mail.gmail.com> <CAJ-VmomSNinEa%2BEgNnaFQLMDRxkY72DffXdzUQ-=LL2v0FF-gg@mail.gmail.com> <CAHjFwoDP-jSYKAdKO_N5EhGFWuR3aOegCgPqGYjwA8H6-aqdaQ@mail.gmail.com> <CAJ-VmokJWgy9U1JoO-NWRqEnnfZ8AjGWYKeN5urvEA2r8tNG_g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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@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@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 > >> > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHjFwoD2KLi9QcBDBBs_f-6RWreWEO8S3VY_QjN1dY9B0%2B%2Brkw>