Skip to contentSkip to conversation

Disable pnat-server

DISCUSSION Nils Faerber 2 participants 7 messages Jul 3, 2011 Bluetooth drivers

lore
Share & tools
lore
#0 lore raw

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

Signature · 4 lines
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen             Mob: +49-176-21024535
http://www.kernelconcepts.de
#1 lore raw

Hi Nils,

Quoted 6 lines · Nils Faerber

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:

Quoted 7 lines
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.

Quoted 4 lines

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

#2 lore raw

Am 03.07.2011 20:04, schrieb Johan Hedberg:

Quoted 1 line

Hi Nils,

Hi Johan!

Quoted 15 lines · Nils Faerber
Quoted 6 lines

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:

Quoted 7 lines
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.

Quoted 5 lines

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?

Quoted 4 lines

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.

Quoted 6 lines
Quoted 4 lines

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

Quoted 1 line

Johan

Cheers
nils

Signature · 4 lines
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen             Mob: +49-176-21024535
http://www.kernelconcepts.de
#3 lore raw
Quoted 8 lines · Nils Faerber
Quoted 5 lines

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

Quoted 7 lines
Quoted 4 lines

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?

Quoted 7 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 8 lines

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

#4 lore raw

Am 03.07.2011 21:06, schrieb Johan Hedberg:

Quoted 11 lines · Nils Faerber
Quoted 8 lines
Quoted 5 lines

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.

Quoted 10 lines
Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

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!

Quoted 1 line

Johan

Cheers
nils

Signature · 4 lines
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen             Mob: +49-176-21024535
http://www.kernelconcepts.de
#5 lore raw
Quoted 7 lines · Nils Faerber
Quoted 2 lines

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

Quoted 1 line

Tried that and now my device works again - yippie!

Good to hear! :)

Johan

#6 lore raw

Am 03.07.2011 22:13, schrieb Johan Hedberg:

Quoted 9 lines · Nils Faerber
Quoted 7 lines
Quoted 2 lines

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.

Quoted 8 lines

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.

Quoted 2 lines
Quoted 1 line

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!

Quoted 1 line

Johan

Cheers
nils

Signature · 4 lines
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen             Mob: +49-176-21024535
http://www.kernelconcepts.de