Re: Workaround for an rsu(4) bug
On Tue, February 5, 2013 14:10, Stuart Henderson wrote: On 2013/02/05 05:18, Brad Smith wrote: On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. The other issue I'm experiencing is when the driver does a scan either from the kernel doing so or from me issuing ifconfig scan will result in rsu_site_survey() failing (rsu0: could not send site survey command) after a few invocations of the function to issue the fw command. Over all though rsu(3) is still mainly unusable at least for the chipset in the adapter I am using; it is way too unreliable. It might be worth trying a different firmware. Looks like the Linux people had some issues with some firmware versions judging from the log messages in their git firmware repo. You'll want rtl8712u.bin from: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi;hb=HEAD With this newer firmware I can do many manual scans in a row and the over all stability of connections associated with an AP is more stable too. Also IPv6 seems to work consistently now. It was cutting in and and out before as if multicast traffic was being dropped. It is not 100% perfect as I was still able to reproduce the site survey errors after quite a few scans but compared to the current firmware package it seems to be quite an improvement. Could you (and other rsu(4) users) test this updated firmware package please: http://junkpile.org/rsu-firmware-1.2.tgz Slightly related, I have problems scanning from iwn; 30 second delay with wchan 80211scan and no scan results. Network is unusable afterwards until I down+up the interface. iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address 8c:70:5a:62:b7:f8 Hi! I still have some problems with 1.2 firmware and rsu wifi on 5.3-beta: Feb 20 12:25:45 barton /bsd: rsu0: could not send join command Feb 20 12:25:47 barton /bsd: rsu0: could not send site survey command Feb 20 12:29:22 barton /bsd: ehci_idone: ex=0x8017f800 is done! Feb 20 12:29:22 barton dhclient[14203]: dispatch_imsg in main: pipe closed Feb 20 12:29:22 barton dhclient[10353]: receive_packet failed on rsu0: Input/output error Feb 20 12:29:22 barton dhclient[10353]: ioctl(SIOCGIFFLAGS) on rsu0: Device not configured Feb 20 12:29:22 barton dhclient[14203]: SIOCDIFADDR failed (10.219.11.4): Device not configured Feb 20 12:29:22 barton /bsd: rsu0 detached Feb 20 12:29:23 barton /bsd: rsu0 at uhub0 Feb 20 12:29:23 barton /bsd: port 3 Manufacturer Realtek ASUS EZ N Network Adapter rev 2.00/2.00 addr 2 Feb 20 12:29:24 barton /bsd: rsu0: MAC/BB RTL8712 cut 3, address c8:60:00:5e:11:bb Feb 20 13:23:23 barton /bsd: rsu0: could not send join command Feb 20 13:23:25 barton /bsd: rsu0: could not send site survey command Feb 20 13:24:52 barton /bsd: ehci_idone: ex=0x8017f800 is done! Feb 20 13:24:52 barton dhclient[10599]: receive_packet failed on rsu0: Input/output error Feb 20 13:24:52 barton dhclient[10599]: ioctl(SIOCGIFFLAGS) on rsu0: Device not configured Feb 20 13:24:52 barton dhclient[1735]: dispatch_imsg in main: pipe closed Feb 20 13:24:52 barton dhclient[1735]: SIOCDIFADDR failed (10.219.11.4): Device not configured Feb 20 13:24:52 barton /bsd: rsu0 detached Feb 20 13:24:55 barton /bsd: rsu0 at uhub0 Feb 20 13:24:55 barton /bsd: port 3 Manufacturer Realtek ASUS EZ N Network Adapter rev 2.00/2.00 addr 2 Feb 20 13:24:55 barton /bsd: rsu0: MAC/BB RTL8712 cut 3, address c8:60:00:5e:11:bb I need to unplug and plug it to reconnect to AP (AP is based on 5.3-beta amd64 from 12 Feb + ral0 Ralink RT2790) But it became more stable with this firmware than before. dmesg.barton Description: Binary data
Re: Workaround for an rsu(4) bug
On Wed, Feb 20, 2013 at 01:23:00PM +0300, Kirill Bychkov wrote: On Tue, February 5, 2013 14:10, Stuart Henderson wrote: On 2013/02/05 05:18, Brad Smith wrote: On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. The other issue I'm experiencing is when the driver does a scan either from the kernel doing so or from me issuing ifconfig scan will result in rsu_site_survey() failing (rsu0: could not send site survey command) after a few invocations of the function to issue the fw command. Over all though rsu(3) is still mainly unusable at least for the chipset in the adapter I am using; it is way too unreliable. It might be worth trying a different firmware. Looks like the Linux people had some issues with some firmware versions judging from the log messages in their git firmware repo. You'll want rtl8712u.bin from: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi;hb=HEAD With this newer firmware I can do many manual scans in a row and the over all stability of connections associated with an AP is more stable too. Also IPv6 seems to work consistently now. It was cutting in and and out before as if multicast traffic was being dropped. It is not 100% perfect as I was still able to reproduce the site survey errors after quite a few scans but compared to the current firmware package it seems to be quite an improvement. Could you (and other rsu(4) users) test this updated firmware package please: http://junkpile.org/rsu-firmware-1.2.tgz Slightly related, I have problems scanning from iwn; 30 second delay with wchan 80211scan and no scan results. Network is unusable afterwards until I down+up the interface. iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address 8c:70:5a:62:b7:f8 Hi! I still have some problems with 1.2 firmware and rsu wifi on 5.3-beta: Feb 20 12:25:45 barton /bsd: rsu0: could not send join command Feb 20 12:25:47 barton /bsd: rsu0: could not send site survey command Feb 20 12:29:22 barton /bsd: ehci_idone: ex=0x8017f800 is done! Feb 20 12:29:22 barton dhclient[14203]: dispatch_imsg in main: pipe closed Feb 20 12:29:22 barton dhclient[10353]: receive_packet failed on rsu0: Input/output error Feb 20 12:29:22 barton dhclient[10353]: ioctl(SIOCGIFFLAGS) on rsu0: Device not configured Feb 20 12:29:22 barton dhclient[14203]: SIOCDIFADDR failed (10.219.11.4): Device not configured Feb 20 12:29:22 barton /bsd: rsu0 detached Feb 20 12:29:23 barton /bsd: rsu0 at uhub0 Feb 20 12:29:23 barton /bsd: port 3 Manufacturer Realtek ASUS EZ N Network Adapter rev 2.00/2.00 addr 2 Feb 20 12:29:24 barton /bsd: rsu0: MAC/BB RTL8712 cut 3, address c8:60:00:5e:11:bb Feb 20 13:23:23 barton /bsd: rsu0: could not send join command Feb 20 13:23:25 barton /bsd: rsu0: could not send site survey command Feb 20 13:24:52 barton /bsd: ehci_idone: ex=0x8017f800 is done! Feb 20 13:24:52 barton dhclient[10599]: receive_packet failed on rsu0: Input/output error Feb 20 13:24:52 barton dhclient[10599]: ioctl(SIOCGIFFLAGS) on rsu0: Device not configured Feb 20 13:24:52 barton dhclient[1735]: dispatch_imsg in main: pipe closed Feb 20 13:24:52 barton dhclient[1735]: SIOCDIFADDR failed (10.219.11.4): Device not configured Feb 20 13:24:52 barton /bsd: rsu0 detached Feb 20 13:24:55 barton /bsd: rsu0 at uhub0 Feb 20 13:24:55 barton /bsd: port 3 Manufacturer Realtek ASUS EZ N Network Adapter rev 2.00/2.00 addr 2 Feb 20 13:24:55 barton /bsd: rsu0: MAC/BB RTL8712 cut 3, address c8:60:00:5e:11:bb I need to unplug and plug it to reconnect to AP (AP is based on 5.3-beta amd64 from 12 Feb + ral0 Ralink RT2790) But it became more stable with this firmware than before. I had been using the adapter in another area of the home which is closer to the AP for the last week and I noticed I had zero issues for the whole week. Then all of a sudden I started experiencing the problems reconnecting and it was way worse than when I was upstairs and further away from the AP. I also noticed the ``ehci_idone: ex=0x8017f800 is done!'' EHCI messages I do not believe were happening earlier. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Workaround for an rsu(4) bug
On Wed, Feb 06, 2013 at 10:36:41AM -0500, Brad Smith wrote: On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. It seems to be the first call to rsu_fw_cmd() from the debug output.. the failure within rsu_join_bss() does not happen with every call of the rsu_join_bss() function though. So this has happened a few more times and I can see it is always failing in the same spot. site survey pass 0 done, found 3 BSS newstate 1 - 1 sending site survey command, pass=1 Tx cmd code=18 len=48 Rx event code=19 len=33 Rx event code=19 len=16 Rx event code=19 len=16 Rx event code=8 len=424 found BSS 84:1b:5e:4d:ef:36: len=424 chan=1 inframode=1 networktype=3 privacy=1 Rx event code=9 len=4 site survey pass 1 done, found 1 BSS newstate 1 - 2 setting operating mode to 2 Tx cmd code=17 len=8 Rx event code=19 len=33 rsu0: could not send join command newstate 1 - 1 sending site survey command, pass=0 Tx cmd code=18 len=48 rsu0: could not send site survey command $ dmesg | grep join sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 rsu0: could not send join command sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Workaround for an rsu(4) bug
Date: Thu, 7 Feb 2013 09:26:58 -0500 From: Brad Smith b...@comstyle.com On Wed, Feb 06, 2013 at 10:36:41AM -0500, Brad Smith wrote: On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. It seems to be the first call to rsu_fw_cmd() from the debug output.. the failure within rsu_join_bss() does not happen with every call of the rsu_join_bss() function though. So this has happened a few more times and I can see it is always failing in the same spot. But it isn't at all clear to me which rsu_fw_cmd() call is failing from the output you posted. site survey pass 0 done, found 3 BSS newstate 1 - 1 sending site survey command, pass=1 Tx cmd code=18 len=48 Rx event code=19 len=33 Rx event code=19 len=16 Rx event code=19 len=16 Rx event code=8 len=424 found BSS 84:1b:5e:4d:ef:36: len=424 chan=1 inframode=1 networktype=3 privacy=1 Rx event code=9 len=4 site survey pass 1 done, found 1 BSS newstate 1 - 2 setting operating mode to 2 Tx cmd code=17 len=8 Rx event code=19 len=33 rsu0: could not send join command newstate 1 - 1 sending site survey command, pass=0 Tx cmd code=18 len=48 rsu0: could not send site survey command $ dmesg | grep join sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 rsu0: could not send join command sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1
Re: Workaround for an rsu(4) bug
On Thu, Feb 07, 2013 at 03:44:12PM +0100, Mark Kettenis wrote: Date: Thu, 7 Feb 2013 09:26:58 -0500 From: Brad Smith b...@comstyle.com On Wed, Feb 06, 2013 at 10:36:41AM -0500, Brad Smith wrote: On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. It seems to be the first call to rsu_fw_cmd() from the debug output.. the failure within rsu_join_bss() does not happen with every call of the rsu_join_bss() function though. So this has happened a few more times and I can see it is always failing in the same spot. But it isn't at all clear to me which rsu_fw_cmd() call is failing from the output you posted. site survey pass 0 done, found 3 BSS newstate 1 - 1 sending site survey command, pass=1 Tx cmd code=18 len=48 Rx event code=19 len=33 Rx event code=19 len=16 Rx event code=19 len=16 Rx event code=8 len=424 found BSS 84:1b:5e:4d:ef:36: len=424 chan=1 inframode=1 networktype=3 privacy=1 Rx event code=9 len=4 site survey pass 1 done, found 1 BSS newstate 1 - 2 setting operating mode to 2 Tx cmd code=17 len=8 Rx event code=19 len=33 rsu0: could not send join command newstate 1 - 1 sending site survey command, pass=0 Tx cmd code=18 len=48 rsu0: could not send site survey command On a successful call to rsu_join_bss() you would see something like... Not seeing the ``setting auth mode to 2'' debug printf indicates it is failing on the firmware command before that which is setting the op mode. site survey pass 0 done, found 4 BSS newstate 1 - 1 sending site survey command, pass=1 Tx cmd code=18 len=48 Rx event code=19 len=33 Rx event code=19 len=16 Rx event code=19 len=16 Rx event code=8 len=424 found BSS 84:1b:5e:4d:ef:36: len=424 chan=1 inframode=1 networktype=3 privacy=1 Rx event code=9 len=4 site survey pass 1 done, found 1 BSS newstate 1 - 2 setting operating mode to 2 Tx cmd code=17 len=8 Rx event code=19 len=33 setting auth mode to 2 Tx cmd code=19 len=8 Rx event code=19 len=22 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Tx cmd code=14 len=248 Rx event code=19 len=19 Rx event code=19 len=14 Rx event code=19 len=47 Rx event code=19 len=21 Rx event code=19 len=12 Rx event code=19 len=26 Rx event code=19 len=41 Rx event code=10 len=180 Rx join BSS event len=180 res=1 associated with 84:1b:5e:4d:ef:36 associd=1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Workaround for an rsu(4) bug
On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. It seems to be the first call to rsu_fw_cmd() from the debug output.. the failure within rsu_join_bss() does not happen with every call of the rsu_join_bss() function though. site survey pass 0 done, found 3 BSS newstate 1 - 1 sending site survey command, pass=1 Tx cmd code=18 len=48 Rx event code=19 len=33 Rx event code=19 len=16 Rx event code=19 len=16 Rx event code=8 len=424 found BSS 84:1b:5e:4d:ef:36: len=424 chan=1 inframode=1 networktype=3 privacy=1 Rx event code=9 len=4 site survey pass 1 done, found 1 BSS newstate 1 - 2 setting operating mode to 2 Tx cmd code=17 len=8 Rx event code=19 len=33 rsu0: could not send join command newstate 1 - 1 sending site survey command, pass=0 Tx cmd code=18 len=48 rsu0: could not send site survey command $ dmesg | grep join sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 rsu0: could not send join command sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 sending join bss command to 84:1b:5e:4d:ef:36 chan 1 Rx join BSS event len=180 res=1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Workaround for an rsu(4) bug
On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. The other issue I'm experiencing is when the driver does a scan either from the kernel doing so or from me issuing ifconfig scan will result in rsu_site_survey() failing (rsu0: could not send site survey command) after a few invocations of the function to issue the fw command. Over all though rsu(3) is still mainly unusable at least for the chipset in the adapter I am using; it is way too unreliable. It might be worth trying a different firmware. Looks like the Linux people had some issues with some firmware versions judging from the log messages in their git firmware repo. You'll want rtl8712u.bin from: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi;hb=HEAD With this newer firmware I can do many manual scans in a row and the over all stability of connections associated with an AP is more stable too. Also IPv6 seems to work consistently now. It was cutting in and and out before as if multicast traffic was being dropped. It is not 100% perfect as I was still able to reproduce the site survey errors after quite a few scans but compared to the current firmware package it seems to be quite an improvement. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Workaround for an rsu(4) bug
On 2013/02/05 05:18, Brad Smith wrote: On Tue, Feb 05, 2013 at 12:26:47AM +0100, Mark Kettenis wrote: Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. The other issue I'm experiencing is when the driver does a scan either from the kernel doing so or from me issuing ifconfig scan will result in rsu_site_survey() failing (rsu0: could not send site survey command) after a few invocations of the function to issue the fw command. Over all though rsu(3) is still mainly unusable at least for the chipset in the adapter I am using; it is way too unreliable. It might be worth trying a different firmware. Looks like the Linux people had some issues with some firmware versions judging from the log messages in their git firmware repo. You'll want rtl8712u.bin from: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi;hb=HEAD With this newer firmware I can do many manual scans in a row and the over all stability of connections associated with an AP is more stable too. Also IPv6 seems to work consistently now. It was cutting in and and out before as if multicast traffic was being dropped. It is not 100% perfect as I was still able to reproduce the site survey errors after quite a few scans but compared to the current firmware package it seems to be quite an improvement. Could you (and other rsu(4) users) test this updated firmware package please: http://junkpile.org/rsu-firmware-1.2.tgz Slightly related, I have problems scanning from iwn; 30 second delay with wchan 80211scan and no scan results. Network is unusable afterwards until I down+up the interface. iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address 8c:70:5a:62:b7:f8
Re: Workaround for an rsu(4) bug
Date: Tue, 5 Feb 2013 11:10:01 + From: Stuart Henderson s...@spacehopper.org On 2013/02/05 05:18, Brad Smith wrote: With this newer firmware I can do many manual scans in a row and the over all stability of connections associated with an AP is more stable too. Also IPv6 seems to work consistently now. It was cutting in and and out before as if multicast traffic was being dropped. It is not 100% perfect as I was still able to reproduce the site survey errors after quite a few scans but compared to the current firmware package it seems to be quite an improvement. I believe it is actually an older firmware. Could you (and other rsu(4) users) test this updated firmware package please: http://junkpile.org/rsu-firmware-1.2.tgz Thanks Stuart. Seems to work for me on: rsu0 at uhub0 port 1 Manufacturer Realtek RTL8188S WLAN Adapter rev 2.00/2.00 addr 2 rsu0: MAC/BB RTL8712 cut 3, address 00:0c:f6:7d:37:ae Can't do any really heavy testing though. Slightly related, I have problems scanning from iwn; 30 second delay with wchan 80211scan and no scan results. Network is unusable afterwards until I down+up the interface. iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address 8c:70:5a:62:b7:f8 I think that always has been broken. It's never bothered me enough to look into it though.
Re: Workaround for an rsu(4) bug
On Tue, Feb 05, 2013 at 05:58:09PM +0100, Mark Kettenis wrote: I believe it is actually an older firmware. Looking at the debug printf indicating the month/day for the firmware that seems to be so. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Workaround for an rsu(4) bug
Date: Tue, 29 Jan 2013 21:04:30 -0500 From: Brad Smith b...@comstyle.com To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. Hmm, I wonder which of the two rsu_fw_cmd() calls in rsu_join_bss() is failing. The other issue I'm experiencing is when the driver does a scan either from the kernel doing so or from me issuing ifconfig scan will result in rsu_site_survey() failing (rsu0: could not send site survey command) after a few invocations of the function to issue the fw command. Over all though rsu(3) is still mainly unusable at least for the chipset in the adapter I am using; it is way too unreliable. It might be worth trying a different firmware. Looks like the Linux people had some issues with some firmware versions judging from the log messages in their git firmware repo. You'll want rtl8712u.bin from: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi;hb=HEAD Cheers, Mark
Re: Workaround for an rsu(4) bug
On Mon, Jan 28, 2013 at 04:44:39PM +0100, Mark Kettenis wrote: When working on the WPA-Enterprise stuff, I actually ran into an issue with the rsu(4) I was using. It seems there is a problem with submitting the join BSS command when an RSN information element is included, which makes the command never complete. The crucial bit seems to be that this changes the length of the command to something the firmware doesn't like. The code rounds the length up to the next multiple of 8, but it seems the firmware wants it to be at least a multiple of 16. The easiest fix seems to be to just send the entire buffer that we allocate for the command. This will transfer more bytes than strictly necessary, but this command isn't sent invoked very often so I don't think this will be a problem. This diff might fix issues with WPA-PSK as well. ok? Tested with rsu0 at uhub0 port 5 Manufacturer Realtek RTL8188S WLAN Adapter rev 2.00/2.00 addr 2 rsu0: MAC/BB RTL8712 cut 3, address 00:13:33:ad:0a:fc while constantly switching between OpenBSD and Linux APs with WPA. Works fine. ok. Index: if_rsu.c === RCS file: /cvs/src/sys/dev/usb/if_rsu.c,v retrieving revision 1.14 diff -u -p -r1.14 if_rsu.c --- if_rsu.c 3 Jul 2011 15:47:17 - 1.14 +++ if_rsu.c 28 Jan 2013 15:23:46 - @@ -1078,7 +1078,7 @@ rsu_join_bss(struct rsu_softc *sc, struc bss-len = htole32(((frm - buf) + 3) ~3); DPRINTF((sending join bss command to %s chan %d\n, ether_sprintf(bss-macaddr), letoh32(bss-config.dsconfig))); - return (rsu_fw_cmd(sc, R92S_CMD_JOIN_BSS, buf, frm - buf)); + return (rsu_fw_cmd(sc, R92S_CMD_JOIN_BSS, buf, sizeof(buf))); } int
Re: Workaround for an rsu(4) bug
On Mon, Jan 28, 2013 at 04:44:39PM +0100, Mark Kettenis wrote: When working on the WPA-Enterprise stuff, I actually ran into an issue with the rsu(4) I was using. It seems there is a problem with submitting the join BSS command when an RSN information element is included, which makes the command never complete. The crucial bit seems to be that this changes the length of the command to something the firmware doesn't like. The code rounds the length up to the next multiple of 8, but it seems the firmware wants it to be at least a multiple of 16. The easiest fix seems to be to just send the entire buffer that we allocate for the command. This will transfer more bytes than strictly necessary, but this command isn't sent invoked very often so I don't think this will be a problem. This diff might fix issues with WPA-PSK as well. ok? To a certain extent this seems to make rsu(3) work a little better, but now I am seeing ``rsu0: could not send join command'' messages which never happened before. The other issue I'm experiencing is when the driver does a scan either from the kernel doing so or from me issuing ifconfig scan will result in rsu_site_survey() failing (rsu0: could not send site survey command) after a few invocations of the function to issue the fw command. Over all though rsu(3) is still mainly unusable at least for the chipset in the adapter I am using; it is way too unreliable. I am using.. rsu0 at uhub0 port 2 Manufacturer Realtek 11n USB Adapter rev 2.00/2.00 addr 2 rsu0: MAC/BB RTL8712 cut 3, address 00:14:d1:6e:ac:6c -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Workaround for an rsu(4) bug
When working on the WPA-Enterprise stuff, I actually ran into an issue with the rsu(4) I was using. It seems there is a problem with submitting the join BSS command when an RSN information element is included, which makes the command never complete. The crucial bit seems to be that this changes the length of the command to something the firmware doesn't like. The code rounds the length up to the next multiple of 8, but it seems the firmware wants it to be at least a multiple of 16. The easiest fix seems to be to just send the entire buffer that we allocate for the command. This will transfer more bytes than strictly necessary, but this command isn't sent invoked very often so I don't think this will be a problem. This diff might fix issues with WPA-PSK as well. ok? Index: if_rsu.c === RCS file: /cvs/src/sys/dev/usb/if_rsu.c,v retrieving revision 1.14 diff -u -p -r1.14 if_rsu.c --- if_rsu.c3 Jul 2011 15:47:17 - 1.14 +++ if_rsu.c28 Jan 2013 15:23:46 - @@ -1078,7 +1078,7 @@ rsu_join_bss(struct rsu_softc *sc, struc bss-len = htole32(((frm - buf) + 3) ~3); DPRINTF((sending join bss command to %s chan %d\n, ether_sprintf(bss-macaddr), letoh32(bss-config.dsconfig))); - return (rsu_fw_cmd(sc, R92S_CMD_JOIN_BSS, buf, frm - buf)); + return (rsu_fw_cmd(sc, R92S_CMD_JOIN_BSS, buf, sizeof(buf))); } int
