Date: Fri, 4 Jan 2008 22:20:48 +0800 From: "Sepherosa Ziehau" <sepherosa@gmail.com> To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" <des@des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression Message-ID: <ea7b9c170801040620l1e1c27a1t30a875b32dc0f01c@mail.gmail.com> In-Reply-To: <86lk76c6t5.fsf@ds4.des.no> References: <86ir2hznnd.fsf@ds4.des.no> <ea7b9c170712312227m7a961c95kc2bed20f94d09593@mail.gmail.com> <86abnpu0wv.fsf@ds4.des.no> <ea7b9c170801020518m6d5f8fdejd01947166669e9e4@mail.gmail.com> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <ea7b9c170801031824n2205c1e8i2f010df67a07dfff@mail.gmail.com> <86lk76c6t5.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 4, 2008 4:51 PM, Dag-Erling Sm=F8rgrav <des@des.no> wrote:
> "Sepherosa Ziehau" <sepherosa@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ea7b9c170801040620l1e1c27a1t30a875b32dc0f01c>