* BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate
@ 2014-04-01 23:28 Scott James Remnant
2014-04-02 1:01 ` Scott James Remnant
0 siblings, 1 reply; 5+ messages in thread
From: Scott James Remnant @ 2014-04-01 23:28 UTC (permalink / raw)
To: linux-bluetooth
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 | keybuk@google.com | Google
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate
2014-04-01 23:28 BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate Scott James Remnant
@ 2014-04-02 1:01 ` Scott James Remnant
2014-04-02 5:21 ` Johan Hedberg
0 siblings, 1 reply; 5+ messages in thread
From: Scott James Remnant @ 2014-04-02 1:01 UTC (permalink / raw)
To: linux-bluetooth, Johan Hedberg
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 | keybuk@google.com | Google
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate
2014-04-02 1:01 ` Scott James Remnant
@ 2014-04-02 5:21 ` Johan Hedberg
2014-04-02 11:13 ` Johan Hedberg
0 siblings, 1 reply; 5+ messages in thread
From: Johan Hedberg @ 2014-04-02 5:21 UTC (permalink / raw)
To: Scott James Remnant; +Cc: linux-bluetooth
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate
2014-04-02 5:21 ` Johan Hedberg
@ 2014-04-02 11:13 ` Johan Hedberg
2014-04-02 23:54 ` Scott James Remnant
0 siblings, 1 reply; 5+ messages in thread
From: Johan Hedberg @ 2014-04-02 11:13 UTC (permalink / raw)
To: Scott James Remnant, linux-bluetooth
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate
2014-04-02 11:13 ` Johan Hedberg
@ 2014-04-02 23:54 ` Scott James Remnant
0 siblings, 0 replies; 5+ messages in thread
From: Scott James Remnant @ 2014-04-02 23:54 UTC (permalink / raw)
To: Scott James Remnant, linux-bluetooth
On Wed, Apr 2, 2014 at 4:13 AM, Johan Hedberg <johan.hedberg@gmail.com> 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 | keybuk@google.com | Google
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-04-02 23:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-01 23:28 BUG: l2cap and rfcomm bind with 0 psm or channel no longer allocate Scott James Remnant
2014-04-02 1:01 ` Scott James Remnant
2014-04-02 5:21 ` Johan Hedberg
2014-04-02 11:13 ` Johan Hedberg
2014-04-02 23:54 ` Scott James Remnant
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.