I cherry-picked Blueman change (linux.sysfs_path setting for rfcomm hal
device) - I presume, this will land into your system with Blueman 1.1
package.
Anyway, there is one more problem with Network-manager itself... now it
needs also udev attribute telling whether the modem is GSM or CDMA. To
workaround this I've created udev rule like this:
It might be challenging to get rock solid rule, which will use the
already in Blueman selected correct modem type (GSM/CDMA) and based on
that set the appropriate udev ID_NM_..... The DEVPATH/address file
could be inspected to get the MAC of the device and then check which
type it should be set reading Blueman Config. Unfortunatelly I'm not
familiar with Python to prepare this patch...
The other way might be to patch the network manager itself to rely on
the hal modem properties when the udev ones are not set at all (and if
the modem is connected via rfcomm).
I cherry-picked Blueman change (linux.sysfs_path setting for rfcomm hal
device) - I presume, this will land into your system with Blueman 1.1
package.
Anyway, there is one more problem with Network-manager itself... now it
needs also udev attribute telling whether the modem is GSM or CDMA. To
workaround this I've created udev rule like this:
$cat /etc/udev/ rules.d/ 33-rfcomm- nm.rules ="*/rfcomm* ", ENV{ID_ NM_MODEM_ GSM}="1"
ACTION=="move", DEVPATH=
It might be challenging to get rock solid rule, which will use the
already in Blueman selected correct modem type (GSM/CDMA) and based on
that set the appropriate udev ID_NM_..... The DEVPATH/address file
could be inspected to get the MAC of the device and then check which
type it should be set reading Blueman Config. Unfortunatelly I'm not
familiar with Python to prepare this patch...
The other way might be to patch the network manager itself to rely on
the hal modem properties when the udev ones are not set at all (and if
the modem is connected via rfcomm).