Could You check, if during "fake" disconnect (when You don't hear anything from bluetooth headset, but it's shown as connected), the other party hears You? i.e., call someone (or Yourself via second phone), and check if 2nd device "hears" what You speak to bluetooth headset microphone.

If yes, it would prove that (most likely) origins of both problems are same.

/Estel

i investigated further:
- it only happens with my se mw600, the se vh410 (or a slightly older modell) works completely flawlessly - are they using different profiles? (btw listening to music is flawless)

- it happens with power-kernel v50 AND the standard omap of pr1.3

- it was better with kp v49; but i reflashed between using v49/50, so i cant really tell

- sometimes it starts stuttering and stops transferring audio/voice, sometimes it does it without stuttering; the headset stays connected for a few seconds and then disconnects

any idea what can cause the problem?
and i will try kp v49, wether it is kernel-related or just another program.

testing with kp v49 is done:
there were NO connection problems, phoning went fine

is there maybe something that kpv50 and stock have in common, what v49 does not?

yeah, there is, all the kernels between 46 and 49 have a patch for BT mice, which have been applied to all devices. Unfortunately it was causing troubles to many BT headset devices, so in KP50 it was restricted to HID devices only. For all other types of devices KP50 behaves just like stock. Now it turns out that this patch is needed for BT devices too, but I just cannot imagine how we are supposed to recognize for which devices it should be applied and for which not . You may try bt-compat drivers, there is just nothing that could be done in KP AIUI

Maybe some ugly solution about sysfs entry, where few affected ones could write vendor PIDs? I mean, that mice path would be enabled for HID by default, and also for devices matching ID's from sysfs entry/config file...

Ugly, but should work and - as far as my miserably limited developing knowledge goes - it shouldn't be too troublesome to actually code.

/Estel

// Edit

Or even more simple solution - sysfs entry to turn on and off mice patch (still, used by default for HID). I doubt that anyone is using conflicting and non-conflicting headset at the same time (literally, both connected at the same time)?

is there any solution for the problem with the bluetooth-patch? because as soon as the kp v50 goes to extras-stable, there is no "easy" (no self-compiling, searching special packages etc.) way to install a kernel which can handle specific bt-headsets. (e.g. se mw600)

so:
is there the possibility to include an sysfs entry (as estel suggested) to turn on/off the patch? so that everybody using an headset which needs that patch isn't stuck with the v49.

thanks in advance!

Pali, can you check that your injection driver load script works for KP51, because I cannot get it to do anything other than tell me when I am not root.

I think there is a problem in your case statement, where you do all the loading / unloading etc. I have KP51, but do not have bash.

To check for injection driver being loaded I use the following Which just tells me that the standard drivers are loaded (wl12xx), no matter how often I run your script using sudo or as root.

Thanks

Edit: Attached script that works for me. Just rename and delete the .txt at the end of the filename.

So did you tried it to run as root? Open X-Term and run:
sudo gainroot

Also, try to run:
id -u

I ran it as root using sudo su, which gives me a result for id -u of zero , (ie. your script would complain if I am not root.). The script istelf is in /home/user with chmod 755 access rights and run using ./script.sh from that directory.

@pali
A small packaging question
Is there a special reason for placing modules right in /opt (e.g /opt/packet-injection-modules/kernel_name_here) instead of e.g. /opt/lib/modules/kernel_name_here/packet-injection (which more suits standard packaging and placing rules)?