* Re: [PATCH 2/2 v2] Bluetooth: Fix system crash bug of no send queue protect
From: haijun liu @ 2010-10-25 2:15 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Haijun Liu, linux-bluetooth
In-Reply-To: <20101022173411.GB980@vigoh>
Hi Gustavo,
>> During test session with another vendor's bt stack, found that
>> without lock protect for TX_QUEUE(sk) will cause system crash while
>> data transfer over AMP controller. So I just add lock protect for
>> TX_QUEUE(sk).
>
> We already use the default socket lock protection. Is it not working for
> you? Why? Could you show a crash case that requires your patch to fix
> it?
>
Yes, there is socket lock protection, but only for sk_buff, for the related
variable we need protect them as well, such as 'sk->sk_send_head',
because later in different context we will use it as sk_buff directly, but at
that time maybe it has been freed and that buffer be occupied by another
sk_buff.
Below is the crash case we met:
[ 265.544145] l2cap_sock_sendmsg: sock e7f4e380, sk e015fc00, msg
e01f5ea4, len 1668
[ 265.544149] l2cap_sock_sendmsg: sk->scid 42, sk->dcid 5d, sk->mode 3
[ 265.544157] block_sendmsg_condition:
[ 265.544160] l2cap_tx_window_full:
[ 265.544163] block_sendmsg_condition: tx_window full: 0, or
wait_f/remote busy.
[ 265.544168] l2cap_sar_segment_sdu: sk e015fc00 len 5736
[ 265.544172] l2cap_create_iframe_pdu: sk e015fc00 len 1011 control
4000 sdulen 5736
[ 265.544175] l2cap_loglink_validate:
[ 265.544179] l2cap_skbuff_fromiovec:
[ 265.544183] l2cap_create_iframe_pdu: sk e015fc00 len 1011 control
c000 sdulen 0
[ 265.544187] l2cap_loglink_validate:
[ 265.544191] l2cap_skbuff_fromiovec:
[ 265.544195] l2cap_create_iframe_pdu: sk e015fc00 len 1011 control
c000 sdulen 0
[ 265.544200] l2cap_loglink_validate:
[ 265.544203] l2cap_skbuff_fromiovec:
[ 265.544207] l2cap_create_iframe_pdu: sk e015fc00 len 1011 control
c000 sdulen 0
[ 265.544211] l2cap_loglink_validate:
[ 265.544214] l2cap_skbuff_fromiovec:
[ 265.544218] l2cap_create_iframe_pdu: sk e015fc00 len 1011 control
c000 sdulen 0
[ 265.544221] l2cap_loglink_validate:
[ 265.544225] l2cap_skbuff_fromiovec:
[ 265.544229] l2cap_create_iframe_pdu: sk e015fc00 len 681 control
8000 sdulen 0
[ 265.544252] l2cap_loglink_validate:
[ 265.544255] l2cap_skbuff_fromiovec:
[ 265.544483] l2cap_recv_acldata:
[ 265.544488] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.544492] l2cap_recv_frame: conn f461bcc0, skb ee91ccc0, cid 42, len 4
[ 265.544496] l2cap_recv_frame: len 4, cid 0x0042
[ 265.544498] l2cap_data_channel:
[ 265.544501] l2cap_get_chan_by_scid:
[ 265.544504] __l2cap_get_chan_by_scid:
[ 265.544508] l2cap_data_channel: sk e015fc00, len 4
[ 265.544511] l2cap_ertm_data_rcv:
[ 265.544514] l2cap_check_fcs:
[ 265.544517] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x2209 len 0
[ 265.544521] l2cap_data_channel_rnrframe: sk e015fc00, req_seq 34 ctrl 0x2209
[ 265.544525] l2cap_drop_acked_frames:
[ 265.544636] l2cap_recv_acldata:
[ 265.544641] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.544645] l2cap_recv_frame: conn f461bcc0, skb ee91c6c0, cid 42, len 4
[ 265.544649] l2cap_recv_frame: len 4, cid 0x0042
[ 265.544652] l2cap_data_channel:
[ 265.544655] l2cap_get_chan_by_scid:
[ 265.544657] __l2cap_get_chan_by_scid:
[ 265.570492] l2cap_recv_acldata:
[ 265.570503] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.570507] l2cap_recv_frame: conn f461bcc0, skb ee91c0c0, cid 42, len 4
[ 265.570513] l2cap_recv_frame: len 4, cid 0x0042
[ 265.570517] l2cap_data_channel:
[ 265.570520] l2cap_get_chan_by_scid:
[ 265.570524] __l2cap_get_chan_by_scid:
[ 265.570529] l2cap_data_channel: sk e015fc00, len 4
[ 265.570533] l2cap_ertm_data_rcv:
[ 265.570536] l2cap_check_fcs:
[ 265.570542] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x2709 len 0
[ 265.570547] l2cap_data_channel_rnrframe: sk e015fc00, req_seq 39 ctrl 0x2709
[ 265.570550] l2cap_drop_acked_frames:
[ 265.570658] l2cap_recv_acldata:
[ 265.570663] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.570668] l2cap_recv_frame: conn f461bcc0, skb ee91ca80, cid 42, len 4
[ 265.570673] l2cap_recv_frame: len 4, cid 0x0042
[ 265.570677] l2cap_data_channel:
[ 265.570680] l2cap_get_chan_by_scid:
[ 265.570683] __l2cap_get_chan_by_scid:
[ 265.570687] l2cap_data_channel: sk e015fc00, len 4
[ 265.570691] l2cap_ertm_data_rcv:
[ 265.570694] l2cap_check_fcs:
[ 265.570698] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x2809 len 0
[ 265.570702] l2cap_data_channel_rnrframe: sk e015fc00, req_seq 40 ctrl 0x2809
[ 265.570706] l2cap_drop_acked_frames:
[ 265.570858] l2cap_recv_acldata:
[ 265.572903] l2cap_recv_acldata:
[ 265.572910] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.572915] l2cap_recv_frame: conn f461bcc0, skb f469fa80, cid 42, len 4
[ 265.572919] l2cap_recv_frame: len 4, cid 0x0042
[ 265.572921] l2cap_data_channel:
[ 265.572925] l2cap_get_chan_by_scid:
[ 265.572928] __l2cap_get_chan_by_scid:
[ 265.572933] l2cap_data_channel: sk e015fc00, len 4
[ 265.572936] l2cap_ertm_data_rcv:
[ 265.572938] l2cap_check_fcs:
[ 265.572943] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x2b09 len 0
[ 265.573348] l2cap_recv_acldata:
[ 265.609993] l2cap_recv_acldata:
[ 265.610005] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.610009] l2cap_recv_frame: conn f461bcc0, skb ee91c540, cid 42, len 4
[ 265.610013] l2cap_recv_frame: len 4, cid 0x0042
[ 265.610016] l2cap_data_channel:
[ 265.610019] l2cap_get_chan_by_scid:
[ 265.610022] __l2cap_get_chan_by_scid:
[ 265.610025] l2cap_data_channel: sk e015fc00, len 4
[ 265.610029] l2cap_ertm_data_rcv:
[ 265.610032] l2cap_check_fcs:
[ 265.610036] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x3801 len 0
[ 265.610041] l2cap_data_channel_rrframe: sk e015fc00, req_seq 56 ctrl 0x3801
[ 265.610044] l2cap_drop_acked_frames:
[ 265.610060] l2cap_ertm_send: sk e015fc00, sk->scid 42, sk->dcid 5d
[ 265.610064] l2cap_tx_window_full:
[ 265.610071] l2cap_ertm_send: pi->next_tx_seq: 13, pi->buffer_seq: 2
[ 265.610075] l2cap_do_send: sk e015fc00, cid 66 skb e0147840 len 1019
[ 265.610078] l2cap_loglink_validate:
[ 265.610081] l2cap_do_send: send I frame over AMP controller
[ 265.610085] l2cap_tx_window_full:
[ 265.610093] l2cap_ertm_send: pi->next_tx_seq: 14, pi->buffer_seq: 2
[ 265.610096] l2cap_do_send: sk e015fc00, cid 66 skb f4801cc0 len 1019
[ 265.610099] l2cap_loglink_validate:
[ 265.610102] l2cap_do_send: send I frame over AMP controller
[ 265.610105] l2cap_tx_window_full:
[ 265.610112] l2cap_ertm_send: pi->next_tx_seq: 15, pi->buffer_seq: 2
[ 265.610115] l2cap_do_send: sk e015fc00, cid 66 skb f4801600 len 1019
[ 265.610118] l2cap_loglink_validate:
[ 265.610121] l2cap_do_send: send I frame over AMP controller
[ 265.610124] l2cap_tx_window_full:
[ 265.610130] l2cap_ertm_send: pi->next_tx_seq: 16, pi->buffer_seq: 2
[ 265.610133] l2cap_do_send: sk e015fc00, cid 66 skb f4801c00 len 689
[ 265.610137] l2cap_loglink_validate:
[ 265.610140] l2cap_do_send: send I frame over AMP controller
[ 265.610143] l2cap_tx_window_full:
[ 265.610153] l2cap_ertm_send: pi->next_tx_seq: 17, pi->buffer_seq: 2
[ 265.610215] l2cap_ertm_send: pi->next_tx_seq: 20, pi->buffer_seq: 2
[ 265.610219] l2cap_do_send: sk e015fc00, cid 66 skb f47f03c0 len 1019
[ 265.610222] l2cap_loglink_validate:
[ 265.619937] l2cap_recv_acldata:
[ 265.619948] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.619952] l2cap_recv_frame: conn f461bcc0, skb ee91c300, cid 42, len 4
[ 265.619956] l2cap_recv_frame: len 4, cid 0x0042
[ 265.620154] l2cap_ertm_send: pi->next_tx_seq: 29, pi->buffer_seq: 2
[ 265.629111] l2cap_recv_acldata:
[ 265.629123] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.639371] l2cap_recv_acldata:
[ 265.639384] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.639388] l2cap_recv_frame: conn f461bcc0, skb ee91ccc0, cid 42, len 4
[ 265.639392] l2cap_recv_frame: len 4, cid 0x0042
[ 265.639395] l2cap_data_channel:
[ 265.639398] l2cap_get_chan_by_scid:
[ 265.639401] __l2cap_get_chan_by_scid:
[ 265.639405] l2cap_data_channel: sk e015fc00, len 4
[ 265.639407] l2cap_ertm_data_rcv:
[ 265.639570] l2cap_do_send: send I frame over AMP controller
[ 265.646669] l2cap_recv_acldata:
[ 265.646681] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.646685] l2cap_recv_frame: conn f461bcc0, skb ee91c6c0, cid 42, len 4
[ 265.646822] l2cap_loglink_validate:
[ 265.646825] l2cap_skbuff_fromiovec:
[ 265.647800] l2cap_recv_acldata:
[ 265.647808] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.649645] l2cap_recv_acldata:
[ 265.649655] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.649659] l2cap_recv_frame: conn f461bcc0, skb ee91c180, cid 42, len 4
[ 265.649663] l2cap_recv_frame: len 4, cid 0x0042
[ 265.651518] l2cap_recv_acldata:
[ 265.651527] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.651532] l2cap_recv_frame: conn f461bcc0, skb ee91c0c0, cid 42, len 4
[ 265.655539] l2cap_recv_acldata:
[ 265.655547] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.655550] l2cap_recv_frame: conn f461bcc0, skb e035bc00, cid 42, len 4
[ 265.655554] l2cap_recv_frame: len 4, cid 0x0042
[ 265.655556] l2cap_data_channel:
[ 265.655559] l2cap_get_chan_by_scid:
[ 265.655562] __l2cap_get_chan_by_scid:
[ 265.663270] l2cap_recv_acldata:
[ 265.663276] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.667987] l2cap_recv_acldata:
[ 265.673206] l2cap_recv_acldata:
[ 265.673217] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.673221] l2cap_recv_frame: conn f461bcc0, skb ee91c780, cid 42, len 4
[ 265.673225] l2cap_recv_frame: len 4, cid 0x0042
[ 265.673227] l2cap_data_channel:
[ 265.673230] l2cap_get_chan_by_scid:
[ 265.673233] __l2cap_get_chan_by_scid:
[ 265.673236] l2cap_data_channel: sk e015fc00, len 4
[ 265.673240] l2cap_ertm_data_rcv:
[ 265.673243] l2cap_check_fcs:
[ 265.673247] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x3109 len 0
[ 265.675265] l2cap_recv_acldata:
[ 265.675273] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.691337] l2cap_recv_acldata:
[ 265.691348] l2cap_recv_acldata: conn f461bcc0 len 8 flags 0x3
[ 265.691352] l2cap_recv_frame: conn f461bcc0, skb ee91c000, cid 42, len 4
[ 265.691356] l2cap_recv_frame: len 4, cid 0x0042
[ 265.691359] l2cap_data_channel:
[ 265.691362] l2cap_get_chan_by_scid:
[ 265.691366] __l2cap_get_chan_by_scid:
[ 265.691369] l2cap_data_channel: sk e015fc00, len 4
[ 265.691372] l2cap_ertm_data_rcv:
[ 265.691375] l2cap_check_fcs:
[ 265.691379] l2cap_data_channel_sframe: sk e015fc00 rx_control 0x3511 len 0
[ 265.691383] l2cap_data_channel_rrframe: sk e015fc00, req_seq 53 ctrl 0x3511
[ 265.691386] l2cap_drop_acked_frames:
[ 265.691389] l2cap_send_i_or_rr_or_rnr:
[ 265.691392] l2cap_ertm_send: sk e015fc00, sk->scid 42, sk->dcid 5d
[ 265.691396] l2cap_tx_window_full:
[ 265.691400] l2cap_ertm_send: pi->next_tx_seq: 53, pi->buffer_seq: 2
[ 265.691404] l2cap_do_send: sk e015fc00, cid 66 skb e0204000 len 101
[ 265.691407] l2cap_loglink_validate:
[ 265.691410] l2cap_do_send: send I frame over AMP controller
[ 265.691415] skb_under_panic: text:f8224a57 len:105 put:4
head:e002ba00 data:e002b9fe tail:0xe002ba2c end:0xe002ba80 dev:瘗"?
[ 265.691443] ------------[ cut here ]------------
[ 265.691446] kernel BUG at net/core/skbuff.c:147!
[ 265.691450] invalid opcode: 0000 [#1] SMP
[ 265.691456] last sysfs file:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_full
[ 265.691460] Modules linked in:[ 265.692743] [<f822573e>]
hci_rx_task+0x2de/0x380 [bluetooth]
[ 265.692748] [<c0132921>] ? __dequeue_entity+0x21/0x40
[ 265.696007] NOHZ: local_softirq_pending 0e
>From above context, we know we expect a skb with length 1019(1011+8),
but dump context tell us, the len is 105.
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH 1/2 v2] Bluetooth: Fix system crash caused by del_timer()
From: haijun liu @ 2010-10-25 1:35 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Haijun Liu, linux-bluetooth
In-Reply-To: <20101022171825.GA980@vigoh>
Hi Gustavo,
>> During test session with another vendor's bt stack, found that in
>> l2cap_chan_del() using del_timer() caused l2cap_monitor_timeout()
>> be called after the sock was freed, so it raised a system crash.
>> So I just replaced del_timer() with del_timer_sync() to solve it.
>
> NAK on this. If you read the del_timer_sync() documentation you can
> see that you can't call del_timer_sync() on interrupt context. The
> possible solution here is to check in the beginning of
> l2cap_monitor_timeout() if your sock is still valid.
>
You are right, I only considered close() interface, so missed the interrupt
context.
It's very difficult to check sock valid or not in timeout procedure, since it's
an interrupt context, and only can get context from parameter pre-stored,
except global variables.
Let's think about it and come up a good solution for this situation.
--
Haijun Liu
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Elvis Pfützenreuter @ 2010-10-24 18:44 UTC (permalink / raw)
To: Santiago Carot; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikLByb4qKBJP_iBUw2H0EqLo1MA9bttLwBO9s-u@mail.gmail.com>
> sure?
> Then you should think what happen with the First reliable data channel
> in case that you are running multiples IEEE specializations over the
> same HDP instance (that is pretty common in IEEE level). Remember that
> the First Relible data channel is used for IEEE association and
> confirmed event traffic. If you dont allow use that channel by other
> application it won't associate with the other device at IEEE layer.
> Please, think that with current HDP implementation you can develop
> IEEE agent specializations too, not only managers.
Ok, I think I see your point now. Thanks for the patience :)
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Elvis Pfützenreuter @ 2010-10-24 17:50 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: Santiago Carot, linux-bluetooth
In-Reply-To: <AANLkTiknmbF78BgGH+KBTfjEvw4rqLVxu3Nnhg3nshB7@mail.gmail.com>
> Sorry, you are right about that, reconnections are not mantadory in
> all cases for sources. May be we should check this flags before
> keeping the state and emitting the signal.
This could be useful even in this case of MDL abort X ChannelConnected signal. If the flags say that device is incapable of reconnections, definetively no point in emitting the signal.
But I am not sure if you will have the SDP record at hand to do this check, at that moment; certainly not worth forcing a SDP query just to round these particular corner cases.
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Jose Antonio Santos Cadenas @ 2010-10-24 15:19 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Santiago Carot, linux-bluetooth
In-Reply-To: <3511AB9E-2F29-4E9C-845A-674A3EA437E7@signove.com>
2010/10/24 Elvis Pfützenreuter <epx@signove.com>:
> Hello,
>
>> In that case, the problem is in the remote side, because the Bluetooth
>> SIG certification requires the devices to support reconnections, so
>> the problem is not in our side but in the remote side that isn't
>> compliant with the standard. I think we don't have to change our
>> implementation regarding buggy devices that don't follow the
>> specification correctly.
>
> I think an HDP device is NOT required to support reconnections. In HDP spec item 5.2.11 there is that bitmap in SDP record that says whether device supports reconnections and CSP.
Sorry, you are right about that, reconnections are not mantadory in
all cases for sources. May be we should check this flags before
keeping the state and emitting the signal.
>
>> More over, the situation that you mention. When receiving a
>> ChannelDeletion, the application shouldn't close the data channel,
>> because the in the normal situation, the DBus object for the data
>> channel will be removed, so no closing of the channel will be
>> performed, the only thing that should happen is that the application
>> will "forget" about this channel. When the second ChannelConnected is
>> received, the application will typically perform an acquire that, in
>> this case, will be very simple because the channel will be already
>> connected and the fd will be transmitted.
>
> So the application must follow a very specific behaviour when handling a ChannelDeleted signal, and worse yet, it must do it to fix a problem that we could fix simply by changing the way channel paths are named.
>
The only thing that the application should do when receiving a
ChannelDeleted signal is to forget about this channel because the
Channel object does not exists any more and no more calls to the
channel API could be done. Nevertheless if you close the fd get from
the Acquire petition, nothing will happen to the new channel, because
the new channel has a new btiochannel. I have to experiment with this
to be completely sure and see how DBus fd-passing deals with this, but
everything points that nothing will happen when closing the previous
get fd.
> If it was the case that we simply could not change the channel path naming, this behaviour should at least written very clearly in API.
>
>> In general, I think, guys, that we are thinking again in very estrange
>> situations. As we said in the Recife's meeting we should design the
>> implementation and the API for working with compliants devices, not
>> with buggy ones and also we have to simplify the use for the API,
>> making it simple for the application programmers in the most usual
>> cases not in the strange ones, that will happen very rarely.
>
> It's weekend, and playing devil's advocate is fun :P
>
> Seriously now, my objective is the same, avoiding that a perfectly sensible application act (closing fd after receiving a ChannelDeleted event) causing a race condition. And IMHO a condition that may happen with compliant devices as well.
Let's see what fd-passing is managing the fd and decide having this
data. Tomorrow I'll experiment with this and reply to the list with
the results.
Regards.
Jose
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Elvis Pfützenreuter @ 2010-10-24 13:28 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: Santiago Carot, linux-bluetooth
In-Reply-To: <AANLkTim3m1ogwwx5MqF+z1FDKn4w3xHEN7MOAO5iW_ms@mail.gmail.com>
Hello,
> In that case, the problem is in the remote side, because the Bluetooth
> SIG certification requires the devices to support reconnections, so
> the problem is not in our side but in the remote side that isn't
> compliant with the standard. I think we don't have to change our
> implementation regarding buggy devices that don't follow the
> specification correctly.
I think an HDP device is NOT required to support reconnections. In HDP spec item 5.2.11 there is that bitmap in SDP record that says whether device supports reconnections and CSP.
> More over, the situation that you mention. When receiving a
> ChannelDeletion, the application shouldn't close the data channel,
> because the in the normal situation, the DBus object for the data
> channel will be removed, so no closing of the channel will be
> performed, the only thing that should happen is that the application
> will "forget" about this channel. When the second ChannelConnected is
> received, the application will typically perform an acquire that, in
> this case, will be very simple because the channel will be already
> connected and the fd will be transmitted.
So the application must follow a very specific behaviour when handling a ChannelDeleted signal, and worse yet, it must do it to fix a problem that we could fix simply by changing the way channel paths are named.
If it was the case that we simply could not change the channel path naming, this behaviour should at least written very clearly in API.
> In general, I think, guys, that we are thinking again in very estrange
> situations. As we said in the Recife's meeting we should design the
> implementation and the API for working with compliants devices, not
> with buggy ones and also we have to simplify the use for the API,
> making it simple for the application programmers in the most usual
> cases not in the strange ones, that will happen very rarely.
It's weekend, and playing devil's advocate is fun :P
Seriously now, my objective is the same, avoiding that a perfectly sensible application act (closing fd after receiving a ChannelDeleted event) causing a race condition. And IMHO a condition that may happen with compliant devices as well.
^ permalink raw reply
* 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Ilya Basin @ 2010-10-24 12:38 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
It all started after upgrading bluez from 4.69 to 4.76 .
'hcitool scan' work and bluetoothd starts normally, but when launching
any related program (e.g. Gnome bluetooth-applet), bluetoothd dies with segfault:
Oct 24 11:31:01 IL kernel: bluetoothd[3894]: segfault at 0 ip
b7632653 sp bfee9b5c error 4 in libc-2.12.1.so[b75be000+145000]
Downgrading to 4.69 helps, I don't even have to reboot, just
restarting bluetoothd
Additional info:
* package version(s)
kernel26 2.6.35.7
bluez 4.76
dbus 1.4.0
$ lsusb | grep lue
Bus 003 Device 002: ID 0a5c:2121 Broadcom Corp. BCM2210 Bluetooth
Compiled with debug flags, gdb output attached
dbus_message_iter_append_basic () is called 7 times after another bt
program starts.
Params seem valid:
Breakpoint 1, 0xb7e4e616 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
(gdb) print (void*)($esp+0)
$1 = (void *) 0xbffff3c0
(gdb) print *(char*)($esp+4)
$2 = 115 's'
(gdb) print **(char***)($esp+8)
$3 = 0xb80474f0 "0000110e-0000-1000-8000-00805f9b34fb"
(gdb) finish
Run till exit from #0 0xb7e4e616 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
Program received signal SIGSEGV, Segmentation fault.
0xb7d3e653 in strlen () from /lib/libc.so.6
(gdb)
[-- Attachment #2: gdb.txt --]
[-- Type: TEXT/PLAIN, Size: 3007 bytes --]
[root@IL packages]# gdb --args /home/il/builds/bluez-debug/src/src/bluez-4.76/src/.libs/bluetoothd -n
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /.snapshots/persist/builds/bluez-debug/src/src/bluez-4.76/src/.libs/bluetoothd...(no debugging symbols found)...done.
(gdb) r
Starting program: /.snapshots/persist/builds/bluez-debug/src/src/bluez-4.76/src/.libs/bluetoothd -n
[Thread debugging using libthread_db enabled]
bluetoothd[20561]: Bluetooth deamon 4.76
bluetoothd[20561]: Starting SDP server
bluetoothd[20561]: HCI dev 0 registered
bluetoothd[20561]: HCI dev 0 up
bluetoothd[20561]: Starting security manager 0
bluetoothd[20561]: Clearing blocked list failed: Invalid argument (22)
bluetoothd[20561]: probe failed with driver input-headset for device /org/bluez/20561/hci0/dev_00_1B_98_A3_A5_2B
bluetoothd[20561]: probe failed with driver input-headset for device /org/bluez/20561/hci0/dev_00_1D_6E_4F_54_EA
bluetoothd[20561]: probe failed with driver input-headset for device /org/bluez/20561/hci0/dev_A8_7E_33_D7_29_DB
bluetoothd[20561]: Adapter /org/bluez/20561/hci0 has been enabled
bluetoothd[20561]: Inquiry Failed with status 0x12
^C
Program received signal SIGINT, Interrupt.
0xb7f73424 in __kernel_vsyscall ()
(gdb) b dbus_message_iter_append_basic
Breakpoint 1 at 0xb7e4e616
(gdb) c
Continuing.
====================
here i start another program
====================
Breakpoint 1, 0xb7e4e616 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
(gdb) c 6
Will ignore next 5 crossings of breakpoint 1. Continuing.
Breakpoint 1, 0xb7e4e616 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb7d3e653 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7d3e653 in strlen () from /lib/libc.so.6
#1 0xb7e5eb10 in ?? () from /usr/lib/libdbus-1.so.3
#2 0xb7e4a34b in ?? () from /usr/lib/libdbus-1.so.3
#3 0xb7e4e7a9 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
#4 0xb7fef03d in append_array_variant ()
#5 0xb7fef799 in emit_array_property_changed ()
#6 0xb7fe4de4 in adapter_service_ins_rem ()
#7 0xb7fd7fb1 in sdp_record_add ()
#8 0xb7fd79de in service_register_req ()
#9 0xb7fd5dfc in handle_request ()
#10 0xb7fd496e in io_session_event ()
#11 0xb7ef7a2b in ?? () from /usr/lib/libglib-2.0.so.0
#12 0xb7eb0b72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0xb7eb1350 in ?? () from /usr/lib/libglib-2.0.so.0
#14 0xb7eb1a1b in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#15 0xb7fd1bbd in main ()
(gdb)
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Jose Antonio Santos Cadenas @ 2010-10-24 12:10 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Santiago Carot, linux-bluetooth
In-Reply-To: <4B999390-7FFB-4B90-98BA-D9F9C17771F5@signove.com>
2010/10/23 Elvis Pfützenreuter <epx@signove.com>:
>> You are forgetting that there may be more than one health applications
>> running over HDP at the same time, if one of them creates a data
>> channel, that data data channel will be exist at MCAP level even if
>> the initiator abort the connection. If other application wants to
>> create a new data channel with the same configuration, it may be want
>> reconnect that data channel avoiding to create another data channel.
>> It is a best practise wich is recomended in MCAP and best explained in
>> the Health Device Profile white paper document to reduce the amount of
>> data interchanged between medical devices (in IEEE/11073-20601
>> terminology: "agents" and "managers"). Remember that channels may be
>> shared between applications.
>
> I'm still not convinced :) I can't see the point of sharing a HealthChannel that is not healthy (pardon the joke).
>
> Maybe I'm being too pragmatic, but I expect that most real HDP devices will be like that Nonin oximeter: incapable of reconnecting MDLs and incapable of accepting connections. Sharing a channel in that situation will make spend much more, not less, energy, because applications will Acquire() and trigger a reconnection over a channel that actually does not exist and wouldn't be accepted even if it existed.
In that case, the problem is in the remote side, because the Bluetooth
SIG certification requires the devices to support reconnections, so
the problem is not in our side but in the remote side that isn't
compliant with the standard. I think we don't have to change our
implementation regarding buggy devices that don't follow the
specification correctly.
>
> Anyway, MDL aborts are expected to be rare, so the actual problem won't be seen often in practice.
In the other hand is this reason you mention, this is a very estrange
situation, so I don't think that the behaviour that we take will be
very important. In fact I don't think that this situation will happen
ever. In the case of the oximeter if it doesn't reconnect data
channels I think that it won't never send an abort or any other
abnormal command.
>
> I think we have another, more important problem: naming the channel after MDLID.
>
> For example, the channel that comes from oximeter has always the same path here: /org/bluez/19750/hci0/dev_00_1C_05_00_28_85/chan1. It is incapable of reconnections but always recreates the MDL with the same MDL ID = 1.
>
> Now, let's suppose a MDL is created, destroyed and re-created, but for some reason the application the application takes too long to act upon the signal. You have three signals:
>
> ChannelConnected chan1
> ChannelDeleted chan1
> ChannelConnected chan1 (a second channel with the same MDL ID)
>
> Application will Acquire() on first signal, thinking it is getting the FD for the first instance of chan1, but it will actually get the FD for the second "version" of chan1.
>
> Then it will process the ChannelDeleted signal, closing a perfectly good channel. And then it sees the third signal, and tries the Acquire() the fd it has just closed. If the other side tries to reconnect immediately but does not support MCAP reconnections, this could go on forever.
>
> A possible solution is to use a monotonic number for the channel path suffix, without relation to MDL ID.
I don't think that this naming is a problem. Think that using the same
id that the real channel is using guarantees us that all the active
channels are using unique IDs in a very "cheap" way, because is MCAP
who's dealing with the id's assignment.
More over, the situation that you mention. When receiving a
ChannelDeletion, the application shouldn't close the data channel,
because the in the normal situation, the DBus object for the data
channel will be removed, so no closing of the channel will be
performed, the only thing that should happen is that the application
will "forget" about this channel. When the second ChannelConnected is
received, the application will typically perform an acquire that, in
this case, will be very simple because the channel will be already
connected and the fd will be transmitted.
In general, I think, guys, that we are thinking again in very estrange
situations. As we said in the Recife's meeting we should design the
implementation and the API for working with compliants devices, not
with buggy ones and also we have to simplify the use for the API,
making it simple for the application programmers in the most usual
cases not in the strange ones, that will happen very rarely.
Regards.
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Santiago Carot @ 2010-10-24 8:40 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <AANLkTikLByb4qKBJP_iBUw2H0EqLo1MA9bttLwBO9s-u@mail.gmail.com>
2010/10/24 Santiago Carot <sancane@gmail.com>:
> Hi,
>
> 2010/10/23 Elvis Pfützenreuter <epx@signove.com>:
>>> You are forgetting that there may be more than one health applications
>>> running over HDP at the same time, if one of them creates a data
>>> channel, that data data channel will be exist at MCAP level even if
>>> the initiator abort the connection. If other application wants to
>>> create a new data channel with the same configuration, it may be want
>>> reconnect that data channel avoiding to create another data channel.
>>> It is a best practise wich is recomended in MCAP and best explained in
>>> the Health Device Profile white paper document to reduce the amount of
>>> data interchanged between medical devices (in IEEE/11073-20601
>>> terminology: "agents" and "managers"). Remember that channels may be
>>> shared between applications.
>>
>> I'm still not convinced :) I can't see the point of sharing a HealthChannel that is not healthy (pardon the joke).
>
> sure?
> Then you should think what happen with the First reliable data channel
> in case that you are running multiples IEEE specializations over the
> same HDP instance (that is pretty common in IEEE level). Remember that
> the First Relible data channel is used for IEEE association and
> confirmed event traffic. If you dont allow use that channel by other
> application it won't associate with the other device at IEEE layer.
> Please, think that with current HDP implementation you can develop
> IEEE agent specializations too, not only managers.
>
> HDP specification says:
> * The first Data Channel opened on a given MCL shall be a Reliable Data Channel.
> * Association traffic shall be carried on the first Reliable Data
> Channel that was
> opened on a given MCL.
>
> Next you are a text fragment copied from white paper (Alluding to the
> example where there are two applications on HDP):
> "...The right side of the diagram shows two devices that typically
> both use Reliable Data Channels. In this
> case, the devices may share a common Reliable Data Channel (and MDL)
> for all data or may optionally
> have separate MDLs for their data, but share the first Reliable Data
> Channel for IEEE association and
> confirmed event traffic..."
>
>
>>
>> Maybe I'm being too pragmatic, but I expect that most real HDP devices will be like that Nonin oximeter: incapable of reconnecting MDLs and incapable of accepting connections. Sharing a channel in that situation will make spend much more, not less, energy, because applications will Acquire() and trigger a reconnection over a channel that actually does not exist and wouldn't be accepted even if it existed.
>
> There are not only Nonin oximeter devices, we have a blood pressure
> that reconnect data channels, in the past we played with a weighing
> scale wich it was waiting for data channel connections, besides it is
> expected more complex devices such as electrocardiograms, and also you
> should think about what will happen if somebody uses this
> implementation to develop a health device specialization?, for
> example, I thinking in smartphones with sensors, etc... IMHO it is
> very presumptuous to make such assumptions about the future (may be I
> am too idealist) :P
>
>>
>> Anyway, MDL aborts are expected to be rare, so the actual problem won't be seen often in practice.
>>
>> I think we have another, more important problem: naming the channel after MDLID.
>>
>> For example, the channel that comes from oximeter has always the same path here: /org/bluez/19750/hci0/dev_00_1C_05_00_28_85/chan1. It is incapable of reconnections but always recreates the MDL with the same MDL ID = 1.
>>
>> Now, let's suppose a MDL is created, destroyed and re-created, but for some reason the application the application takes too long to act upon the signal. You have three signals:
>>
>> ChannelConnected chan1
>> ChannelDeleted chan1
>> ChannelConnected chan1 (a second channel with the same MDL ID)
>>
>> Application will Acquire() on first signal, thinking it is getting the FD for the first instance of chan1, but it will actually get the FD for the second "version" of chan1.
>>
>> Then it will process the ChannelDeleted signal, closing a perfectly good channel. And then it sees the third signal, and tries the Acquire() the fd it has just closed. If the other side tries to reconnect immediately but does not support MCAP reconnections, this could go on forever.
>>
>> A possible solution is to use a monotonic number for the channel path suffix, without relation to MDL ID.
>
Sorry, please, ignore my last comment:
> That is a problem in remote side and applications shall to know how
You are right, I don't know exactly how we can address that problem,
may be we have to study this in deep.
Regards.
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Santiago Carot @ 2010-10-24 8:34 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <4B999390-7FFB-4B90-98BA-D9F9C17771F5@signove.com>
Hi,
2010/10/23 Elvis Pfützenreuter <epx@signove.com>:
>> You are forgetting that there may be more than one health applications
>> running over HDP at the same time, if one of them creates a data
>> channel, that data data channel will be exist at MCAP level even if
>> the initiator abort the connection. If other application wants to
>> create a new data channel with the same configuration, it may be want
>> reconnect that data channel avoiding to create another data channel.
>> It is a best practise wich is recomended in MCAP and best explained in
>> the Health Device Profile white paper document to reduce the amount of
>> data interchanged between medical devices (in IEEE/11073-20601
>> terminology: "agents" and "managers"). Remember that channels may be
>> shared between applications.
>
> I'm still not convinced :) I can't see the point of sharing a HealthChannel that is not healthy (pardon the joke).
sure?
Then you should think what happen with the First reliable data channel
in case that you are running multiples IEEE specializations over the
same HDP instance (that is pretty common in IEEE level). Remember that
the First Relible data channel is used for IEEE association and
confirmed event traffic. If you dont allow use that channel by other
application it won't associate with the other device at IEEE layer.
Please, think that with current HDP implementation you can develop
IEEE agent specializations too, not only managers.
HDP specification says:
* The first Data Channel opened on a given MCL shall be a Reliable Data Channel.
* Association traffic shall be carried on the first Reliable Data
Channel that was
opened on a given MCL.
Next you are a text fragment copied from white paper (Alluding to the
example where there are two applications on HDP):
"...The right side of the diagram shows two devices that typically
both use Reliable Data Channels. In this
case, the devices may share a common Reliable Data Channel (and MDL)
for all data or may optionally
have separate MDLs for their data, but share the first Reliable Data
Channel for IEEE association and
confirmed event traffic..."
>
> Maybe I'm being too pragmatic, but I expect that most real HDP devices will be like that Nonin oximeter: incapable of reconnecting MDLs and incapable of accepting connections. Sharing a channel in that situation will make spend much more, not less, energy, because applications will Acquire() and trigger a reconnection over a channel that actually does not exist and wouldn't be accepted even if it existed.
There are not only Nonin oximeter devices, we have a blood pressure
that reconnect data channels, in the past we played with a weighing
scale wich it was waiting for data channel connections, besides it is
expected more complex devices such as electrocardiograms, and also you
should think about what will happen if somebody uses this
implementation to develop a health device specialization?, for
example, I thinking in smartphones with sensors, etc... IMHO it is
very presumptuous to make such assumptions about the future (may be I
am too idealist) :P
>
> Anyway, MDL aborts are expected to be rare, so the actual problem won't be seen often in practice.
>
> I think we have another, more important problem: naming the channel after MDLID.
>
> For example, the channel that comes from oximeter has always the same path here: /org/bluez/19750/hci0/dev_00_1C_05_00_28_85/chan1. It is incapable of reconnections but always recreates the MDL with the same MDL ID = 1.
>
> Now, let's suppose a MDL is created, destroyed and re-created, but for some reason the application the application takes too long to act upon the signal. You have three signals:
>
> ChannelConnected chan1
> ChannelDeleted chan1
> ChannelConnected chan1 (a second channel with the same MDL ID)
>
> Application will Acquire() on first signal, thinking it is getting the FD for the first instance of chan1, but it will actually get the FD for the second "version" of chan1.
>
> Then it will process the ChannelDeleted signal, closing a perfectly good channel. And then it sees the third signal, and tries the Acquire() the fd it has just closed. If the other side tries to reconnect immediately but does not support MCAP reconnections, this could go on forever.
>
> A possible solution is to use a monotonic number for the channel path suffix, without relation to MDL ID.
That is a problem in remote side and applications shall to know how
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Elvis Pfützenreuter @ 2010-10-23 20:35 UTC (permalink / raw)
To: Santiago Carot; +Cc: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <AANLkTi=65C7HQXQW1Bqbgf4sNY3wbV2CzqoENBc-b04g@mail.gmail.com>
> You are forgetting that there may be more than one health applications
> running over HDP at the same time, if one of them creates a data
> channel, that data data channel will be exist at MCAP level even if
> the initiator abort the connection. If other application wants to
> create a new data channel with the same configuration, it may be want
> reconnect that data channel avoiding to create another data channel.
> It is a best practise wich is recomended in MCAP and best explained in
> the Health Device Profile white paper document to reduce the amount of
> data interchanged between medical devices (in IEEE/11073-20601
> terminology: "agents" and "managers"). Remember that channels may be
> shared between applications.
I'm still not convinced :) I can't see the point of sharing a HealthChannel that is not healthy (pardon the joke).
Maybe I'm being too pragmatic, but I expect that most real HDP devices will be like that Nonin oximeter: incapable of reconnecting MDLs and incapable of accepting connections. Sharing a channel in that situation will make spend much more, not less, energy, because applications will Acquire() and trigger a reconnection over a channel that actually does not exist and wouldn't be accepted even if it existed.
Anyway, MDL aborts are expected to be rare, so the actual problem won't be seen often in practice.
I think we have another, more important problem: naming the channel after MDLID.
For example, the channel that comes from oximeter has always the same path here: /org/bluez/19750/hci0/dev_00_1C_05_00_28_85/chan1. It is incapable of reconnections but always recreates the MDL with the same MDL ID = 1.
Now, let's suppose a MDL is created, destroyed and re-created, but for some reason the application the application takes too long to act upon the signal. You have three signals:
ChannelConnected chan1
ChannelDeleted chan1
ChannelConnected chan1 (a second channel with the same MDL ID)
Application will Acquire() on first signal, thinking it is getting the FD for the first instance of chan1, but it will actually get the FD for the second "version" of chan1.
Then it will process the ChannelDeleted signal, closing a perfectly good channel. And then it sees the third signal, and tries the Acquire() the fd it has just closed. If the other side tries to reconnect immediately but does not support MCAP reconnections, this could go on forever.
A possible solution is to use a monotonic number for the channel path suffix, without relation to MDL ID.
^ permalink raw reply
* Re: AVRCP 1.4 : Future on Target Role
From: João Paulo Rechi Vita @ 2010-10-23 15:50 UTC (permalink / raw)
To: linux-bluetooth
Cc: Sander van Grieken, Shivendra Agrawal, David Stockwell,
Waldemar Rymarkiewicz, Luiz Augusto von Dentz, Johan Hedberg
In-Reply-To: <AANLkTikgKM1MNpwP2JL1GdERZ60dE6dkFNC=rdyQDhOV@mail.gmail.com>
Hello all,
I've seen some discuss regarding how to add support for AVRCP 1.3 and
1.4 versions on the ML lately, and some expectations over the related
work I've done in BlueZ. Sorry for the long delay on replying, I've
been pretty busy lately and just didn't got the time. I'm planing to
put some effort again on this work on the coming weeks.
On Tue, Oct 19, 2010 at 14:14, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
> <sander@outrightsolutions.nl> wrote:
>> I am very much in favor of not directly depending on MPRIS, but instead letting
>> applications registering themselves as a target. For two reasons:
>>
>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>> the intersecting subset of both technologies.
>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>> MPRIS support.
>
> Sounds good to me, we can use Media API to register players as well.
>
I agree with Sander's opinion that MPRIS seems a bit limited for 1.4.
OTOH it's an already defined and under-adoption standard. If we have
applications registering themselves directly with us, we'll have to
define a new interface for that and push this to the player
applications. Do you guys already have a draft of these interfaces
(for the applications and extensions to the Media API)? I guess we
should try to define exactly what we need first, and them see what's
missing from MPRIS.
>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>> > my effort in right direction.
>>> >
>>> > Question:
>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>
>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>
>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>
>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>> and conflict with Joao's stuff, so I'm hesitant to go there.
>
Have you published this code somewhere?
> I hope to see this code being push upstream soon, I will try to
> contact Joao Paulo to get an idea if the code is ready to be
> reviewed/pushed so we get the things rolling.
>
I'm finally here :) I've focused mostly in the 1.3 version of the spec
and having pulseaudio as a middle-man in my work, and have written
most of the code in pulseaudio to handle these new functionality. Even
if we take the approach described above for 1.4, IMO it makes sense to
upstream this so we can have earlier support for 1.3 and also to
support Sander's work. Luiz, Johan, what do you think?
I'll review the code once more, since I've written it a few months
ago, but my main concern about pushing it upstream right now is that
it hasn't been tested yet. I have no device to test against and PTS
can't give us no guarantee whether the code really works in practice
or not (but it's still better than nothing). Sander, David, have you
tested my code against any real device?
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
^ permalink raw reply
* Re: [PATCH] This patch avoids a crash when org.bluez.Manager GetProperties request is received and there is not yet any adapters ready. Happens often for example when bluetoothd and ofonod is started next ot each other.
From: Johan Hedberg @ 2010-10-23 12:31 UTC (permalink / raw)
To: Tommi Keisala; +Cc: linux-bluetooth
In-Reply-To: <1287811998-20490-2-git-send-email-ext-tommi.keisala@nokia.com>
Hi Tommi,
On Sat, Oct 23, 2010, Tommi Keisala wrote:
> ---
> src/manager.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
You seem to have somehow managed to screw up the commit message this
time: everything in the summary line and nothing in the message body.
Anyway, to avoid further feedback rounds (since the patch itself is fine
now) I went ahead and fixed the commit message and pushed your patch
upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/1] Fix small coding style issues
From: Johan Hedberg @ 2010-10-23 12:28 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1287775122-12536-1-git-send-email-epx@signove.com>
Hi Elvis,
On Fri, Oct 22, 2010, Elvis Pfützenreuter wrote:
> Based on http://lxr.linux.no/linux+v2.6.36/Documentation/CodingStyle#L171
> ---
> health/hdp_util.c | 24 +++++++++++++-----------
> health/mcap_lib.h | 8 ++++----
> 2 files changed, 17 insertions(+), 15 deletions(-)
Thanks, I've pushed the patch upstream. FWIW, The BlueZ code base
doesn't really enforce the kernel style rule of having braces for all
parts of if-else statements when at least one branch has them.
Johan
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Santiago Carot @ 2010-10-23 8:25 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <AANLkTimvQH4jA=AudrGA7Sj1vAFB3OjocOur2J2=Yy2f@mail.gmail.com>
Hi again,
2010/10/23 Santiago Carot <sancane@gmail.com>:
> Hi Elvis,
>
> 2010/10/23 Santiago Carot <sancane@gmail.com>:
>> Hi,
>>
>> 2010/10/22 Elvis Pfützenreuter <epx@signove.com>:
>>> Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
>>>
>>> I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
>>>
>>> The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
>>>
>>
>> You are forgetting that there may be more than one health applications
>> running over HDP at the same time, if one of them creates a data
>> channel, that data data channel will be exist at MCAP level even if
>> the initiator abort the connection. If other application wants to
>> create a new data channel with the same configuration, it may be want
>> reconnect that data channel avoiding to create another data channel.
>> It is a best practise wich is recomended in MCAP and best explained in
>> the Health Device Profile white paper document to reduce the amount of
>> data interchanged between medical devices (in IEEE/11073-20601
>> terminology: "agents" and "managers"). Remember that channels may be
>> shared between applications.
>>
>
> I found the example that I was trying to explain here in page 16 of
> the HDP whitepaper, there you can see two applications over HDP
> sharing the same data channel (one of them providing support to
> diferents device specializations).
>
Well, may be that above reference is not the best because in the
picture applications share the same MDEP too, but I think that it is
enough to see analogies.
>> That is the reason why HDP sends out a signal when a data channel has
>> been created.
>> Of course, the efficence of the protocol will depend on intelligence
>> of the programmer of the applications to take advantages of MCAP
>> reconnections. In any case, you will need to know when a data channel
>> has been created over the MCL (by you, or by other application).
>>
>> Regards,
>>
>> Santiago
>>
>
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Santiago Carot @ 2010-10-23 8:00 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <AANLkTi=65C7HQXQW1Bqbgf4sNY3wbV2CzqoENBc-b04g@mail.gmail.com>
Hi Elvis,
2010/10/23 Santiago Carot <sancane@gmail.com>:
> Hi,
>
> 2010/10/22 Elvis Pfützenreuter <epx@signove.com>:
>> Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
>>
>> I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
>>
>> The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
>>
>
> You are forgetting that there may be more than one health applications
> running over HDP at the same time, if one of them creates a data
> channel, that data data channel will be exist at MCAP level even if
> the initiator abort the connection. If other application wants to
> create a new data channel with the same configuration, it may be want
> reconnect that data channel avoiding to create another data channel.
> It is a best practise wich is recomended in MCAP and best explained in
> the Health Device Profile white paper document to reduce the amount of
> data interchanged between medical devices (in IEEE/11073-20601
> terminology: "agents" and "managers"). Remember that channels may be
> shared between applications.
>
I found the example that I was trying to explain here in page 16 of
the HDP whitepaper, there you can see two applications over HDP
sharing the same data channel (one of them providing support to
diferents device specializations).
> That is the reason why HDP sends out a signal when a data channel has
> been created.
> Of course, the efficence of the protocol will depend on intelligence
> of the programmer of the applications to take advantages of MCAP
> reconnections. In any case, you will need to know when a data channel
> has been created over the MCL (by you, or by other application).
>
> Regards,
>
> Santiago
>
^ permalink raw reply
* Re: (Health) ChannelConnected signal when MDL aborted?
From: Santiago Carot @ 2010-10-23 7:50 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <295EA951-2357-4B6B-B558-0B3F1D6FFDD9@signove.com>
Hi,
2010/10/22 Elvis Pfützenreuter <epx@signove.com>:
> Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
>
> I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
>
> The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
>
You are forgetting that there may be more than one health applications
running over HDP at the same time, if one of them creates a data
channel, that data data channel will be exist at MCAP level even if
the initiator abort the connection. If other application wants to
create a new data channel with the same configuration, it may be want
reconnect that data channel avoiding to create another data channel.
It is a best practise wich is recomended in MCAP and best explained in
the Health Device Profile white paper document to reduce the amount of
data interchanged between medical devices (in IEEE/11073-20601
terminology: "agents" and "managers"). Remember that channels may be
shared between applications.
That is the reason why HDP sends out a signal when a data channel has
been created.
Of course, the efficence of the protocol will depend on intelligence
of the programmer of the applications to take advantages of MCAP
reconnections. In any case, you will need to know when a data channel
has been created over the MCL (by you, or by other application).
Regards,
Santiago
^ permalink raw reply
* [PATCH] This patch avoids a crash when org.bluez.Manager GetProperties request is received and there is not yet any adapters ready. Happens often for example when bluetoothd and ofonod is started next ot each other.
From: Tommi Keisala @ 2010-10-23 5:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Tommi Keisala
In-Reply-To: <20101022131207.GA29655 () jh-x301>
---
src/manager.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/manager.c b/src/manager.c
index aff069c..dd9560f 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -197,13 +197,14 @@ static DBusMessage *get_properties(DBusConnection *conn,
DBUS_DICT_ENTRY_END_CHAR_AS_STRING, &dict);
array = g_new0(char *, g_slist_length(adapters) + 1);
- for (i = 0, list = adapters; list; list = list->next, i++) {
+ for (i = 0, list = adapters; list; list = list->next) {
struct btd_adapter *adapter = list->data;
if (!adapter_is_ready(adapter))
continue;
array[i] = (char *) adapter_get_path(adapter);
+ i++;
}
dict_append_array(&dict, "Adapters", DBUS_TYPE_OBJECT_PATH, &array, i);
g_free(array);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] This patch avoids a crash when org.bluez.Manager GetProperties request is
From: Tommi Keisala @ 2010-10-23 5:33 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20101022131207.GA29655 () jh-x301>
I made changes requested
^ permalink raw reply
* [PATCH 6/6] Bluetooth: simple SMP pairing negotiation
From: Anderson Briglia @ 2010-10-22 23:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
This implementation only exchanges SMP messages between the Host and the
Remote. No keys are being generated. TK and STK generation will be
provided in further patches.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/l2cap.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 114 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 2a88f23..be91a33 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4644,6 +4644,104 @@ done:
return 0;
}
+static void smp_cmd_pairing_req(struct l2cap_conn *conn, struct sk_buff *skb)
+{
+ struct smp_cmd_pairing *rp = (void *) skb->data;
+
+ BT_DBG("");
+
+ skb_pull(skb, sizeof(struct smp_cmd_pairing));
+
+ rp->io_capability = 0x00;
+ rp->oob_flag = 0x00;
+ rp->max_key_size = 16;
+ rp->init_key_dist = 0x00;
+ rp->resp_key_dist = 0x00;
+ rp->auth_req &= 0x05;
+
+ smp_send_cmd(conn, SMP_CMD_PAIRING_RSP, sizeof(*rp), rp);
+}
+
+static void smp_cmd_pairing_rsp(struct l2cap_conn *conn, struct sk_buff *skb)
+{
+ struct smp_cmd_pairing_confirm cp;
+
+ BT_DBG("");
+
+ memset(&cp, 0, sizeof(struct smp_cmd_pairing_confirm));
+
+ smp_send_cmd(conn, SMP_CMD_PAIRING_CONFIRM, sizeof(cp), &cp);
+}
+
+static void smp_cmd_pairing_confirm(struct l2cap_conn *conn,
+ struct sk_buff *skb)
+{
+ BT_DBG("");
+
+ if (conn->hcon->link_mode & HCI_LM_MASTER) {
+
+ struct smp_cmd_pairing_random random;
+
+ BT_DBG("master");
+
+ memset(&random, 0, sizeof(struct smp_cmd_pairing_random));
+
+ smp_send_cmd(conn, SMP_CMD_PAIRING_RANDOM, sizeof(random),
+ &random);
+ } else {
+ struct smp_cmd_pairing_confirm confirm;
+
+ BT_DBG("slave");
+
+ memset(&confirm, 0, sizeof(struct smp_cmd_pairing_confirm));
+
+ smp_send_cmd(conn, SMP_CMD_PAIRING_CONFIRM, sizeof(confirm),
+ &confirm);
+ }
+}
+
+static void smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
+{
+ struct smp_cmd_pairing_random cp;
+
+ BT_DBG("");
+
+ skb_pull(skb, sizeof(struct smp_cmd_pairing_random));
+
+ /* FIXME: check if random matches */
+
+ if (conn->hcon->link_mode & HCI_LM_MASTER) {
+ BT_DBG("master");
+ /* FIXME: start encryption */
+ } else {
+ BT_DBG("slave");
+
+ memset(&cp, 0, sizeof(struct smp_cmd_pairing_random));
+
+ smp_send_cmd(conn, SMP_CMD_PAIRING_RANDOM, sizeof(cp), &cp);
+ }
+}
+
+static void smp_cmd_security_req(struct l2cap_conn *conn, struct sk_buff *skb)
+{
+ struct smp_cmd_security_req *rp = (void *) skb->data;
+ struct smp_cmd_pairing cp;
+
+ BT_DBG("");
+
+ skb_pull(skb, sizeof(struct smp_cmd_security_req));
+ memset(&cp, 0, sizeof(struct smp_cmd_pairing));
+
+ cp.io_capability = 0x00;
+ cp.oob_flag = 0x00;
+ cp.max_key_size = 16;
+ cp.init_key_dist = 0x00;
+ cp.resp_key_dist = 0x00;
+ cp.auth_req = rp->auth_req & 0x05;
+
+ smp_send_cmd(conn, SMP_CMD_PAIRING_REQ, sizeof(cp), &cp);
+}
+
static inline void smp_sig_channel(struct l2cap_conn *conn, struct sk_buff *skb)
{
__u8 code = skb->data[0];
@@ -4651,25 +4749,37 @@ static inline void smp_sig_channel(struct l2cap_conn *conn, struct sk_buff *skb)
skb_pull(skb, 1);
+ BT_DBG("conn %p code 0x%2.2x", conn, code);
+
switch (code) {
case SMP_CMD_PAIRING_REQ:
- reason = SMP_PAIRING_NOTSUPP;
- smp_send_cmd(conn, SMP_CMD_PAIRING_FAIL, 1, &reason);
- l2cap_conn_del(conn->hcon, 0x05);
+ smp_cmd_pairing_req(conn, skb);
break;
case SMP_CMD_PAIRING_FAIL:
break;
case SMP_CMD_PAIRING_RSP:
+ smp_cmd_pairing_rsp(conn, skb);
+ break;
+
+ case SMP_CMD_SECURITY_REQ:
+ smp_cmd_security_req(conn, skb);
+ break;
+
case SMP_CMD_PAIRING_CONFIRM:
+ smp_cmd_pairing_confirm(conn, skb);
+ break;
+
case SMP_CMD_PAIRING_RANDOM:
+ smp_cmd_pairing_random(conn, skb);
+ break;
+
case SMP_CMD_ENCRYPT_INFO:
case SMP_CMD_MASTER_IDENT:
case SMP_CMD_IDENT_INFO:
case SMP_CMD_IDENT_ADDR_INFO:
case SMP_CMD_SIGN_INFO:
- case SMP_CMD_SECURITY_REQ:
default:
BT_DBG("Unknown command code 0x%2.2x", code);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/6] Bluetooth: Fix initiated LE connections
From: Anderson Briglia @ 2010-10-22 23:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Fix LE connections not being marked as master.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/hci_conn.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index c7309e4..1a48c6a 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -52,6 +52,7 @@ void hci_le_connect(struct hci_conn *conn)
conn->state = BT_CONNECT;
conn->out = 1;
+ conn->link_mode |= HCI_LM_MASTER;
memset(&cp, 0, sizeof(cp));
cp.scan_interval = cpu_to_le16(0x0004);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/6] Bluetooth: Start SMP procedure
From: Anderson Briglia @ 2010-10-22 23:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Briglia, Vinicius Costa Gomes
Start SMP procedure for LE connections. This modification intercepts l2cap
received frames and call proper SMP functions to start the SMP procedure. By
now, no keys are being used.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
---
net/bluetooth/l2cap.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index ba87c84..2a88f23 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -714,6 +714,8 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
l2cap_sock_clear_timer(sk);
sk->sk_state = BT_CONNECTED;
sk->sk_state_change(sk);
+ if (smp_conn_security(conn, l2cap_pi(sk)->sec_level))
+ BT_DBG("Insufficient security");
}
if (sk->sk_type != SOCK_SEQPACKET &&
@@ -4707,6 +4709,10 @@ static void l2cap_recv_frame(struct l2cap_conn *conn, struct sk_buff *skb)
l2cap_conless_channel(conn, psm, skb);
break;
+ case L2CAP_CID_SMP:
+ smp_sig_channel(conn, skb);
+ break;
+
default:
l2cap_data_channel(conn, cid, skb);
break;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/6] Bluetooth: Implement the first SMP commands
From: Anderson Briglia @ 2010-10-22 23:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
These simple commands will allow the SMP procedure to be started
and terminated with a not supported error. This is the first step
toward something useful.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/l2cap.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 117 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 1ac44f4..ba87c84 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -54,6 +54,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
#include <net/bluetooth/l2cap.h>
+#include <net/bluetooth/smp.h>
#define VERSION "2.15"
@@ -307,6 +308,85 @@ static void l2cap_chan_del(struct sock *sk, int err)
}
}
+static struct sk_buff *smp_build_cmd(struct l2cap_conn *conn, u8 code,
+ u16 dlen, void *data)
+{
+ struct sk_buff *skb;
+ struct l2cap_hdr *lh;
+ int len;
+
+ len = L2CAP_HDR_SIZE + 1 + dlen;
+
+ if (len > conn->mtu)
+ return NULL;
+
+ skb = bt_skb_alloc(len, GFP_ATOMIC);
+ if (!skb)
+ return NULL;
+
+ lh = (struct l2cap_hdr *) skb_put(skb, L2CAP_HDR_SIZE);
+ lh->len = cpu_to_le16(1 + dlen);
+ lh->cid = cpu_to_le16(L2CAP_CID_SMP);
+
+ memcpy(skb_put(skb, 1), &code, 1);
+
+ memcpy(skb_put(skb, dlen), data, dlen);
+
+ return skb;
+}
+
+static inline void smp_send_cmd(struct l2cap_conn *conn, u8 code, u16 len, void *data)
+{
+ struct sk_buff *skb = smp_build_cmd(conn, code, len, data);
+
+ BT_DBG("code 0x%2.2x", code);
+
+ if (!skb)
+ return;
+
+ hci_send_acl(conn->hcon, skb, 0);
+}
+
+static int smp_conn_security(struct l2cap_conn *conn, __u8 sec_level)
+{
+ __u8 authreq;
+
+ BT_DBG("conn %p hcon %p level 0x%2.2x", conn, conn->hcon, sec_level);
+
+ switch (sec_level) {
+ case BT_SECURITY_MEDIUM:
+ /* Encrypted, no MITM protection */
+ authreq = 0x01;
+ break;
+
+ case BT_SECURITY_HIGH:
+ /* Bonding, MITM protection */
+ authreq = 0x05;
+ break;
+
+ case BT_SECURITY_LOW:
+ default:
+ return 1;
+ }
+
+ if (conn->hcon->link_mode & HCI_LM_MASTER) {
+ struct smp_cmd_pairing cp;
+ cp.io_capability = 0x00;
+ cp.oob_flag = 0x00;
+ cp.max_key_size = 16;
+ cp.init_key_dist = 0x00;
+ cp.resp_key_dist = 0x00;
+ cp.auth_req = authreq;
+ smp_send_cmd(conn, SMP_CMD_PAIRING_REQ, sizeof(cp), &cp);
+ } else {
+ struct smp_cmd_security_req cp;
+ cp.auth_req = authreq;
+ smp_send_cmd(conn, SMP_CMD_SECURITY_REQ, sizeof(cp), &cp);
+ }
+
+ return 0;
+}
+
/* Service level security */
static inline int l2cap_check_security(struct sock *sk)
{
@@ -4562,6 +4642,43 @@ done:
return 0;
}
+static inline void smp_sig_channel(struct l2cap_conn *conn, struct sk_buff *skb)
+{
+ __u8 code = skb->data[0];
+ __u8 reason;
+
+ skb_pull(skb, 1);
+
+ switch (code) {
+ case SMP_CMD_PAIRING_REQ:
+ reason = SMP_PAIRING_NOTSUPP;
+ smp_send_cmd(conn, SMP_CMD_PAIRING_FAIL, 1, &reason);
+ l2cap_conn_del(conn->hcon, 0x05);
+ break;
+
+ case SMP_CMD_PAIRING_FAIL:
+ break;
+
+ case SMP_CMD_PAIRING_RSP:
+ case SMP_CMD_PAIRING_CONFIRM:
+ case SMP_CMD_PAIRING_RANDOM:
+ case SMP_CMD_ENCRYPT_INFO:
+ case SMP_CMD_MASTER_IDENT:
+ case SMP_CMD_IDENT_INFO:
+ case SMP_CMD_IDENT_ADDR_INFO:
+ case SMP_CMD_SIGN_INFO:
+ case SMP_CMD_SECURITY_REQ:
+ default:
+ BT_DBG("Unknown command code 0x%2.2x", code);
+
+ reason = SMP_CMD_NOTSUPP;
+ smp_send_cmd(conn, SMP_CMD_PAIRING_FAIL, 1, &reason);
+ l2cap_conn_del(conn->hcon, 0x05);
+ }
+
+ kfree_skb(skb);
+}
+
static void l2cap_recv_frame(struct l2cap_conn *conn, struct sk_buff *skb)
{
struct l2cap_hdr *lh = (void *) skb->data;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
From: Anderson Briglia @ 2010-10-22 23:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
As L2CAP packets coming over LE don't have any more encapsulation,
other than L2CAP, we are able to process them as soon as they arrive.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/l2cap.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 2bf083e..1ac44f4 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
{
struct l2cap_conn *conn = hcon->l2cap_data;
+ struct l2cap_hdr *hdr;
+ int len;
if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
goto drop;
BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
+ if (hcon->type == LE_LINK) {
+ hdr = (struct l2cap_hdr *) skb->data;
+ len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
+
+ if (len == skb->len) {
+ /* Complete frame received */
+ l2cap_recv_frame(conn, skb);
+ return 0;
+ }
+
+ goto drop;
+ }
+
if (flags & ACL_START) {
- struct l2cap_hdr *hdr;
struct sock *sk;
u16 cid;
- int len;
if (conn->rx_len) {
BT_ERR("Unexpected start frame (len %d)", skb->len);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/6] Bluetooth: Add SMP command structures
From: Anderson Briglia @ 2010-10-22 23:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
From: Ville Tervo <ville.tervo@nokia.com>
Add command structures for security manager protocol.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/smp.h | 76 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 include/net/bluetooth/smp.h
diff --git a/include/net/bluetooth/smp.h b/include/net/bluetooth/smp.h
new file mode 100644
index 0000000..8f2edbf
--- /dev/null
+++ b/include/net/bluetooth/smp.h
@@ -0,0 +1,76 @@
+#ifndef __SMP_H
+#define __SMP_H
+
+struct smp_command_hdr {
+ __u8 code;
+} __packed;
+
+#define SMP_CMD_PAIRING_REQ 0x01
+#define SMP_CMD_PAIRING_RSP 0x02
+struct smp_cmd_pairing {
+ __u8 io_capability;
+ __u8 oob_flag;
+ __u8 auth_req;
+ __u8 max_key_size;
+ __u8 init_key_dist;
+ __u8 resp_key_dist;
+} __packed;
+
+#define SMP_CMD_PAIRING_CONFIRM 0x03
+struct smp_cmd_pairing_confirm {
+ __u8 confirm_val[16];
+} __packed;
+
+#define SMP_CMD_PAIRING_RANDOM 0x04
+struct smp_cmd_pairing_random {
+ __u8 rand_val[16];
+} __packed;
+
+#define SMP_CMD_PAIRING_FAIL 0x05
+struct smp_cmd_pairing_fail {
+ __u8 reason;
+} __packed;
+
+#define SMP_CMD_ENCRYPT_INFO 0x06
+struct smp_cmd_encrypt_info {
+ __u8 ltk[16];
+} __packed;
+
+#define SMP_CMD_MASTER_IDENT 0x07
+struct smp_cmd_master_ident {
+ __u16 ediv;
+ __u8 rand[8];
+} __packed;
+
+#define SMP_CMD_IDENT_INFO 0x08
+struct smp_cmd_ident_info {
+ __u8 irk[16];
+} __packed;
+
+#define SMP_CMD_IDENT_ADDR_INFO 0x09
+struct smp_cmd_ident_addr_info {
+ __u8 addr_type;
+ bdaddr_t bdaddr;
+} __packed;
+
+#define SMP_CMD_SIGN_INFO 0x0a
+struct smp_cmd_sign_info {
+ __u8 csrk[16];
+} __packed;
+
+#define SMP_CMD_SECURITY_REQ 0x0b
+struct smp_cmd_security_req {
+ __u8 auth_req;
+} __packed;
+
+#define SMP_PASSKEY_ENTRY_FAILED 0x01
+#define SMP_OOB_NOT_AVAIL 0x02
+#define SMP_AUTH_REQUIREMENTS 0x03
+#define SMP_CONFIRM_FAILED 0x04
+#define SMP_PAIRING_NOTSUPP 0x05
+#define SMP_ENC_KEY_SIZE 0x06
+#define SMP_CMD_NOTSUPP 0x07
+#define SMP_UNSPECIFIED 0x08
+#define SMP_REPEATED_ATTEMPTS 0x09
+
+#endif /* __SMP_H */
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox