2011-08-12 23:23:29

by Isaiah Sarju

[permalink] [raw]
Subject: RFCOMM channel 1 behavior differences

Hello,

Does Ubuntu, linux kernel 2.6.38.10, running bluez 4.91-0ubuntu1 have a
special security policy for incoming rfcomm connections on channel 1,
and not other channels?

I ask this because I can create rfcomm connections between two computers
on other channels (2, 3, 11, 13, etc.) but the listening computer
refuses connections when connection requests come in for channel 1.

I use the following commands:

on listening computer:
sudo rfcomm listen hci0 <channel>

on connecting computer:
sudo rfcomm connect hci0 <BD_ADDR> <channel>

When <channel> does not equal 1 both computers connect no with no
problem. When <channel> equals 1 I receive the error "Can't connect
RFCOMM socket: Connection refused"

I tried this in to two different environments. 1) in a X-session and 2)
in command line

1) in GUI on the listing computer a dialogue box pops up requesting a
pin for pairing. When I click cancel on the dialogue box of the
listening machine the error "Can't connect RFCOMM socket: Connection
refused" appears on the command line of the connecting machine.

2) in command line mode on the listening computer nothing appears and I
immediately receive the error "Can't connect RFCOMM socket: Connection
refused" on in the command line of the connecting machine

These problems do not arise when attempting to connect on any other
channels.

I have searched Google, looked at multiple forum posts on rfcomm
connections, looked at forum posts on peoples' problems with rfcomm
connections, reviewed this mailing list's archives, and I cannot find my
specific problem.

Thank you for any advice you can provide or resources to which you can
point me.

Regards,
Isaiah


2011-08-13 21:15:07

by Isaiah Sarju

[permalink] [raw]
Subject: Re: RFCOMM channel 1 behavior differences

On 8/13/11 4:26 AM, Johan Hedberg wrote:
> Hi,
>
> On Fri, Aug 12, 2011, Vinicius Costa Gomes wrote:
>> On 19:23 Fri 12 Aug, Isaiah Sarju wrote:
>>> Hello,
>>>
>>> Does Ubuntu, linux kernel 2.6.38.10, running bluez 4.91-0ubuntu1
>>> have a special security policy for incoming rfcomm connections on
>>> channel 1, and not other channels?
>>>
>>
>> Most probably this is caused by a problem in how Ubuntu packages
>> BlueZ.
>>
>> Could you try this: edit /etc/bluetooth/main.conf and add "pnat-server"
>> to the DisabledPlugins field (perhaps you will need to uncomment that
>> line). Restart bluetoothd and see if it works.
>
> That could be the reason, however the plugin name is "pnat" and not
> "pnat-server" (pnat-server is just the adapter driver name that the pnat
> plugin registers).

Thank you both for the advice. Adding "pnat" to the comma separated list
worked for me.

main.conf now contains line:
DisablePlugins = network,input,pnat

What I could find on pnat-server in the archives stated that it has a
use on some Nokia device. What function does the pnat plugin serve?

Thank you,
Isaiah

2011-08-13 08:26:21

by Johan Hedberg

[permalink] [raw]
Subject: Re: RFCOMM channel 1 behavior differences

Hi,

On Fri, Aug 12, 2011, Vinicius Costa Gomes wrote:
> On 19:23 Fri 12 Aug, Isaiah Sarju wrote:
> > Hello,
> >
> > Does Ubuntu, linux kernel 2.6.38.10, running bluez 4.91-0ubuntu1
> > have a special security policy for incoming rfcomm connections on
> > channel 1, and not other channels?
> >
>
> Most probably this is caused by a problem in how Ubuntu packages
> BlueZ.
>
> Could you try this: edit /etc/bluetooth/main.conf and add "pnat-server"
> to the DisabledPlugins field (perhaps you will need to uncomment that
> line). Restart bluetoothd and see if it works.

That could be the reason, however the plugin name is "pnat" and not
"pnat-server" (pnat-server is just the adapter driver name that the pnat
plugin registers).

Johan

2011-08-13 00:06:15

by Vinicius Costa Gomes

[permalink] [raw]
Subject: Re: RFCOMM channel 1 behavior differences

Hi Isaiah,

On 19:23 Fri 12 Aug, Isaiah Sarju wrote:
> Hello,
>
> Does Ubuntu, linux kernel 2.6.38.10, running bluez 4.91-0ubuntu1
> have a special security policy for incoming rfcomm connections on
> channel 1, and not other channels?
>

Most probably this is caused by a problem in how Ubuntu packages
BlueZ.

Could you try this: edit /etc/bluetooth/main.conf and add "pnat-server"
to the DisabledPlugins field (perhaps you will need to uncomment that
line). Restart bluetoothd and see if it works.

> I ask this because I can create rfcomm connections between two
> computers on other channels (2, 3, 11, 13, etc.) but the listening
> computer refuses connections when connection requests come in for
> channel 1.
>
> I use the following commands:
>
> on listening computer:
> sudo rfcomm listen hci0 <channel>
>
> on connecting computer:
> sudo rfcomm connect hci0 <BD_ADDR> <channel>
>
> When <channel> does not equal 1 both computers connect no with no
> problem. When <channel> equals 1 I receive the error "Can't connect
> RFCOMM socket: Connection refused"
>
> I tried this in to two different environments. 1) in a X-session and
> 2) in command line
>
> 1) in GUI on the listing computer a dialogue box pops up requesting
> a pin for pairing. When I click cancel on the dialogue box of the
> listening machine the error "Can't connect RFCOMM socket: Connection
> refused" appears on the command line of the connecting machine.
>
> 2) in command line mode on the listening computer nothing appears
> and I immediately receive the error "Can't connect RFCOMM socket:
> Connection refused" on in the command line of the connecting machine
>
> These problems do not arise when attempting to connect on any other
> channels.
>
> I have searched Google, looked at multiple forum posts on rfcomm
> connections, looked at forum posts on peoples' problems with rfcomm
> connections, reviewed this mailing list's archives, and I cannot
> find my specific problem.
>
> Thank you for any advice you can provide or resources to which you
> can point me.
>
> Regards,
> Isaiah
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html


Cheers,
--
Vinicius