From owner-freebsd-wireless@FreeBSD.ORG Tue Aug 23 13:23:06 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 DDE2D106566B for ; Tue, 23 Aug 2011 13:23:06 +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 9A37D8FC08 for ; Tue, 23 Aug 2011 13:23:06 +0000 (UTC) Received: by vxh11 with SMTP id 11so113438vxh.13 for ; Tue, 23 Aug 2011 06:23:05 -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; bh=b+ZpG4PLZIVoR0HfldtrWi9VAPLXN891Xyhcbk6dyGU=; b=paJG7CTbM2TsUd2rPQ0oVC5nsCX2G/q8GvBhXecuZPO5+cYcvmwK+zkl1j36/SEDJJ VTZaBcph8CF6BJZBJkoMGNYeu9BowQqIqnJzNVlcDia7AsdjFI5vRHFYCdB8DkR4fLMG YWjzXNLE+iiHemYCNfj7WgRCxPUkxzm0s9h5U= MIME-Version: 1.0 Received: by 10.52.174.35 with SMTP id bp3mr3739331vdc.462.1314105785809; Tue, 23 Aug 2011 06:23:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.33.49 with HTTP; Tue, 23 Aug 2011 06:23:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Aug 2011 21:23:05 +0800 X-Google-Sender-Auth: IXAcCJpb_BoOZ4iGd-xvv7_PR4o Message-ID: From: Adrian Chadd To: Kang Yin Su Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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 13:23:06 -0000 Hi! 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 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