Hello!
I have developed a small app which registers its own RFCOMM based
service and service ID using libbluetooth and the SDP services. This
worked great until some recent Ubuntu update which upgraded the
Bluetooth services (I guess).
Now I get an error in syslog whenever my device tries to connect:
Jul 3 17:23:13 tlb bluetoothd[27590]: Unable to spawn pnatd: Failed to
execute child process "/usr/bin/phonet-at" (No such file or directory)
It took me quite some time to figure out that this is part of the (new?)
bluetoothd plugin system which is pitily not documented anywhere -
especially not which plugins there are, what they do and how they can be
en- or disabled.
After some more searching and reading sources I found that plugins can
theoretically be disabled in bluetoothd's config file main.conf. So I added
DisablePlugins = pnat-server
there but still bluetoothd tries to spawn pnatd upon incoming connection!?
This is pretty annoying.
Additionally I really wonder if this is a reasonable default for a PC?
Which PC has an AT command device that it would want to export over
Bluetooth? A mobile, yes, maybe, but on a PC?
And even then, there is no appropriate pnatd application coming with the
Bluetooth BlueZ package so this default does not even work. I would
therefor strongly suggest to disable pnatd by default and only enable it
where it is actually needed.
So, how can I get rid of this pnatd pseudo service so that my service
will work again?
PS: If you wonder what my service is about it is a small app for the
SonyEricsson LiveView mobile display device...
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
Am 03.07.2011 22:13, schrieb Johan Hedberg:
> On Sun, Jul 03, 2011, Nils Faerber wrote:
>>> Hmm? So they don't use SDP do discover the RFCOMM channel but directly
>>> connect to channel 1?
>>
>> Um...well I just checked that code.
>> What the device does it look for the service name on the host and on the
>> host side it is bound to channel 1 - I think. I borrowed that part of my
>> code from some old BlueZ code, forgot which.
>
> So, the SDP service record is there so profiles can look up e.g. the
> RFCOMM channel based on the profile UUID. If that's what the remote
> device is doing you should be able to change the channel to something
> else than 1 in the service record and then bind your server socket to
> this new channel. However, if the remote side has a hard-coded channel
> value of 1 and doesn't care what SDP says then there's really nothing
> you can do (except make sure you don't have any other service on that
> channel, like you now did).
Looks like it is hardcoded, I just tried a different one and it fails.
>> Tried that and now my device works again - yippie!
> Good to hear! :)
At least I can now continue playing with it... eventually I'll release
my code once it reached a halfway usable state. Currently I still
struggle a little with the protocol implementation which would need a
state machine and I am still reluctant to implement one and wait for
another inspiration instead ;) But it seems it is not coming...
Thanks again!
> Johan
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
On Sun, Jul 03, 2011, Nils Faerber wrote:
> > Hmm? So they don't use SDP do discover the RFCOMM channel but directly
> > connect to channel 1?
>
> Um...well I just checked that code.
> What the device does it look for the service name on the host and on the
> host side it is bound to channel 1 - I think. I borrowed that part of my
> code from some old BlueZ code, forgot which.
So, the SDP service record is there so profiles can look up e.g. the
RFCOMM channel based on the profile UUID. If that's what the remote
device is doing you should be able to change the channel to something
else than 1 in the service record and then bind your server socket to
this new channel. However, if the remote side has a hard-coded channel
value of 1 and doesn't care what SDP says then there's really nothing
you can do (except make sure you don't have any other service on that
channel, like you now did).
> Tried that and now my device works again - yippie!
Good to hear! :)
Johan
Am 03.07.2011 21:06, schrieb Johan Hedberg:
> On Sun, Jul 03, 2011, Nils Faerber wrote:
>>> There should be absolutely no reason for Ubuntu have this plugin enabled
>>> or even compiled. You might wanna file a bug to them to disable it. The
>>> only place where it makes sense to be compiled is in Nokia's Maemo
>>> Harmattan platform. For everything else it should be disabled (as it is
>>> by default).
>>
>> Yes, indeed - I have not tried, what is the default when compiling the
>> BlueZ package, en- or disabled?
>
> It's disabled (grep for pnat_enable in acinclude.m4).
OK, then it would indeed be Ubuntu's fault.
>>> Btw, if you have your own RFCOMM based service you should take a look at
>>> doc/assigned-numbers.txt to be sure not to conflict with any of those
>>> services. The range of possible RFCOMM channels (1-31) is so small that
>>> it's easy to get conflicts.
>>
>> I was not the one to choose that ;)
>> It is for the Sony Ericsson LiveView and I have to use what they did.
>
> Hmm? So they don't use SDP do discover the RFCOMM channel but directly
> connect to channel 1?
Um...well I just checked that code.
What the device does it look for the service name on the host and on the
host side it is bound to channel 1 - I think. I borrowed that part of my
code from some old BlueZ code, forgot which.
>>>> After some more searching and reading sources I found that plugins can
>>>> theoretically be disabled in bluetoothd's config file main.conf. So I added
>>>>
>>>> DisablePlugins = pnat-server
>>>
>>> The plugin is called pnat, so that line should read DisablePlugins=pnat
>>
>> Sure?
Yes, you are ;)
Tried that and now my device works again - yippie!
Thanks for your quick help!
> Johan
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
On Sun, Jul 03, 2011, Nils Faerber wrote:
> > There should be absolutely no reason for Ubuntu have this plugin enabled
> > or even compiled. You might wanna file a bug to them to disable it. The
> > only place where it makes sense to be compiled is in Nokia's Maemo
> > Harmattan platform. For everything else it should be disabled (as it is
> > by default).
>
> Yes, indeed - I have not tried, what is the default when compiling the
> BlueZ package, en- or disabled?
It's disabled (grep for pnat_enable in acinclude.m4).
> > Btw, if you have your own RFCOMM based service you should take a look at
> > doc/assigned-numbers.txt to be sure not to conflict with any of those
> > services. The range of possible RFCOMM channels (1-31) is so small that
> > it's easy to get conflicts.
>
> I was not the one to choose that ;)
> It is for the Sony Ericsson LiveView and I have to use what they did.
Hmm? So they don't use SDP do discover the RFCOMM channel but directly
connect to channel 1?
> >> After some more searching and reading sources I found that plugins can
> >> theoretically be disabled in bluetoothd's config file main.conf. So I added
> >>
> >> DisablePlugins = pnat-server
> >
> > The plugin is called pnat, so that line should read DisablePlugins=pnat
>
> Sure?
> The pnat.c source sais:
>
> static struct btd_adapter_driver pnat_server = {
> .name = "pnat-server",
> .probe = pnat_probe,
> .remove = pnat_remove,
> };
That's the adapter driver name. I think the plugin name is still just
"pnat".
Johan
Am 03.07.2011 20:04, schrieb Johan Hedberg:
> Hi Nils,
Hi Johan!
> On Sun, Jul 03, 2011, Nils Faerber wrote:
>> I have developed a small app which registers its own RFCOMM based
>> service and service ID using libbluetooth and the SDP services. This
>> worked great until some recent Ubuntu update which upgraded the
>> Bluetooth services (I guess).
>> Now I get an error in syslog whenever my device tries to connect:
>>
>> Jul 3 17:23:13 tlb bluetoothd[27590]: Unable to spawn pnatd: Failed to
>> execute child process "/usr/bin/phonet-at" (No such file or directory)
>>
>> It took me quite some time to figure out that this is part of the (new?)
>> bluetoothd plugin system which is pitily not documented anywhere -
>> especially not which plugins there are, what they do and how they can be
>> en- or disabled.
>
> There should be absolutely no reason for Ubuntu have this plugin enabled
> or even compiled. You might wanna file a bug to them to disable it. The
> only place where it makes sense to be compiled is in Nokia's Maemo
> Harmattan platform. For everything else it should be disabled (as it is
> by default).
Yes, indeed - I have not tried, what is the default when compiling the
BlueZ package, en- or disabled?
> Btw, if you have your own RFCOMM based service you should take a look at
> doc/assigned-numbers.txt to be sure not to conflict with any of those
> services. The range of possible RFCOMM channels (1-31) is so small that
> it's easy to get conflicts.
I was not the one to choose that ;)
It is for the Sony Ericsson LiveView and I have to use what they did.
>> After some more searching and reading sources I found that plugins can
>> theoretically be disabled in bluetoothd's config file main.conf. So I added
>>
>> DisablePlugins = pnat-server
>
> The plugin is called pnat, so that line should read DisablePlugins=pnat
Sure?
The pnat.c source sais:
static struct btd_adapter_driver pnat_server = {
.name = "pnat-server",
.probe = pnat_probe,
.remove = pnat_remove,
};
I'll retry with pnat again ;)
> Johan
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
Hi Nils,
On Sun, Jul 03, 2011, Nils Faerber wrote:
> I have developed a small app which registers its own RFCOMM based
> service and service ID using libbluetooth and the SDP services. This
> worked great until some recent Ubuntu update which upgraded the
> Bluetooth services (I guess).
> Now I get an error in syslog whenever my device tries to connect:
>
> Jul 3 17:23:13 tlb bluetoothd[27590]: Unable to spawn pnatd: Failed to
> execute child process "/usr/bin/phonet-at" (No such file or directory)
>
> It took me quite some time to figure out that this is part of the (new?)
> bluetoothd plugin system which is pitily not documented anywhere -
> especially not which plugins there are, what they do and how they can be
> en- or disabled.
There should be absolutely no reason for Ubuntu have this plugin enabled
or even compiled. You might wanna file a bug to them to disable it. The
only place where it makes sense to be compiled is in Nokia's Maemo
Harmattan platform. For everything else it should be disabled (as it is
by default).
Btw, if you have your own RFCOMM based service you should take a look at
doc/assigned-numbers.txt to be sure not to conflict with any of those
services. The range of possible RFCOMM channels (1-31) is so small that
it's easy to get conflicts.
> After some more searching and reading sources I found that plugins can
> theoretically be disabled in bluetoothd's config file main.conf. So I added
>
> DisablePlugins = pnat-server
The plugin is called pnat, so that line should read DisablePlugins=pnat
Johan