Notices


Reply
Thread Tools
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#241
Just FYI, I keep noticing this problem in the last 10 or so versions that hit extras-devel:

The included-in-power-kernel paths to the injection-capable wifi driver modules is:
/opt/packet-injection-modules/`uname -r`/compat.ko
/opt/packet-injection-modules/`uname -r`/mac80211.ko
/opt/packet-injection-modules/`uname -r`/cfg80211.ko
/opt/packet-injection-modules/`uname -r`/rfkill_backport.ko
/opt/packet-injection-modules/`uname -r`/wl1251.ko
/opt/packet-injection-modules/`uname -r`/wl1251_spi.ko

Note that the .ko files are all in that same directory - not in a bunch of different sub-directories, as was/is the case for the backport-modules package. Your latest (well, I last updated about 6 hours ago) version in -devel contained a very neat* script to get the 'correct' file path to the modules, but it would still fail on a device with kernel power 51 without a redundant install of backport-modules, because your wlan-load1.sh script still contains all the subdirectories that applied only to the backport-modules package.

*But honestly, I think the get_wlan_path.sh script should at least be reordered. (And either way you'd have to change your approach, based on the above information, if you wanted to find the directory dynamically.) This is because with power-kernel v51, there's going to never be a need for backport-modules package, so once kernel-power v51 or some stable consequent version there-of makes it to extras, you won't need to keep checking for backport-modules' paths to the modules. Only very odd, unusual setups will exist that could possibly contain injection drivers at the backport-modules paths, without also containing them at the kernel-power 51+ paths. So the logical thing would be to put the check for the kernel-power 51+ paths first, and then only if that path's not found, check in the backport-modules path. The way you have it now, every time you go to load the drivers, it'll check the less-likely-to-be-widely-used-in-the-future backport-modules path, and only then check the built-in-to-kernel-power path.

Not saying you need to fix this now - devel is devel for a reason and I'm happy to tweak the shell scripts myself into working order every time an update happens, but I presume it's something you'd want to fix for when you push it down to extras-testing/extras.
 

The Following User Says Thank You to Mentalist Traceur For This Useful Post:
Posts: 141 | Thanked: 313 times | Joined on May 2012 @ Czech Republic
#242
I have problem with AIS when bluetoothd is restarted (manually or some crash it doesn't matter). The AIS is unusable for bluetooth in that case till next rebooot. I don't take a look into the code but it seems like AIS doesn't count with bluetoothd restart (change dbus path - as pid is part of the path).

Steps to reproduce:
AIS - BT on
in cmd: stop bluetoothd; start bluetoothd
AIS - change BT - no effect

Can it be fixed?
 

The Following 2 Users Say Thank You to luf For This Useful Post:
Posts: 462 | Thanked: 550 times | Joined on Sep 2008 @ Moscow
#243
Originally Posted by luf View Post
I have problem with AIS when bluetoothd is restarted (manually or some crash it doesn't matter). The AIS is unusable for bluetooth in that case till next rebooot. I don't take a look into the code but it seems like AIS doesn't count with bluetoothd restart (change dbus path - as pid is part of the path).

Steps to reproduce:
AIS - BT on
in cmd: stop bluetoothd; start bluetoothd
AIS - change BT - no effect

Can it be fixed?
i'll take a look tomorrow, it seemed to me following name owner change.
 

The Following 3 Users Say Thank You to 412b For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#244
Since last update, I got strange problems with AIS. The thing is, that I've used post-load0 script to set iw reg set JP, and post-up script to change mac address (via macchanger).

lately, I noticed that MAC fails to change (which result in AP assigning wrong IP to my device via DHCP, as it server static leases, based on MAC). I decided to run AIS scripts manually, to see output. Here are the results:

/usr/bin/advifsw/wlan_load0.sh
Code:
ifconfig: wlan0: error fetching interface information: Device not found
libwl1251: netlink family ID is 53
wl1251-cal: Country code: 260
wl1251-cal: Got CAL NVS
wl1251-cal: found MAC address xx:xx:xx:xx:xx:xx
wl1251-cal: netlink family id 52
wl1251-cal: ack_handler()
(mac was replaced by me, manually, it's shown correctly in output)
After this, pop-up for selecting network I want to connect appears, despite fact, that /usr/bin/advifsw/wlan_up.sh wasn't called yet! If I invoke it manually, then...

/usr/bin/advifsw/wlan_up.sh
Code:
start: Job not changed: wlancond
Current MAC: ec:9b:5b:fd:82:37 (unknown)
ERROR: Can't change MAC: interface up or not permission: Device or resource busy
So, it seems again, that interface got up after loading modules, and wlan-up.sh script just tries to repeat, what was already done. This result in failure to change MAC, as interface was up, already.
---

What is strange here - sometimes, it just works (MAC get changed). Thinking about it, I remember, that macchanger got updated some time ago, too - maybe something is wrong with new version?
Edit: Or it wasn't - after checking package interface, it seems that I'm wrong here - macchanger wasn't updated since late 2011, so my memory must be making tricks on me /Edit

But, no mater of macchanger state, there seems to be something wrong with AIS too (interface up, before calling wlan-up.sh), so I'm reporting it here, nevertheless.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!

Last edited by Estel; 2012-10-21 at 15:57.
 
Posts: 462 | Thanked: 550 times | Joined on Sep 2008 @ Moscow
#245
Estel,
try changing change "sudo stop wlancond" to "stop wlancond" in /usr/bin/advifsw/wlan_down.sh
stopping wlancond is quite unstable thing in Fremantle (especially when Modest updating or other data exchange) at least for my device leading it to "spontanious" reboots every 1/4 attempts.
 

The Following User Says Thank You to 412b For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#246
Thanks a lot 412b, after proceeding as You've suggested, everything (literally) works fine.

FIY, I did extensive tests, and without removing "sudo", wlancond *never*stopped, so, both this line, and one responsible for enabling it again later, were not working. You may see it worthwile, to fix this in new version.

Interestingly, no matter how much I've messed with stopping and starting wlancond, I wasn't able to reproduce bug with spontaneous reboots.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following User Says Thank You to Estel For This Useful Post:
peterleinchen's Avatar
Posts: 4,117 | Thanked: 8,901 times | Joined on Aug 2010 @ Ruhrgebiet, Germany
#247
So, was this sudo on purpose (avoiding that stop worked? Or bug? callng sudo as root never works ).
I can confirm 412b's saying "wlancond stopping causes spontaneous reboot" from earlier tests, iirc. Right now I just tested once and it worked.
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!

Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257

editsignature, http://talk.maemo.org/profile.php?do=editsignature
 

The Following User Says Thank You to peterleinchen For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#248
I testes it ~40 times in row (sic! [including lockdown timer]) and it never rebooted. cssu-thumb and kernel-power here (kernel isn't related, probably).

The most I was able to reproduce, were "spawning too fast" or something like that, which deny starting wlancond again, until certain time passes. Highly unlikely to happen in real-life situations, though - to get it, one need to *really* spam stopping and starting wlancond.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Posts: 462 | Thanked: 550 times | Joined on Sep 2008 @ Moscow
#249
Originally Posted by peterleinchen View Post
avoiding that stop worked
yep, because of stability issues. power users can always remove that sudo, because they know, what they are doing

Originally Posted by Estel View Post
I testes it ~40 times in row (sic! [including lockdown timer]) and it never rebooted. cssu-thumb and kernel-power here (kernel isn't related, probably).

The most I was able to reproduce, were "spawning too fast" or something like that, which deny starting wlancond again, until certain time passes. Highly unlikely to happen in real-life situations, though - to get it, one need to *really* spam stopping and starting wlancond.

/Estel
my scenario's steps are:
1. turn wlan off
2. open modest with autoupdates turned on
3. turn wlan on, connect to network
4. update modest manually
5. turn wlan off
6. lock device (additional step, which is not always necessary)
7. kaboom

the alternative scenarion is using im accounts:
0. availability is turned on, wlan is off
1. turn wlan on, connect to network
2. accounts started connecting/all connected
3. turn wlan off
4. lock device (additional step, which is not always necessary)
5. kaboom

it happens with different kernels (kp mostly), cssu (-testing and -thumb).
 

The Following 2 Users Say Thank You to 412b For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#250
Hm, I'm still unable to reproduce, I wonder what triggers this bug...

But, if it's not directly kernel-related, it sound serious - userland bits, like wlancond, shouldn't be able to kaboom device like that. Maybe it's worth reporting to cssu's one-man-bug-hunting-army? (freemangordon)

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 10:10.