Notices

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.

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.

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
(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
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

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.

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

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.

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

yep, because of stability issues. power users can always remove that sudo, because they know, what they are doing

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).

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