From owner-freebsd-wireless@FreeBSD.ORG Tue Aug 23 11:49:17 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 751821065673; Tue, 23 Aug 2011 11:49:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 101E08FC0C; Tue, 23 Aug 2011 11:49:16 +0000 (UTC) Received: by vxh11 with SMTP id 11so18919vxh.13 for ; Tue, 23 Aug 2011 04:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DMQe1bSIXon11BOJbcM4c9SHabbHwgQn3ayvkutc5jQ=; b=WQ22Hp2rIEmLfuak5zZO1aIhLISLTy236QFpKQQAJHkW9ZQdSDlZRUL/ujM/S2hJFd JIrub+PpfBTmlOmvX8spGSNvcqMphVAs8km1CMavYS8RyqDshK4PqQcl9Ho2X3GMZfvh hpvcODwkZXORPv05U53gEs3DSuVbp9K5Ho2G0= MIME-Version: 1.0 Received: by 10.52.20.106 with SMTP id m10mr3812062vde.328.1314100156056; Tue, 23 Aug 2011 04:49:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.33.49 with HTTP; Tue, 23 Aug 2011 04:49:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Aug 2011 19:49:16 +0800 X-Google-Sender-Auth: Cwc0v1hcQnrozg9aChGkIjJjEGI Message-ID: From: Adrian Chadd To: Kang Yin Su Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: AR5416 beacon issue. X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:49:17 -0000 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 wrote: > Please commit my fix, if everything is fine :) > > On Tue, Aug 23, 2011 at 7:27 PM, Adrian Chadd 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 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 >> > 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 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 >> >> > 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: Sto= ps >> >> >> 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(): >> >> >> >> >> >> =A0 =A0 =A0 =A0/* >> >> >> =A0 =A0 =A0 =A0 * disable seq number generation in hw >> >> >> =A0 =A0 =A0 =A0 */ >> >> >> =A0 =A0 =A0 =A0 OS_REG_WRITE(ah, AR_STA_ID1, >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 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 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 AR521= 2 >> >> >> > 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 >> >> >> > wrote: >> >> >> >> >> >> >> >> Hi All, >> >> >> >> Using FreeBSD HEAD create a AP, found that the beacon frames ha= ve >> >> >> >> no >> >> >> >> sequence number on AR5416 WiFi card, however there is sequence >> >> >> >> number >> >> >> >> on >> >> >> >> AR5212 WiFi card. Attached is the WiFi capture on both =A0 =A0c= ard. >> >> >> >> =A000:1b:b1:59:ab:4d is AR5416 and 00:0b:6b:2d:f2:cc is AR5212. >> >> >> >> Thanks, >> >> >> >> Yin >> >> >> > >> >> > >> >> > >> > >> > > >