From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 14:12:01 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42BE116A421 for ; Fri, 4 Jan 2008 14:12:01 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.251]) by mx1.freebsd.org (Postfix) with ESMTP id DBFE813C4D3 for ; Fri, 4 Jan 2008 14:12:00 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so5219866hsj.11 for ; Fri, 04 Jan 2008 06:12:00 -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=Auo6u/ahvPWQveev1o9Jl5ADa20pxZnwSALscTcreMs=; b=jOo1z1OurCs/LeK7jjBz0UNmO7hMESoALMNFbDNgGVMbC/3A9RxkRMWR2NSL5dPdqBE3XLbi6o9i68XreH1JqjGOdd6yU6p5fni82gjaPRks7Eh8O3fxJWgC+BSFb1QxE7bXFcBc6SsXzaq2Kn15JwIZT0uPUgTZLbNwAaiCtCY= 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=TVlQR1uT5u9/CpHCeigI4LpfkoS/VOnFiz6cE8nclFh7DgLrLbty9886X4zO4cLExw51aHPp0Ts2yHDPHv2fioGQSmH/t7la+R0GSpY62b6RsNc2zt7ASadUT9sTaIYmYy5Qo7hma1vQi2EPiwM5HXHYJJqM3poyiibQJJ2X0/M= Received: by 10.142.212.19 with SMTP id k19mr5106641wfg.200.1199455911649; Fri, 04 Jan 2008 06:11:51 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 4 Jan 2008 06:11:51 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 22:11:51 +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-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 14:12:01 -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? 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 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 use different beacon se --=20 Live Free or Die