![]() |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
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... |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
Quote:
Code:
stop wlancond Code:
cat /proc/modules | grep wl Quote:
Code:
user ~ load-bleeding-edge-drivers.sh |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
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 ;) |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
Quote:
|
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
Quote:
Quote:
Quote:
Quote:
|
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
Quote:
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. |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
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? :confused: 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? :confused: 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... |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers [0.2.0]
Quote:
|
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
Quote:
Quote:
http://hosted.laasonen.net/attachment-0MHYWV.png |
Re: [ANNOUNCE] Wlan Driver Selector Applet - Switch easily between stock and bleeding edge drivers and shut down WLAN complitely [0.2.1]
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?:confused:) |
All times are GMT. The time now is 12:16. |
vBulletin® Version 3.8.8