Finished: CALL FOR TESTERS Ralink wireless run(4) usb driver for FreeBSD

[Denzelii]

The new log was attached.

It was the same.

Small description:

at Jul 19 22:22:24 - I'm trying to reconnect with my cellphone
(the led is blinking with the same speed, cellphone can see the ap, but can't connect to it)
at Jul 19 22:25:13 - hostapd restarted
at Jul 19 22:26:** - speedtest runned
Jul 19 22:22:27:** - a trying to run the test again, but freezed
(the led is blinking with the same speed, cellphone can see the ap, but can't connect to it)

10 minutes later: cellphone can see the ap, but can't connect to it

Last night the phone can reconnect after a few minutes, but now, after 14 minutes can't estabilish a connection.

 

[Denzelii]

35 minutes later, the cellphone still can't connect without hostapd restart.

I think when hostapd restarting, the buffer is reinitializing.

Thanks you help!

 

[PseudoCylon]

I was hoping the workaround would buy me sometime for digging in the problem, but I guess it didn't.

Since I don't have any documentation, it will take while to figure out. In the meantime, you can try 11n version. Your device is a b/g only one, but Tx OP related bits are also enabled. It might help shooting the packet into the air.

Also, here is Ralink's code. I will be more than happy if you find the problem.

 

[Denzelii]

Sorry, I was away.

I downloaded, compiled and tried the 11n version, but producing the same behavior.
(run0: device time out after for a short time).

What should I check in the Ralink's code? I know programing in C, so I hope I can help, but I don't understand the if_run.c, so I don't have any idea, where should I start debugging or modifying the code. I never wrote driver. I just wrote some other programs.

As I think, I can't use the Ralink driver directly. What functions should I check?

 

[Denzelii]

I tried the Egorenkov driver (http://forums.freebsd.org/showthread.php?t=7010): it is not working.

 

[PseudoCylon]

What should I check in the Ralink's code? I know programing in C, so I hope I can help, but I don't understand the if_run.c, so I don't have any idea, where should I start debugging or modifying the code. I never wrote driver. I just wrote some other programs.

Cool!

In this case, the device doesn't like the data received, and the data is stuck in the device (nothing is transmitted). Maybe, there is something not right in Tx pass, run_raw_xmit() or run_start(). The last time it was just zeroing trailing bytes. You may compare with Ralink's, i.e. this.

The log shows run_update_beacon() is called far too often. At my place, it is only called once every 15 min. or so. I guess tx bulk transfer and run_do_request() are called at wrong time or order. usbd_do_request_flags() can sleep, so calling it first doesn't guarantee completed first. Though APs don't bgscan, in sta mode, bgscan causes device timeout (That's why the driver doesn't support it.) Because, during the scan, registers are also read/written often, I guess that does something with the device timeout. I'm checking these functions to see if there is anything I need to do. But this is my guess. If you have other guess, you are more than welcome to dig into it. I don't have any documentation; you can find everything I know on the internet.

If it isn't a big problem, try using the AP in low wireless traffic area and see if the timeout still occurs. Also, it would be helpful if you find out what is updating the becaon by adding an extra debug message, like

run_update_beacon(struct ieee80211vap *vap, int item)
{
...
        KASSERT(vap != NULL, ("no beacon"));
[color="Green"]+
+       DPRINTF("item=%d\n", item);
+[/color]
        switch (item) {

 

[Denzelii]

Ok, I will try something.

But, I know programing in C doesn't means I understand this code, or I know what that function doing, or what that structure represent.

 

[PseudoCylon]

But, I know programing in C doesn't means I understand this code, or I know what that function doing, or what that structure represent.

That's true. But, to read and understand someone's code is also part of porting software, even though it is time consuming. Checking with linux code might be easier, because it is cross referenced, i.e. rt2800.c or rt2800lib.c.

I guess switching slot time during active Tx might be the cause.

Anyway, I'm happy with you have understood how much time I have to spend to fix this bug, at least.

 

[Denzelii]

I understand.
But I realized cheaper and faster to buy a supported hardware than to fix this.

Problem solved, I bought an asus stick.

Thanks for your helping.

 

[PseudoCylon]

So, this is a device specific (RT3070/RF2020) problem then. That helps digging the problem further. Though, since you have got a new device, I'll finish adding 11n support.

 

[wbedard]

Hi PseudoCyclon,

Although it has been some time since this thread was last active, I would like to touch base with you to see if you would be interested in working with me to more or less pick up where this thread last left off. I am working with a new hardware setup running pfSense 2.1 (FreeBSD 8.3) and a couple of the following USB WiFi adapters:

Alfa Networks AWUS051NH

This adapter uses the Ralink RT2770 chipset and Alfa makes a lot of driver resources available over on their SourceForge page, here:

Alfa Networks on SourceForge

As for my ability to assist you in this effort, while I am not a developer, I am comfortable reading code and can certainly build patched versions of operating systems such as Android and FreeBSD. My pfSense hardware is my initial exposure to FreeBSD so I am still learning a lot but I am a pretty quick study in this area.

I have been following your progress on the "run" driver over at Gitorius and would be more than happy to assist you in testing it, especially the new 802.11n functionality. My principal focus, at the moment though, is to get past the "device timeout" issues that you previously discussed in this thread. Please let me know if your current situation allows you to spend some time working with me to make some progress here. Thanks in advance!

R/
wbedard

 

[PseudoCylon]

My principal focus, at the moment though, is to get past the "device timeout" issues that you previously discussed in this thread.

That fix didn't go into 8.* You need to manually patch the code because you are running 8.3 RELEASE.

[B]diff --git a/if_run.c b/if_run.c
--- a/if_run.c
+++ b/if_run.c[/B]
[color="Blue"]@@ -2747,6 +2747,9 @@ run_bulk_tx_callbackN(struct usb_xfer *xfer, usb_error_t error, unsigned int index)[/color]
        size = sizeof(data->desc);
        usbd_copy_in(pc, 0, &data->desc, size);
        usbd_m_copy_in(pc, size, m, 0, m->m_pkthdr.len);
[color="Green"]+       size += m->m_pkthdr.len;
+       usbd_frame_zero(pc, size, ((-size) & 3) + 8);
+       size += ((-size) & 3) + 8;[/color]

        vap = data->ni->ni_vap;
        if (ieee80211_radiotap_active_vap(vap)) {

especially the new 802.11n functionality.

Actually, 8.* + 11n isn't a good combination because there are number of changes in 80211 stack. I remember it was a big pain in the neck, and I dumped 8.2 as soon as 9.0 was released. You need an extra hardware to run CURRENT (or 9.2 at least) to test 11n support.

 

[wbedard]

That fix didn't go into 8.* You need to manually patch the code because you are running 8.3 RELEASE
....

That little patch looks surprisingly easy to apply. I'm looking forward to trying that out! Can you point out any posts/threads where others have had positive results using your patch, perhaps even using similar USB adapters?

Actually, 8.* + 11n isn't a good combination because there are number of changes in 80211 stack. I remember it was a big pain in the neck, and I dumped 8.2 as soon as 9.0 was released. You need an extra hardware to run CURRENT (or 9.2 at least) to test 11n support.

Yes, I apologize for not being more clear on that point. I was aware that 11n couldn't be used in my "production" hardware running pfsense. What I was imagining doing was connecting one of my Alfa USB devices to my laptop and binding it to a VM running whatever version of FreeBSD you wanted tested. I haven't actually verified that it would work though, since I was uncertain just how compatible my adapters were with FreeBSD. Your patch has greatly encouraged me, though. Let me know if you would be interested in me going down this route and providing you with my test results.

R/
wbedard

 

[PseudoCylon]

Can you point out any posts/threads where others have had positive results using your patch, perhaps even using similar USB adapters?

Here is the original post, but his device uses different chipset.
http://forums.freebsd.org/showthread.php?p=156885#post156885

What I was imagining doing was connecting one of my Alfa USB devices to my laptop and binding it to a VM running whatever version of FreeBSD you wanted tested.

9.2-RELEASE should do the job. Whether using CURRENT or the latest RELEASE, you will be end up checking-out the latest source and re-compile when there are important changes in 80211 stack.

Exactly what chipset does your device have? When you plug-in the device, there will be a debug message like this

run0: MAC/BBP RT3572 (rev 0x0221), RF RT3052 (MIMO 2T2R), address ...

 

[gnoma]

Hello,

I have linksys WMP600N:

ral0@pci0:2:2:0:	class=0x028000 card=0x00671737 chip=0x06011814 rev=0x00 hdr=0x00
    vendor     = 'Ralink corp.'
    device     = 'RT2800 802.11n PCI'
    class      = network

I was using FreeBSD 7.2 for long time and I was working with if_run driver in 11g mode.

However I reinstalled to FreeBSD 9.0. Now I didn't have to install a driver, it was already included in the kernerl.
I want now to use it in 11n mode, but I wasn't able to configure it:

root@sentinel:/ # ifconfig wlan0 mode 11n
ifconfig: SIOCSIFMEDIA (media): Device not configured

No encryption, no hostapd or some other stuff. I guess that the driver just doesn't support it. Now I saw that there is 11n support for this driver here. I hope it will still work so good now as it worked on FreeBSD 7.2 in 11g mode. My problem is that I don't know how to unload/remove the existing driver, as it is included in the kernel, so I can load the new one. Do I have to recompile the kernel? Is it possible to do it without recompile?

Thank you.

 

[wbedard]

Here is the original post, but his device uses different chipset.
http://forums.freebsd.org/showthread.php?p=156885#post156885

Thanks for the reference. I'll definitely check it out!

Exactly what chipset does your device have? When you plug-in the device, there will be a debug message like this...

My device looks like the following on pfSense 2.1 (FreeBSD 8.3):

run0: <1.0> on usbus1
run0: MAC/BBP RT2872 (rev 0x0202), RF RT2750 (MIMO 1T2R), address ....
run0: firmware RT2870 loaded

 

[PseudoCylon]

@gnoma,

ral0@pci0:2:2:0:	class=0x028000 card=0x00671737 chip=0x06011814 rev=0x00 hdr=0x00
    vendor     = 'Ralink corp.'
    device     = 'RT2800 802.11n PCI'
    class      = network

Your device uses ral(4), totally different driver. As far as I know, no one is working on adding 11n support at this moment.

@wbedard,

My device looks like the following on pfSense 2.1 (FreeBSD 8.3):

run0: <1.0> on usbus1
run0: MAC/BBP RT2872 (rev 0x0202), RF RT2750 (MIMO 1T2R), address ....
run0: firmware RT2870 loaded

I do not have any device with this chipset, but the driver on gitorious should (or hopefully) work. But, patch and see if device time out disappears before trying 11n.

 

[wbedard]

@wbedard,
I do not have any device with this chipset, but the driver on gitorious should (or hopefully) work. But, patch and see if device time out disappears before trying 11n.

Well, that is pretty neat! After getting through a few hurdles including:
1. Familiarizing myself with the pfSense build process so that I could properly inject your patch,
2. Debugging the pfSense build process to actually get a LiveCD ISO created,
3. Figuring out an appropriate virtual networking configuration in VirtualBox to configure the VM,
it appears that your patch works like a charm! Thanks for getting back into this thread to help me out.

BTW, I was a bit embarrassed to find out that the link you provided me previously was only one page back in this thread. I actually did read this entire thread before posting but I think I was a bit intimidated by the details to leverage your previous discussions on my own. Thanks for holding my hand a bit on this one.

Also, now that I am pretty familiar with all the aspects of this puzzle, my offer still stands if you would like some assistance debugging the 11n features of your driver, perhaps against some specific configuration cases. You know a bit about my hardware setup but I don't mind compiling FreeBSD alpha/beta builds with non-standard configurations if you need the input. It's not going to be for my regular use though as I don't plan on migrating my operational hardware to FreeBSD 9.x/10.x until the next release of pfSense.

R/
wbedard

 

[wbedard]

Well, that is pretty neat! After getting through a few hurdles including
...
it appears that your patch works like a charm! Thanks for getting back into this thread to help me out.
...

Just a quick follow-up to confirm that an A-B comparison using VirtualBox VMs from both the release and patched pfSense ISOs show that your patch does correct the device timeout issue for my device/chipset. My next step is to verify the upgrade procedures within the "release" VM work as expected before upgrading my production hardware.

R/
wbedard

 

[PseudoCylon]

Just a quick follow-up to confirm that an A-B comparison using VirtualBox VMs from both the release and patched pfSense ISOs show that your patch does correct the device timeout issue for my device/chipset.

That's good to know.

For 11n support, you are more than welcome to try the driver at gitorious and report any problem. So far, I have figured out what registers to poke, but BBPs. There are 3 different versions (Linux, Ralink, and OpenBSD) of drivers, and they are slightly different each other. I do not know which one is correct. If you know anything about BBPs, please let me know.

 

[wbedard]

Just a quick follow-up to confirm that an A-B comparison using VirtualBox VMs from both the release and patched pfSense ISOs show that your patch does correct the device timeout issue for my device/chipset. My next step is to verify the upgrade procedures within the "release" VM work as expected before upgrading my production hardware.

As much as I hate to say it, I'd like to backup and re-visit the effectiveness of the patch you provided earlier in this thread. In spite of my earlier testing, once I upgraded the kernel on my production hardware, I saw device timeouts on the Alfa devices almost immediately. Assuming that I had simply copied over the wrong kernel, I went back to my stock and patched ISO virtual machines to confirm not only their configuration but also the results I previously, if optimistically and perhaps hastily, posted.

After conducted some more extended testing, it does appear that the patch you specified earlier doesn't eliminate the device timeout issue. While my earlier testing did not show any timeouts, subsequent testing using the same procedures did. Would you be willing to follow-up on this issue by providing me some troubleshooting or debugging steps that I could use to help you understand what might be different about this device/chipset from the ones you have previously worked with?

As always, I do greatly appreciate your time and effort in supporting your users!

R/
wbedard

 

[PseudoCylon]

If you have compiled the kernel or the driver with USB_DEBUG option, the following will print out some debug information. # sysctil hw.usb.run.debug=1

You could try un-comment the following line at or around line 683 in if_run.c, though it might cause LOR. (The LOR was fixed in 9.0-RELEASE.)

ic->ic_updateslot = run_updateslot;

Also, background scan tends to cause the timeout. Make sure turn it off (default is off). And, put the USB cable away from the power line or other higher voltage cables, just in case.

 

[wbedard]

As much as I hate to say it, I'd like to backup and re-visit the effectiveness of the patch you provided earlier in this thread. In spite of my earlier testing, ...

While going back through my procedures, I think that I may have never actually applied your patch properly and my earlier success was more a case of good luck/timing. I'm currently rebuilding my patched pfSense ISO, this time having confirmed that the patch was applied during the build process, and I hope to have additional test results tomorrow. Thank for your patience as I continue to learn some of the "best practices" surrounding building FreeBSD.

R/
wbedard

 

[wbedard]

If you have compiled the kernel or the driver with USB_DEBUG option, the following will print out some debug information. # sysctil hw.usb.run.debug=1

You could try un-comment the following line at or around line 683 in if_run.c, though it might cause LOR. (The LOR was fixed in 9.0-RELEASE.)

ic->ic_updateslot = run_updateslot;

Also, background scan tends to cause the timeout. Make sure turn it off (default is off). And, put the USB cable away from the power line or other higher voltage cables, just in case.

Sorry for the delay in following up on your suggestions...life got a bit busy for a couple of weeks. However, I am back on the case and have some feedback for you. First, I have confirmed at multiple points in the FreeBSD build process that your patch is now being applied and making it into the LiveCD ISO that I am running under VirtualBox. Unfortunately, I can also confirm this since I have been unable to successfully connect to this patched VM. However, I did enable the debugging and have posted the output at various stages to Pastebin, as follows:

1. dmesg output after attaching device to VM (Dmesg_Attach_Device_w_Debugging_On)
2. dmesg output after creating the interface (Dmesg_Create_Interface_w_Debugging_On)
3. ifconfig verbose output for created run0 interface (Ifconfig_Verbose_run0_Interface)
4. dmesg output while attempting to connect from client (Dmesg_Attempt_Connection_w_Debugging_On)

While I have attempted to collect and provide all information available, please do not hesitate to ask if there's anything else you would like to see. In item "4" above, only the last line appears when I attempt a connection (run_do_request...) and the other line are only provided as context up to the connection attempt. Additionally, please note that on line 28 in item "3" above, background scanning does appear to be off.

Thanks again for your assistance in helping me troubleshoot this issue. Again, my apologies for dropping out of the thread previously without warning.

R/
wbedard

 

[PseudoCylon]

Actually,

run0: device timeout

and

run_do_request: Control request failed, USB_ERR_TIMEOUT (retrying)

are 2 different error.

I could not see any run0: device timeout in the attached output. In other words, the deceive should have been working when you got the output, I believe. The device needs to be kept running until run0: device timeout shows up.

I think the device attached to pfSense runs in HOSTAP mode. Does one with VirtualBox also run in HOSTAP mode? There is a tricky part in HOSTAP mode.