[ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.2 in extras] - Page 14 - maemo.org

mr_pingu | # 131 | 2011-06-18, 22:18 | Report

The funny part is I never installed the modified osso-wlan and also never encountered that bug. I often drive away from home without killing my connection first and wlan never got stuck.

Well I made today a simple script and put in bin which does nothing more than linking load.sh to a command wlanload and wlanunload. Maybe an idea to include for this applet too, so that we can load and unload the drivers with a simple command. Note: Not worth sharing, my n900 is my first linux device so my scripting skillz are way below yours. Just wanted to tell that it could be a nice addition since when we gonna use these drivers we probably need xterm anyway. The only GUI I know for aircrack-ng (faircrack) has already a button for loading the drivers...

laasonen | # 132 | 2011-06-18, 22:19 | Report

Originally Posted by pierrem View Post

then I have the stock osso-wlan, but from what Estel wrote, it does not seem to be the problem
What kind of "debug info" would you need ?

You could try, if this fixes the problem:

Code:

stop wlancond
start wlancond
ifconfig wlan0 up

Check, if the modules are loaded:

Code:

cat /proc/modules | grep wl

And does the problem occur with both drivers? If possible could you try another wireless access point.

Originally Posted by mr_pingu View Post

Well I made today a simple script and put in bin which does nothing more than linking load.sh to a command wlanload and wlanunload. Maybe an idea to include for this applet too, so that we can load and unload the drivers with a simple command.

This works already

Code:

user ~ load-bleeding-edge-drivers.sh
user ~ load-stock-drivers.sh
user ~ unload-drivers.sh

Last edited by laasonen; 2011-06-18 at 22:25.

mr_pingu | # 133 | 2011-06-18, 22:45 | Report

Awesome, but when loading bleeding edge through applet and load the stock through xterm the button stays glowed.

I don't know but the code to unglow it should be included in load-stock-drivers.sh.

Well, should sounds maybe a bit commanding, but I don't mean it that way. I mean this post as feedback and help to improve this easy applet

laasonen | # 134 | 2011-06-18, 22:50 | Report

Originally Posted by mr_pingu View Post

Awesome, but when loading bleeding edge through applet and load the stock through xterm the button stays glowed.

I don't know but the code to unglow it should be included in load-stock-drivers.sh.

Well, should sounds maybe a bit commanding, but I don't mean it that way. I mean this post as feedback and help to improve this easy applet

I didn't plan those scripts to be used without the applet, but they work as good as any other external enabler/disabler. Even thought I would make those scripts manually toggle the button, it would get unsynchronized when someone changes drivers with faircrack for example. So I would need to poll the loaded drivers, which would increase CPU usage, what I don't want to do. Orientation lock applet has the same problem.

Last edited by laasonen; 2011-06-18 at 22:54.

The Following 2 Users Say Thank You to laasonen For This Useful Post:
Estel, mr_pingu

pierrem | # 135 | 2011-06-18, 22:54 | Report

Originally Posted by laasonen View Post

You could try, if this fixes the problem:

Code:

stop wlancond
start wlancond
ifconfig wlan0 up

nope

Originally Posted by

Check, if the modules are loaded:

Code:

cat /proc/modules | grep wl

they are

Originally Posted by

And does the problem occur with both drivers?

yes

Originally Posted by

If possible could you try another wireless access point.

not possible right now: I'll try later

Estel | # 136 | 2011-06-18, 23:19 | Report

Originally Posted by pierrem View Post

What kind of "debug info" would you need ?

Good point - I'm by no means expert on this, so i can't give You straight instructions, but I'm sure that somewhere must be command to watch (kernel?) messages, just like dmesg in HEN. I hope some "pros" will show up here and point You toward right direction... If You get "connection error", it's most unlikely that linux distribution doesn't store somewhere info what part failed, or at least allow checking output messages in real time.

I'm sorry that i can't be much more help here

// Edit

Did quick research, and:

dmesg

run as root indeed provide some info about connection stages. Just be sure to execute it AFTER failed attempt - it's not updating in real time, so when run, it show you messages to the moment that it was executed. to update, need to run it again.

My output look like this:
unloading stock drivers:

[86817.312927] wl1251: down
[86817.844177] wl1251: 151 tx blocks at 0x3b788, 35 rx blocks at 0x3a780
[86817.859802] wl1251: firmware booted (Rev 4.0.4.3.7)
[86818.000915] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[86818.117736] wl1251: down
[86818.281677] wl1251: unloaded

loading stock drivers:

[87210.910308] cfg80211: Using static regulatory domain info
[87210.910339] cfg80211: Regulatory domain: US
[87210.910339] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[87210.910369] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[87210.910369] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910369] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910400] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910400] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910400] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[87210.910430] cfg80211: Regulatory domain changed to country: US
[87210.910430] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[87210.910461] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[87210.910461] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910461] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910491] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910491] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[87210.910491] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[87210.991912] phy0: Selected rate control algorithm 'minstrel'
[87210.996551] wl1251: loaded
[87210.996948] wl1251: initialized
[87212.227020] wl12xx spi4.0: firmware: requesting wl1251-fw.bin
[87212.474731] wl12xx spi4.0: firmware: requesting wl1251-nvs.bin
[87213.086425] wl1251: 151 tx blocks at 0x3b788, 35 rx blocks at 0x3a780
[87213.102020] wl1251: firmware booted (Rev 4.0.4.3.7)
[87213.203887] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[87214.766113] wl1251: down
[87216.930847] wl1251: 151 tx blocks at 0x3b788, 35 rx blocks at 0x3a780
[87216.931488] wl1251: firmware booted (Rev 4.0.4.3.7)
[87217.032012] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[87218.016052] wlan0: authenticate with AP 00:18:39:ce:dc:5a
[87218.018829] wlan0: authenticated
[87218.018859] wlan0: associate with AP 00:18:39:ce:dc:5a
[87218.022552] wlan0: RX AssocResp from 00:18:39:ce:dc:5a (capab=0x431 status=0 aid=2)
[87218.022583] wlan0: associated
[87218.113250] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

---

That's output from loading drivers and associating with my WPA2 hidden network, so same setup as Yours. Check please. if Your output isn't kicking out any errors, or missing any part. Or even better, paste it here?

Sorry in advance if dmsg output is irrelevant for fixing this problem - as i said, I'm no way an expert here.

Last edited by Estel; 2011-06-18 at 23:37.

Estel | # 137 | 2011-06-19, 00:29 | Report

I think i was able to reproduce (or semi-reproduce) the problem. After messing up for some time with loading and reloading drivers via selector applet, sudden of nothing I'm not able anymore to connect into my network. Steps are exactly like pierrem reported, with exception that after some time of wifi-status icon flashing, I got message:

"Error connection to Internet: could not receive IP address from server. Try again?" (I get communicate in my language, so translation may be not accurate to the letter - of course trying again don't help)

From that point, nor bleeding edge or stock drivers are able to connect me.

dmesg print output as usual, stating that i was authenticated with AP - so it's likely really part with negotiating IP from DHCP that fail.

Strange thing is that other computers in my network doesn't have this issue, and if i reboot N900, initial connection to Wifi work. Ho ever, if i use applet to disable and enable wifi, I'm not able to connect anymore. What on earth?

I'll check if wifi-switcher work (uinstaled it already), and update my findings soon.

Anyway, could it be that way selector applet unload and load drivers screw something badly with configuration? I double checked settings and disabled/enabled again auto obtaining IP from dhcp. Will check if static IP work.

The most FRUSTRATING part is that i have absolutely no idea what i did to "trigger" this error, and now I'm unable to get rid of it

Prior to that point, i was using selector applet to enable and disable my wifi quite often, sometimes even load bleeding edge - without ANY troubles. for worst-case scenario i got backup, but I'm really curious to find source of problems...

// Edit 1
Reinstalling selector applet doesn't help. I checked from my router side, and its true that my N900 is "connected" - can see client and signal quality via tomato firmware, ho ever IP is not obtained. the strange thing is that MAC reported to router is different than my usual N900 MAC?

I got static dhcp rule that always worked, now i see that connection attempt is made with totally different MAC. Still, I'm sure that it's me trying to connect. and keep in mind that we're talking about stock drivers attempts.

I wonder if that can be a clue to our problem - anyway, keep in mind that i DON'T have MAC filter set on my router, so it can't be direct source of problems. Will investigate further.

// Edit 2

Just small update - at every attempt to connect again via prompt asking me if i want to try again, MAC reported to router is the same. ho ever, if i shut down wifi via selector, and re-enable it again, mac changes to another fresh one. Also, first 3 portions of max adress (parts between ":" ) are the same, only last 3 parts are different.

IDK if this is normal behaviour for wifi connection in stage of negotiating IP address (or any post-wpa2 authentication), so this may be totally irrelevant info. If so, correct me.

With bleeding edge drivers situation is the same - constant N900 MAC reported to router when i re-apply attempts to connect, but switching drivers on and off result in MAC that have 3 last portions different. Still don't know if this info is valuable, i hope so...

Last edited by Estel; 2011-06-19 at 01:06.

Pyro1099 | # 138 | 2011-06-19, 00:29 | Report

Originally Posted by laasonen View Post

What theme are you using? All my three themes show clearly, if its toggled.

Just the Humanity theme.

laasonen | # 139 | 2011-06-19, 01:00 | Report

Originally Posted by Estel View Post

mac changes to another fresh one. Also, first 3 portions of max adress (parts between

are the same, only last 3 parts are different.

0.1.x versions first saved the mac-address and then recovered it after loading the drivers, but now that you can disable them completely, its not possible easily. If thats the problem, I could save the mac-address to some file and recover it from there.

Originally Posted by Pyro1099 View Post

Just the Humanity theme.

Installed the Humanity Theme 0.6. Looks pretty clear to me.

Last edited by laasonen; 2011-06-19 at 01:08.

Estel | # 140 | 2011-06-19, 01:04 | Report

It would be great, cause this way static DHCP service (i.e. port forwarding, etc) can work as it should. Other way, You must re-define open ports (for torrent client on N900, as example from top of my head) every time You disable/enable Your wifi on N900.

Anyway, if i set IP address manually, I'm connected without any problems using selector applet. With DHCP, it doesn't work - just the moment i check "obtain IP automatically" and maemo re-enable connection (after settings were saved) I'm not able to connect anymore. I'm most confused...

Now, I'm almost sure that this bug isn't related directly to selector applet, but something with maemo connectivity or routers behaviour - still, somehow this bug is triggered by usage of selector applet.

// Edit

May it be (copyright enya

) that so many changes of MAC and connection attempts make routers deny leasing IP addresses to DHCP anymore? Full DHCP pool or something? I doubt, cause if so, why i connect without problems after reboot... (I mean the first, initial connection done by maemo. Still, further connection attempt done by maemo after enabling DHCP IP fail - really, what the hell is going on?

)

Last edited by Estel; 2011-06-19 at 01:23.