From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 14:20:50 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 529F416A41B for ; Fri, 4 Jan 2008 14:20:50 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 0236F13C4E5 for ; Fri, 4 Jan 2008 14:20:49 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1268943nzf.13 for ; Fri, 04 Jan 2008 06:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XUfzhWiPvibjl+4pAvSRIATeeuY/MnHnU5BJGFvoC3M=; b=a295olCP04njz6P9VIj2XP+1jbzu+rxJ23TWLoUDdiQHP1nRC5jherzz3QFq/Lg71wkEdkeI9shu8Q9exUuYUr4AvCBjWOpSiwJbgbPTR4CS2xIr73UmQAc3fTvEFIGE16aXGJPb0aLd6CjJV+jwzf3S9swFUXFAQuroVvCxq2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lXQE/E+TI1OtONwhvPsjyV9h5ioYteQj4h6qOEP1i0bB4qAVssIdRL3kzcMpauWRrqjSIyZEpwnCRbO2PZrJPFb9rH7hbNIpqc+n8pOBQ3Oubi601KOlnDX3+sWWePh5Iu1j8Eu5Qr7tGmSGeQfbhQ0gFeYWwExkc7jjQWezjvE= Received: by 10.143.173.2 with SMTP id a2mr1241885wfp.168.1199456448741; Fri, 04 Jan 2008 06:20:48 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:20:48 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:20:48 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:20:50 -0000 On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > Are you also using freebsd as STA too? If yes, would you have time to > > gather following information on the STA side before after and during > > the rsyncing: > > 1) wlandebug -i sta_iface +input > > 2) tcpdump -ni sta_iface -y ieee802_11 -w dump.bin > > I'll have to pull out an old laptop to do that, my current one runs > Ubuntu. Hopefully, I'll have the results for you later today. I > imagine you want to see the output from wlandebug both when the AP is > working and when it is stuck? > > DES > -- > > Dag-Erling Sm=F8rgrav - des@des.no > Grr, keyboard mis-fire :P Yes. I just did some air dump of ral's beacon and data frame A sample ral(4) broadcast beacon frame: 21:26:26.662250 Beacon (sephe-hostap) [1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 6 0x0000: 8000 0000 ffff ffff ffff 0015 f2d7 420c 0x0010: 0015 f2d7 420c 0000 e053 4a10 0000 0000 0x0020: 6400 2104 000c 7365 7068 652d 686f 7374 0x0030: 6170 0108 8284 8b96 0c12 1824 0301 0605 0x0040: 0400 0101 002a 0100 3204 3048 606c The seq is 0!! Two sample ral(4) data frames (ICMP echo resps) 21:26:27.810209 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 1, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c f0b1 aaaa 0300 0000 0800 0x0020: 4500 0054 0e75 0000 4001 e0e0 c0a8 0502 0x0030: c0a8 0501 0800 42b2 f211 0001 477e 3403 0x0040: 000c 5caa 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 21:26:28.820190 IP 192.168.5.2 > 192.168.5.1: ICMP echo request, id 61969, seq 2, length 64 0x0000: 0801 2c00 0015 f2d7 420c 0014 787a 5990 0x0010: 0015 f2d7 420c 00b2 aaaa 0300 0000 0800 0x0020: 4500 0054 f517 0000 4001 fa3d c0a8 0502 0x0030: c0a8 0501 0800 1bb1 f211 0002 477e 3404 0x0040: 000c 83a9 0809 0a0b 0c0d 0e0f 1011 1213 0x0050: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 802.11 stack does the right thing here, seq is incremented between two fram= es. This actually brings up two things: 1) I think we should ignore seq in multicast frames; this is permitted in 802.11 standard. In dfly I did that, since one of our users encountered a broken commercial AP which is not 802.11e but uses different seq for data and beacon. 2) TX sequence. I think standards only mention QSTA/nQSTA, but not AP. Currently our AP uses per node TX seq, which means beacon's seq is difficult to choose, at least for 2560 based ral(4), whose beacons' seq need to be set by software. I saw Linksys AP uses one seq for all of the frames it sends. Sam, what's you opinion on this? I think if STA counts ral(4)'s beacon seq, as what we do currently, beacon missing will quickly happen since beacons will be discarded after first several data frames. Best Regards, sephe --=20 Live Free or Die