Seems to have occurred between 3.10.18 and bluetooth-next/for-upstream
Given:
>>> import dbus
>>> bus = dbus.SystemBus()
>>> bluez = bus.get_object('org.bluez', '/org/bluez')
>>> bluez.RegisterProfile('/profile1', '00002401-0000-1000-8000-00805f9b34fb', { 'Name': 'Test RFCOMM Service', 'Channel': dbus.UInt16(0) }, dbus_interface='org.bluez.ProfileManager1')
>>> bluez.RegisterProfile('/profile2', '00002402-0000-1000-8000-00805f9b34fb', { 'Name': 'Test RFCOMM Service', 'Channel': dbus.UInt16(0) }, dbus_interface='org.bluez.ProfileManager1')
The resulting SDP is:
Service Name: Test RFCOMM Service
Service RecHandle: 0x10006
Service Class ID List:
UUID 128: 00002401-0000-1000-8000-00805f9b34fb
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 0
Service Name: Test RFCOMM Service
Service RecHandle: 0x10007
Service Class ID List:
UUID 128: 00002402-0000-1000-8000-00805f9b34fb
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 0
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
On Wed, Apr 2, 2014 at 4:13 AM, Johan Hedberg <[email protected]> wrote:
> FWIW, for the user space side this should now be fixed. It could use a
> bit more testing though, however at least with our test-profile script
> the RFCOMM channel auto-allocation and resulting SDP record seems to be
> fine.
>
Patch looks the same (just less hacky) as I tried here - will test it
out tomorrow!
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
Hi,
On Wed, Apr 02, 2014, Johan Hedberg wrote:
> On Tue, Apr 01, 2014, Scott James Remnant wrote:
> > b783fbc Bluetooth: Refuse peer L2CAP address reading when not connected
> > 35364c9 Bluetooth: Refuse peer RFCOMM address reading when not connected
> >
> > The reason these break things is that they limit peer address checking
> > to connected sockets, btio's get_peers() function is calling both
> > getsockname() and getpeername(), bailing out if either fails, before
> > checking what option is being checked for.
> >
> > Smells more like a bluetoothd fix, but I don't like the idea of
> > earlier versions of bluetoothd breaking on newer kernels.
>
> Indeed. If not a bug it's at the very least bad design of BtIO (which
> I'm to blame of) and now we're stuck suffering the results from that
> since we can't really have the kernel break user space in this way.
>
> We can (and probably should) fix this BtIO behavior, but at the same
> time I think these checks must unfortunately be removed from the kernel
> side before 3.15 goes out.
FWIW, for the user space side this should now be fixed. It could use a
bit more testing though, however at least with our test-profile script
the RFCOMM channel auto-allocation and resulting SDP record seems to be
fine.
Johan
Hi Scott,
On Tue, Apr 01, 2014, Scott James Remnant wrote:
> b783fbc Bluetooth: Refuse peer L2CAP address reading when not connected
> 35364c9 Bluetooth: Refuse peer RFCOMM address reading when not connected
>
> The reason these break things is that they limit peer address checking
> to connected sockets, btio's get_peers() function is calling both
> getsockname() and getpeername(), bailing out if either fails, before
> checking what option is being checked for.
>
> Smells more like a bluetoothd fix, but I don't like the idea of
> earlier versions of bluetoothd breaking on newer kernels.
Indeed. If not a bug it's at the very least bad design of BtIO (which
I'm to blame of) and now we're stuck suffering the results from that
since we can't really have the kernel break user space in this way.
We can (and probably should) fix this BtIO behavior, but at the same
time I think these checks must unfortunately be removed from the kernel
side before 3.15 goes out.
Johan
Culprit commits are:
b783fbc Bluetooth: Refuse peer L2CAP address reading when not connected
35364c9 Bluetooth: Refuse peer RFCOMM address reading when not connected
The reason these break things is that they limit peer address checking
to connected sockets, btio's get_peers() function is calling both
getsockname() and getpeername(), bailing out if either fails, before
checking what option is being checked for.
Smells more like a bluetoothd fix, but I don't like the idea of
earlier versions of bluetoothd breaking on newer kernels.
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google