* Re: Problem with an Apple bluetooth keyboard
From: Daniel O'Connor @ 2011-03-05 2:00 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20110305005651.GC9005@joana>
On 05/03/2011, at 11:26, Gustavo F. Padovan wrote:
>> Is there some command I can run to re-probe it as a work around? Or perhaps some debugging I can enable to find out exactly what is going wrong.
>
> Send to us the output of "hciconfig -a" before you unplug the dongle.
Output is as follows:
hci0: Type: USB
BD Address: 00:10:DC:57:76:BE ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:689 acl:0 sco:0 events:22 errors:0
TX bytes:86 acl:0 sco:0 commands:22 errors:0
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'MythTV'
Class: 0x4a0000
Service Classes: Networking, Capturing, Telephony
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x110 LMP Ver: 1.1 (0x1) LMP Subver: 0x110
Manufacturer: Cambridge Silicon Radio (10)
Thanks.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
^ permalink raw reply
* Re: [PATCH] work around for l2cap NULL dereference in l2cap_conn_start
From: Gustavo F. Padovan @ 2011-03-05 2:12 UTC (permalink / raw)
To: David Fries
Cc: Liang Bao, Andrei Warkentin, linux-bluetooth, linux-kernel,
Feng Tang
In-Reply-To: <20110302061910.GE22204@spacedout.fries.net>
Hi David,
* David Fries <david@fries.net> [2011-03-02 00:19:10 -0600]:
> On Mon, Feb 28, 2011 at 02:30:22PM -0300, Gustavo F. Padovan wrote:
> > Hi David,
> >
> > * David Fries <david@fries.net> [2011-02-27 23:03:40 -0600]:
> >
> > > On Sun, Feb 27, 2011 at 04:15:45PM -0300, Gustavo F. Padovan wrote:
> > > > I pushed the following patch to bluetooth-2.6 tree. It should fix the problem
> > > > by avoiding connections to be accepted before a L2CAP info response comes:
> > >
> > > Is
> > > git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> > > the bluetooth-2.6 tree you mentioned? I don't see your patch there.
> > > As a side note, the inline patch in your e-mail has the tabs replaced by
> > > spaces, once I changed them, it applied cleanly.
> > >
> > > I first reverted to the base N900 kernel-power-2.6.28 46 (none of my
> > > changes or debugging), it crashed as expected. I then applied your
> > > patch 743400e0, and it still crashed. I added back the
> > > l2cap_conn_start parent check and some debugging in af_bluetooth.c
> > > dmesg debug output and patches follow.
> >
> > I want to see a test with this patch and a recent kernel. We added many fixes
> > to stack in the last two years. Can you test this scenario?
>
> I'm sorry, but apparently not, at least this post says 2.6.37 isn't
> going to happen for the N900 and Maemo.
> http://forums.internettablettalk.com/showthread.php?t=70082
>
> I tried 2.6.37-n900 from
> git://gitorious.org/nokia-n900-kernel/nokia-n900-kernel.git anyway,
> but the display visibly degrades like it isn't being updated and
> doesn't apparently get any further. I don't have anyway to debug it
> further.
I think you can test this in a desktop machine.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* hci_conn_timeout
From: Koustuv Ghosh @ 2011-03-05 7:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Koustuv Ghosh
Hello ,
I am using vcgomes kernel for LE .
I observed two thing...
once I issue LE connect via gatttool(bluez-4.88) from my host ,
after 2 or 3s I
am geeting a hci_conn_timeout, which causes existing LE connection
disconnected.
So I noticed there is a hci_conn_hold(conn) which I feel basically
deactivate the timer, and as a work around I introduced it in
hci_le_conn_complete_evt ,and after that disconnect time out does
not occur.
But then if I am trying to connect remote device via gatttool with
same parameter twice , system hangs.
Any help...
rgds
Koustuv
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: Initial release for Bluetooth init script
From: Pavan Savoy @ 2011-03-05 8:17 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Gery Kahn, David Woodhouse, linux-wireless, linux-bluetooth,
Luciano Coelho
In-Reply-To: <AANLkTimkoaZqn9SDEuc=vuazzqwA7Jrmz1hiwDWSXhM2@mail.gmail.com>
On Sat, Mar 5, 2011 at 5:04 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Hi Pavan,
>
> On Thu, Mar 3, 2011 at 3:44 PM, Pavan Savoy <pavan_savoy@ti.com> wrote:
>> On Wed, Mar 2, 2011 at 8:01 PM, Gery Kahn <gery.kahn@gmail.com> wrote:
> ...
>> Can we name this in all smaller case?
>
> How is this going to work with smaller case ?
No, Not right away - Since every release the firmware team makes, it
does that by naming it in CamelCase.
So, I was thinking while putting up each new firmware on /lib/ may be
we can make it smaller case - like other firmware....
> AFAICS, Gery used the exact name format that st_kim is looking for:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/misc/ti-st/st_kim.c;h=73b6c8b0e8696db9dbe8a71590bf7b62fb3b5532;hb=HEAD#l261
>
> Do you plan to change st_kim ?
>
> If so, please first change it, and then update the firmware file.
So, yes in case the firmware is going to be freely available from
now-onwards - will post a patch to expect smaller case file name.
Thanks,
Pavan
> Thanks,
> Ohad.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: updating unacked_frames counter during retransmission
From: Suraj Sumangala @ 2011-03-05 8:51 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <20110305005309.GB9005@joana>
Hi Gustavo,
On 3/5/2011 6:23 AM, Gustavo F. Padovan wrote:
> Hi Suraj,
>
> * Suraj Sumangala<suraj@Atheros.com> [2011-03-03 12:00:35 +0530]:
>
>> Hi Gustavo,
>>
>> I have a question regarding the ERTM implementation.
>>
>> Should we be incrementing the "l2cap_pinfo.unacked_frames" variable if
>> we are retransmitting a frame?
>
> No, if we are retransmitting a frame that means L2CAP didn't received an ack
> for it and we are already accounting it in unacked_frames and there is no need
> to increment unacked_frames in this case.
I think right now we are incrementing the "l2cap_pinfo.unacked_frames"
for retransmission also.
>
>>
>> Won't this cause the same frame to be accounted twice?
>>
>> If there are too many retransmissions, will there be a chance that
>> "unacked_frames" could cross 0xFF and over flow.
>
> No, unacked_frames number is limited by the remote transmission window size.
>
Actually, I am seeing an overflow (crossing the remote transmit window)
issue, when there is retransmission. This was found in older kernel(2.6.35).
So not sure if this is valid in the latest kernel. Will anyway try to
send a patch for the same.
Regards
Suraj
^ permalink raw reply
* Re: [PATCH v2] linux-firmware: Initial release for Bluetooth init script
From: Ohad Ben-Cohen @ 2011-03-05 9:15 UTC (permalink / raw)
To: Pavan Savoy
Cc: Gery Kahn, David Woodhouse, linux-wireless, linux-bluetooth,
Luciano Coelho
In-Reply-To: <AANLkTi=fRXHWVeZpR1X5pGAZjPGTt84ZPo1kWkPQhZps@mail.gmail.com>
On Sat, Mar 5, 2011 at 10:17 AM, Pavan Savoy <pavan_savoy@ti.com> wrote:
> So, yes in case the firmware is going to be freely available from
> now-onwards - will post a patch to expect smaller case file name.
Well, right now we have users of st_kim, and we prefer using the
firmware name that is currently expected by it. Otherwise it just
won't work..
I understand the the lower case affinity, but that's second to not
breaking the user experience IMHO.
Thanks,
Ohad.
^ permalink raw reply
* Re: HCI core error recovery.
From: Andrei Warkentin @ 2011-03-05 10:03 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTing8htA_TSLQ7ScxC0+KGAo+nHZ+6Amiyet7d5-@mail.gmail.com>
On Sun, Feb 27, 2011 at 5:30 AM, Andrei Warkentin <andreiw@motorola.com> wrote:
> On Fri, Feb 18, 2011 at 2:21 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
>> On Mon, Feb 14, 2011 at 4:23 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
>>> On Sat, Feb 12, 2011 at 12:47 AM, Andrei Warkentin <andreiw@motorola.com> wrote:
>>>> On Fri, Feb 11, 2011 at 5:07 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
>>>>> Dear List,
>>>>>
>>>>> I've run into an interesting problem. Excuse me in advance if this was
>>>>> already covered here, or for my explanations, since I'm not too
>>>>> familiar with overall flow within BlueZ or Bluetooth specifics...
>>>>> We've had some hardware config issues that resulted in garbage/malformed
>>>>> messages arriving via H4 into the HCI layer. We've since resolved
>>>>> these, but it got me thinking. The issues would result in certain HCI
>>>>> messages being missed, including occasionally disconnect events being
>>>>> missed, and a subsequent connect event would result in a double add.
>>>>>
>>>>> I was thinking about how to fix at the very least the crash. The sysfs
>>>>> object is created as a last step after getting a "connection
>>>>> completed" HCI message, I think. What I am unsure about is if it's
>>>>> safe to just ignore the add if there is already a sysfs entry...
>>>>>
>>>>> So I would think the HCI core needs some resiliency against
>>>>> bad/malignant bluetooth controllers, and perform error
>>>>> recovery/resynchronization. Perhaps maybe there is room for a virtual
>>>>> hci controller that just injects various message types to see how well
>>>>> the core can cope?
>>>>>
>>>>> Thanks in advance,
>>>>> A
>>>>
>>>> To further explain the issue, here is what was happening -
>>>>
>>>> 0) A BT device is paired.
>>>> 1) Host goes into sleep mode.
>>>> 2) BT device turns off.
>>>> 3) Host wakes up due to BT waking the host. Due to UART resume issues,
>>>> HCI message corrupted. hci_disconn_complete_evt never gets called.
>>>> 4) BT device turns on.
>>>> 5) devref gets incremented in hci_conn_complete_evt, and is now 2.
>>>> 6) BT device turns off. hci_disconn_complete_evt is called, conn hash
>>>> is deleted, but sysfs entry not cleaned up since
>>>> atomic_dec_and_test(&conn->devref) != 0.
>>>> 7) BT device turns on. sysfs add fails since it never was cleaned up.
>>>>
>>>> The attached patch takes care of that. I'm not too familiar with BlueZ
>>>> (or bluetooth :-(), so I would like your feedback. In particular, I am
>>>> unsure about sync connections.
>>>> The primary issue overall is that HCI core doesn't handle HCI issues
>>>> (whether caused by transport issues, or bad/malicious BT controller).
>>>> I am curious if there are other ways to break the core.
>>>>
>>>> Thanks,
>>>> A
>>>>
>>>
>>> Anyone?
>>>
>>
>> Anyone? Who should I talk to about HCI?
>>
>
> Anyone pretty please :)? I'm positive what I'm doing isn't necessarily
> right, but I do think this is a real issue in current BlueZ code that
> needs work. HCI core should be more resilient to HCI transport issues,
> after all, the BT HCI spec does mandate specific behavior.
>
> A
>
Anyone? I mean anyone can literally craft a malicious usb device that
will act like a bluetooth controller and crash the OS... Nobody is at
all interested?
A
^ permalink raw reply
* Re: how to set adapter to master with bluez 4.69?
From: Brian J. Murrell @ 2011-03-06 22:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <4D6EF7ED.2090905@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 347 bytes --]
On 11-03-02 09:07 PM, Brian J. Murrell wrote:
> Per the thread at
> http://permalink.gmane.org/gmane.linux.bluez.kernel/11455 it appears
> that I need to ensure that my B/T adapter is the master in the piconet.
Nobody knows? I was hoping this was going to be one of those simple
questions that just about everybody knew. :-(
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: how to set adapter to master with bluez 4.69?
From: Brad Midgley @ 2011-03-07 1:08 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: linux-bluetooth
In-Reply-To: <4D740AA7.5080209@interlinx.bc.ca>
Brian,
> Nobody knows? I was hoping this was going to be one of those simple
> questions that just about everybody knew. :-(
It has been really quiet.
I got the latest bluez and looked through doc/ and test/ for
references to link mode. I think maybe mentions of L2CAP_LM_MASTER in
test/l2test.c might be on the right track. You could probably follow
that model and set the l2cap link mode to get what you want. I didn't
see it in any gui I could find. A patch to a gui would be ambitious
but would end up being the nicest user experience in the end.
--
Brad Midgley
^ permalink raw reply
* Re: re "bluetooth disabled" and "[BUG] usb problems in .38-rc3+"
From: Mikko Vinni @ 2011-03-07 19:50 UTC (permalink / raw)
To: Johan Hedberg
Cc: linux-bluetooth, Justin P. Mattock, Ed Tomlinson,
Gustavo F. Padovan
In-Reply-To: <20110303143154.GA2342@jh-x301>
Hi,
Johan Hedberg wrote:
> In any case what's happening is that there's never a command complete
> for the local features. This is one of those commands that user space
> tracks to determine that the adapter is initialized so if it never comes
> the adapter remains uninitialized from a bluetoothd perspective. There
> is supposed to be some work-around code in bluetoothd for this kind of
> situations, but due to the patch you found in the kernel the code
> doesn't get triggered since the "up" flag is not set when the situation
> happens. The patch I've attached removed this check for the flag. Could
> you try and see if it helps?
I compiled bluez 4.89-71-gdc920af from git, which seems to contain the
patch that was as an attachment (9bae9813abf29344cc3d84af2ee59efd9e9e78fc).
It sometimes helps, but not always. Maybe there are some alternative code
paths, races, or something. Below some logs for a case when it doesn't
help. Also, it doesn't seem to work when bluetoothd is started before
plugging in the adapter or if the adapter is unplugged and replugged.
adapter in; start hcidump; start self-compiled bluetoothd
hcidump log ("hcidump -a" ran around 21.27.30):
HCI sniffer - Bluetooth packet analyzer ver 2.0
btsnoop version: 1 datalink type: 1002
2011-03-07 21:27:08.891188 < HCI Command: Reset (0x03|0x0003) plen 0
2011-03-07 21:27:08.891722 > HCI Event: Command Status (0x0f) plen 4
Unknown (0x00|0x0000) status 0x00 ncmd 1
2011-03-07 21:27:08.891747 < HCI Command: Read Local Supported Features
(0x04|0x0003) plen 0
2011-03-07 21:27:09.029713 > HCI Event: Command Complete (0x0e) plen 4
Reset (0x03|0x0003) ncmd 1
status 0x00
2011-03-07 21:27:09.029785 < HCI Command: Read Local Version Information
(0x04|0x0001) plen 0
2011-03-07 21:27:09.033720 > HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 2.0 (0x3) HCI Revision: 0x7a6
LMP Version: 2.0 (0x3) LMP Subversion: 0x7a6
Manufacturer: Cambridge Silicon Radio (10)
2011-03-07 21:27:09.033767 < HCI Command: Read Buffer Size (0x04|0x0005) plen 0
2011-03-07 21:27:09.037700 > HCI Event: Command Complete (0x0e) plen 11
Read Buffer Size (0x04|0x0005) ncmd 1
status 0x00
ACL MTU 384:8 SCO MTU 64:8
2011-03-07 21:27:09.037726 < HCI Command: Read BD ADDR (0x04|0x0009) plen 0
2011-03-07 21:27:09.040717 > HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
status 0x00 bdaddr 00:0D:3C:38:FA:B5
2011-03-07 21:27:09.040756 < HCI Command: Read Class of Device (0x03|0x0023)
plen 0
2011-03-07 21:27:09.043704 > HCI Event: Command Complete (0x0e) plen 7
Read Class of Device (0x03|0x0023) ncmd 1
status 0x00 class 0x000000
2011-03-07 21:27:09.043741 < HCI Command: Read Local Name (0x03|0x0014) plen 0
2011-03-07 21:27:09.078711 > HCI Event: Command Complete (0x0e) plen 252
Read Local Name (0x03|0x0014) ncmd 1
status 0x00 name 'CSR - bc4'
2011-03-07 21:27:09.078749 < HCI Command: Read Voice Setting (0x03|0x0025) plen
0
2011-03-07 21:27:09.081733 > HCI Event: Command Complete (0x0e) plen 6
Read Voice Setting (0x03|0x0025) ncmd 1
status 0x00 voice setting 0x0060
2011-03-07 21:27:09.081764 < HCI Command: Set Event Filter (0x03|0x0005) plen 1
type 0 condition 0
Clear all filters
2011-03-07 21:27:09.084712 > HCI Event: Command Complete (0x0e) plen 4
Set Event Filter (0x03|0x0005) ncmd 1
status 0x00
2011-03-07 21:27:09.084738 < HCI Command: Write Page Timeout (0x03|0x0018) plen
2
timeout 32768
2011-03-07 21:27:09.087703 > HCI Event: Command Complete (0x0e) plen 4
Write Page Timeout (0x03|0x0018) ncmd 1
status 0x00
2011-03-07 21:27:09.087726 < HCI Command: Write Connection Accept Timeout
(0x03|0x0016) plen 2
timeout 32000
2011-03-07 21:27:09.090699 > HCI Event: Command Complete (0x0e) plen 4
Write Connection Accept Timeout (0x03|0x0016) ncmd 1
status 0x00
2011-03-07 21:27:09.091818 < HCI Command: Write Page Timeout (0x03|0x0018) plen
2
timeout 8192
2011-03-07 21:27:09.094704 > HCI Event: Command Complete (0x0e) plen 4
Write Page Timeout (0x03|0x0018) ncmd 1
status 0x00
2011-03-07 21:27:09.094758 < HCI Command: Read Stored Link Key (0x03|0x000d)
plen 7
bdaddr 00:00:00:00:00:00 all 1
2011-03-07 21:27:09.098714 > HCI Event: Command Complete (0x0e) plen 8
Read Stored Link Key (0x03|0x000d) ncmd 1
status 0x00 max 16 num 0
2011-03-07 21:27:33.036962 < HCI Command: Read Local Name (0x03|0x0014) plen 0
2011-03-07 21:27:33.088144 > HCI Event: Command Complete (0x0e) plen 252
Read Local Name (0x03|0x0014) ncmd 1
status 0x00 name 'CSR - bc4'
2011-03-07 21:27:33.088386 < HCI Command: Read Class of Device (0x03|0x0023)
plen 0
2011-03-07 21:27:33.091152 > HCI Event: Command Complete (0x0e) plen 7
Read Class of Device (0x03|0x0023) ncmd 1
status 0x00 class 0x000000
2011-03-07 21:27:33.091181 < HCI Command: Read Local Supported Features
(0x04|0x0003) plen 0
2011-03-07 21:27:33.094151 > HCI Event: Command Complete (0x0e) plen 12
Read Local Supported Features (0x04|0x0003) ncmd 1
status 0x00
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
2011-03-07 21:27:33.094175 < HCI Command: Read Local Version Information
(0x04|0x0001) plen 0
2011-03-07 21:27:33.098150 > HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 2.0 (0x3) HCI Revision: 0x7a6
LMP Version: 2.0 (0x3) LMP Subversion: 0x7a6
Manufacturer: Cambridge Silicon Radio (10)
2011-03-07 21:27:33.150368 < HCI Command: Set Event Mask (0x03|0x0001) plen 8
Mask: 0xfffffbff07180000
2011-03-07 21:27:33.153142 > HCI Event: Command Complete (0x0e) plen 4
Set Event Mask (0x03|0x0001) ncmd 1
status 0x00
2011-03-07 21:27:33.153176 < HCI Command: Write Inquiry Mode (0x03|0x0045) plen
1
mode 1
2011-03-07 21:27:33.156136 > HCI Event: Command Complete (0x0e) plen 4
Write Inquiry Mode (0x03|0x0045) ncmd 1
status 0x00
2011-03-07 21:27:33.156168 < HCI Command: Write Default Link Policy Settings
(0x02|0x000f) plen 2
policy 0x0f
Link policy: RSWITCH HOLD SNIFF PARK
2011-03-07 21:27:33.159136 > HCI Event: Command Complete (0x0e) plen 4
Write Default Link Policy Settings (0x02|0x000f) ncmd 1
status 0x00
2011-03-07 21:27:33.159163 < HCI Command: Write Local Name (0x03|0x0013) plen
248
name 'koni-0'
2011-03-07 21:27:33.162140 > HCI Event: Command Complete (0x0e) plen 4
Write Local Name (0x03|0x0013) ncmd 1
status 0x00
2011-03-07 21:27:33.162167 < HCI Command: Write Class of Device (0x03|0x0024)
plen 3
class 0x480100
2011-03-07 21:27:33.165143 > HCI Event: Command Complete (0x0e) plen 4
Write Class of Device (0x03|0x0024) ncmd 1
status 0x00
2011-03-07 21:27:33.165180 < HCI Command: Write Scan Enable (0x03|0x001a) plen 1
enable 3
2011-03-07 21:27:33.169143 > HCI Event: Command Complete (0x0e) plen 4
Write Scan Enable (0x03|0x001a) ncmd 1
status 0x00
2011-03-07 21:27:33.169175 < HCI Command: Read Local Name (0x03|0x0014) plen 0
2011-03-07 21:27:33.190186 > HCI Event: Command Complete (0x0e) plen 252
Read Local Name (0x03|0x0014) ncmd 1
status 0x00 name 'koni-0'
2011-03-07 21:27:33.190246 < HCI Command: Read Scan Enable (0x03|0x0019) plen 0
2011-03-07 21:27:33.193155 > HCI Event: Command Complete (0x0e) plen 5
Read Scan Enable (0x03|0x0019) ncmd 1
status 0x00 enable 3
2011-03-07 21:27:50.114574 < HCI Command: Reset (0x03|0x0003) plen 0
syslog:
Mar 7 21:26:47 koni kernel: usb 5-3: New USB device found, idVendor=13dd,
idProduct=0001
Mar 7 21:26:47 koni kernel: usb 5-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
Mar 7 21:26:47 koni kernel: usb 5-3: Product: BlueCON U2
Mar 7 21:26:47 koni kernel: usb 5-3: Manufacturer: i.Tech Dynamic
Mar 7 21:27:08 koni bluetoothd[18369]: Bluetooth deamon 4.89
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() parsing
main.conf
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() discovto=0
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() pairto=0
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() pageto=8192
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() name=%h-%d
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() class=0x000100
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config()
discov_interval=0
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:parse_config() Key file does
not have key 'DeviceID'
Mar 7 21:27:08 koni bluetoothd[18369]: Starting SDP server
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:plugin_init() Loading
builtin plugins
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading audio
plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading input
plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading serial
plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading
network plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading
service plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading attrib
plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading health
plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading hciops
plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading
mgmtops plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading
formfactor plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:add_plugin() Loading
storage plugin
Mar 7 21:27:08 koni bluetoothd[18369]: src/plugin.c:plugin_init() Loading
plugins /usr/lib/bluetooth/plugins
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/service.c:register_interface()
path /org/bluez/18369/any
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/service.c:register_interface()
Registered interface org.bluez.Service on path /org/bluez/18369/any
Mar 7 21:27:08 koni bluetoothd[18369]: health/hdp.c:hdp_manager_start()
Starting Health manager
Mar 7 21:27:08 koni bluetoothd[18369]: network/manager.c:read_config()
/etc/bluetooth/network.conf: Key file does not have key 'DisableSecurity'
Mar 7 21:27:08 koni bluetoothd[18369]: network/manager.c:read_config() Config
options: Security=true
Mar 7 21:27:08 koni bluetoothd[18369]: input/manager.c:input_manager_init()
input.conf: Key file does not have key 'IdleTimeout'
Mar 7 21:27:08 koni bluetoothd[18369]: audio/manager.c:audio_manager_init()
audio.conf: Key file does not have key 'AutoConnect'
Mar 7 21:27:08 koni bluetoothd[18369]: audio/unix.c:unix_init() Unix socket
created: 8
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/hciops.c:hciops_init()
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/hciops.c:hciops_setup()
Mar 7 21:27:08 koni bluetoothd[18369]: src/main.c:main() Entering main loop
Mar 7 21:27:08 koni kernel: Bluetooth: SCO (Voice Link) ver 0.6
Mar 7 21:27:08 koni kernel: Bluetooth: SCO socket layer initialized
Mar 7 21:27:08 koni bluetoothd[18369]: src/rfkill.c:rfkill_event() RFKILL event
idx 0 type 1 op 0 soft 0 hard 0
Mar 7 21:27:08 koni bluetoothd[18369]: src/rfkill.c:rfkill_event() RFKILL event
idx 16 type 2 op 0 soft 0 hard 0
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/hciops.c:init_known_adapters()
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/hciops.c:init_device() hci0
Mar 7 21:27:08 koni bluetoothd[18369]: Listening for HCI events on hci0
Mar 7 21:27:08 koni bluetoothd[18369]: plugins/hciops.c:init_device() child
18372 forked
Mar 7 21:27:09 koni bluetoothd[18369]:
plugins/hciops.c:read_local_version_complete() Got version for hci0
Mar 7 21:27:09 koni bluetoothd[18369]: plugins/hciops.c:read_bd_addr_complete()
hci0 status 0
Mar 7 21:27:09 koni bluetoothd[18369]: plugins/hciops.c:read_bd_addr_complete()
Got bdaddr for hci0
Mar 7 21:27:09 koni bluetoothd[18369]:
plugins/hciops.c:read_local_name_complete() hci0 status 0
Mar 7 21:27:09 koni bluetoothd[18369]:
plugins/hciops.c:read_local_name_complete() Got name for hci0
Mar 7 21:27:09 koni bluetoothd[18369]: plugins/hciops.c:child_exit() child
18372 exited
Mar 7 21:27:09 koni bluetoothd[18369]: HCI dev 0 up
Mar 7 21:27:09 koni bluetoothd[18369]: plugins/hciops.c:device_devup_setup()
hci0
Mar 7 21:27:33 koni bluetoothd[18369]:
plugins/hciops.c:read_local_name_complete() hci0 status 0
Mar 7 21:27:33 koni bluetoothd[18369]:
plugins/hciops.c:read_local_name_complete() Got name for hci0
Mar 7 21:27:33 koni bluetoothd[18369]:
plugins/hciops.c:read_local_features_complete() Got features for hci0
Mar 7 21:27:33 koni bluetoothd[18369]: src/adapter.c:btd_adapter_ref()
0x7f28f49b3800: ref=1
Mar 7 21:27:33 koni bluetoothd[18369]: plugins/hciops.c:hciops_read_bdaddr()
hci0
...
Mikko
^ permalink raw reply
* Re: [PATCHv2 2/5] Initial Client Characteristic Configuration implementation
From: Peter Dons Tychsen @ 2011-03-07 20:52 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Anderson Lizardo, linux-bluetooth
In-Reply-To: <20110223032608.GE16014@jh-x301>
Hi,
On Wed, 2011-02-23 at 00:26 -0300, Johan Hedberg wrote:
> On Tue, Feb 22, 2011, Anderson Lizardo wrote:
> > +static uint8_t client_set_notifications(struct attribute *attr,
> > + gpointer
> user_data)
> > +{
> > + struct gatt_channel *channel = user_data;
> > + struct attribute *a, *last_chr_val = NULL;
> > + uint16_t handle, cfg_val;
> > + uuid_t uuid;
> > + GSList *l;
> > +
> > + cfg_val = att_get_u16(attr->data);
> > +
> > + sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
> > + for (l = database, handle = 0; l != NULL; l = l->next) {
> > + a = l->data;
>
> The variable "a" is only used inside the for-loop so it should be
> declared inside it as well. I think you can move handle inside the
> loop
> as well as long as you declare it static (so it only gets initialized
> to
> 0 on the first iteration).
Would that not be a waste? Declaring it static would place it in
global-space. IMHO local variables must never be static, unless there
really is a need for it. For embedded devices with less memory, to many
of such constructs would be considered a problem.
Putting it inside or outside the loops makes no difference with most
compilers as the optimizer will figure it out anyway (to the code, not
the style), but putting static in front will change the output and will
lower the global memory available. And since the number of used
instructions most likely will be the same, putting static in front will
at best be a waste.
Thanks,
/pedro
^ permalink raw reply
* Re: how to set adapter to master with bluez 4.69?
From: Brian J. Murrell @ 2011-03-07 21:13 UTC (permalink / raw)
To: public-linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTin3-+9txbUyFxyrirySnkjwWVeMHrZtCqGfz-4m@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
On 11-03-06 08:08 PM, Brad Midgley wrote:
> Brian,
Hi Brad,
> It has been really quiet.
Indeed.
> I got the latest bluez and looked through doc/ and test/ for
> references to link mode. I think maybe mentions of L2CAP_LM_MASTER in
> test/l2test.c might be on the right track.
OK.
> You could probably follow
> that model and set the l2cap link mode to get what you want. I didn't
> see it in any gui I could find. A patch to a gui would be ambitious
> but would end up being the nicest user experience in the end.
Agreed. Unfortunately, unlike quite a bit of technology, I am a total
end-user of B/T. I don't even really know what the stack looks like. I
guess I just have not had the bandwidth to dive in.
That said, it seems odd that without a knob to give total control to the
user, that the implicit behavior is not to make the adapter the master,
if it can be.
Understood, yes, that there might be a situation such as B/T networking
where there are two hosts with adapters, so one would have to fall back,
but for the more common case such as mice, headsets, etc. if the adapter
needs to be master for them to co-exist peacefully, I wonder why that's
not being done implicitly.
Can in inquire from userspace which devices are master/slave? hcitool
looks interesting but I can't seem to get it to report master/slave of
devices or the local adapter.
Ahhh. Wait. I just did (after turning the mouse on):
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
So it seems the mouse, which is the only remote device that's on, is master.
When I try to change that I get:
$ sudo hcitool sr 00:1F:20:0F:30:6A slave
Switch role request failed: Input/output error
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: how to set adapter to master with bluez 4.69?
From: Andrei Warkentin @ 2011-03-07 22:57 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: public-linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D754A84.1020609@interlinx.bc.ca>
On Mon, Mar 7, 2011 at 3:13 PM, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> On 11-03-06 08:08 PM, Brad Midgley wrote:
>> Brian,
>
> Hi Brad,
>
>> It has been really quiet.
>
> Indeed.
>
Does that mean I really should be posting to LKML for patch RFCs? To
get more eyes, hopefully?
>> I got the latest bluez and looked through doc/ and test/ for
>> references to link mode. I think maybe mentions of L2CAP_LM_MASTER in
>> test/l2test.c might be on the right track.
>
> OK.
>
>> You could probably follow
>> that model and set the l2cap link mode to get what you want. I didn't
>> see it in any gui I could find. A patch to a gui would be ambitious
>> but would end up being the nicest user experience in the end.
>
> Agreed. Unfortunately, unlike quite a bit of technology, I am a total
> end-user of B/T. I don't even really know what the stack looks like. I
> guess I just have not had the bandwidth to dive in.
>
> That said, it seems odd that without a knob to give total control to the
> user, that the implicit behavior is not to make the adapter the master,
> if it can be.
>
> Understood, yes, that there might be a situation such as B/T networking
> where there are two hosts with adapters, so one would have to fall back,
> but for the more common case such as mice, headsets, etc. if the adapter
> needs to be master for them to co-exist peacefully, I wonder why that's
> not being done implicitly.
>
> Can in inquire from userspace which devices are master/slave? hcitool
> looks interesting but I can't seem to get it to report master/slave of
> devices or the local adapter.
>
> Ahhh. Wait. I just did (after turning the mouse on):
>
> $ hcitool con
> Connections:
> > ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
>
> So it seems the mouse, which is the only remote device that's on, is master.
>
> When I try to change that I get:
>
> $ sudo hcitool sr 00:1F:20:0F:30:6A slave
> Switch role request failed: Input/output error
>
> b.
>
>
>
>
What do you get for hcitool info 00:1F:20:0F:30:6A?
^ permalink raw reply
* Re: how to set adapter to master with bluez 4.69?
From: Brad Midgley @ 2011-03-07 23:09 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: public-linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D754A84.1020609@interlinx.bc.ca>
Brian
> $ hcitool con
> Connections:
> > ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
>
> So it seems the mouse, which is the only remote device that's on, is master.
>
> When I try to change that I get:
>
> $ sudo hcitool sr 00:1F:20:0F:30:6A slave
> Switch role request failed: Input/output error
iirc, the remote device can deny a role switch. try the situation you
want, changing to master.
I think we can work this up. We need a new checkbox in bluez-gnome's
properties/general.c I think.
--
Brad Midgley
^ permalink raw reply
* Re: [PATCH] Adjust prefix of contact id for getting pb size
From: Johan Hedberg @ 2011-03-08 9:41 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1298901223-8313-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Mon, Feb 28, 2011, Rafal Michalski wrote:
> Getting phonebook size is related to recognizing contacts by their id
> prefixes. Previously it was "contact: " and has been changed to
> "urn:uuid:". This patch fixes it and allows to get valid phonebook size.
> ---
> plugins/phonebook-tracker.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
I seem to have missed this one. It's now pushed upstream.
Johan
^ permalink raw reply
* [PATCH] Fix "possible circular locking dependency" in rfcomm
From: Ferraton, Jean RegisX @ 2011-03-08 10:10 UTC (permalink / raw)
To: marcel@holtmann.org, davem@davemloft.net, eric.dumazet@gmail.com,
xiaosuo@gmail.com, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Changes in sock.c in function __rfcomm_sock_close, to release sock before c=
alling rfcomm_dlc_close to avoid possible deadlock when calling rfcomm_lock=
(in rfcomm_dlc_close).
Signed-off-by: Jean Regis Ferraton <jrferraton@gmail.com>
---
net/bluetooth/rfcomm/sock.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 66cc1f0..3b5ec09 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -234,7 +234,10 @@ static void __rfcomm_sock_close(struct sock *sk)
case BT_CONNECT2:
case BT_CONFIG:
case BT_CONNECTED:
+ /* release_sock to avoid deadlock when calling rfcomm_lock() */
+ release_sock(sk);
rfcomm_dlc_close(d, 0);
+ lock_sock(sk);
=20
default:
sock_set_flag(sk, SOCK_ZAPPED);
--=20
1.6.2.5
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,=20
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: how to set adapter to master with bluez 4.69?
From: Brian J. Murrell @ 2011-03-08 11:08 UTC (permalink / raw)
To: Andrei Warkentin; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikbv=9T3t_Y6LO4faqC5k1X_usWYH8ghmt8TGHV@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On 11-03-07 05:57 PM, Andrei Warkentin wrote:
>
> What do you get for hcitool info 00:1F:20:0F:30:6A?
$ hcitool info 00:1F:20:0F:30:6A
Requesting information ...
BD Address: 00:1F:20:0F:30:6A
Device Name: Bluetooth Laser Travel Mouse
LMP Version: 2.0 (0x3) LMP Subversion: 0x229
Manufacturer: Broadcom Corporation (15)
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <AFH cap. slave>
Cheers,
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [PATCH] Increase AVDTP request timeout
From: Daniel Örstadius @ 2011-03-08 13:18 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Increase-AVDTP-request-timeout.patch --]
[-- Type: text/x-patch, Size: 921 bytes --]
From 4a2c3e973dd417d289bd87dd2fece8b0c42bcb52 Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Tue, 8 Mar 2011 14:33:55 +0200
Subject: [PATCH] Increase AVDTP request timeout
At least one headset with both A2DP and PBAP sends delayed responses
to AVDTP requests when it is doing PBAP queries (typically at the
beginning of the connection).
Increasing the timer by two seconds to give the headset more time to
reply, to avoid aborting the AVDTP connection.
---
audio/avdtp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/audio/avdtp.c b/audio/avdtp.c
index 6ba9794..83b1aa2 100644
--- a/audio/avdtp.c
+++ b/audio/avdtp.c
@@ -85,7 +85,7 @@
#define AVDTP_MSG_TYPE_ACCEPT 0x02
#define AVDTP_MSG_TYPE_REJECT 0x03
-#define REQ_TIMEOUT 4
+#define REQ_TIMEOUT 6
#define ABORT_TIMEOUT 2
#define DISCONNECT_TIMEOUT 1
#define STREAM_TIMEOUT 20
--
1.6.0.4
^ permalink raw reply related
* [2.6.38-rc8, patch] fix hci_dev_list locking
From: Daniel J Blueman @ 2011-03-08 16:07 UTC (permalink / raw)
To: Linux Kernel, linux-bluetooth
No response from original post, and it missed getting taken into -rc7
and -rc8, so repost:
Release acquired lock on error path, fixing potential hang up.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index f827fd9..ace8726 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -111,8 +111,10 @@ static int read_index_list(struct sock *sk)
body_len = sizeof(*ev) + sizeof(*rp) + (2 * count);
skb = alloc_skb(sizeof(*hdr) + body_len, GFP_ATOMIC);
- if (!skb)
+ if (!skb) {
+ read_unlock(&hci_dev_list_lock);
return -ENOMEM;
+ }
hdr = (void *) skb_put(skb, sizeof(*hdr));
hdr->opcode = cpu_to_le16(MGMT_EV_CMD_COMPLETE);--
--
Daniel J Blueman
^ permalink raw reply related
* Re: re "bluetooth disabled" and "[BUG] usb problems in .38-rc3+"
From: Justin P. Mattock @ 2011-03-08 22:30 UTC (permalink / raw)
To: Mikko Vinni
Cc: Johan Hedberg, linux-bluetooth, Ed Tomlinson, Gustavo F. Padovan
In-Reply-To: <359639.21781.qm@web161807.mail.bf1.yahoo.com>
alright..
<------clip --------->
finally had time to get online and look at this issue. from playing
around(hopefully)I found the trouble spot in of which this is
hitting(but could be wrong).
By doing the below:
From ff80f03c351018b53a630de8f256137a7af8f00c Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Tue, 8 Mar 2011 13:28:22 -0800
Subject: [PATCH] test
Signe-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
net/bluetooth/hci_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 9c4541b..9b8f425 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -99,8 +99,8 @@ void hci_req_complete(struct hci_dev *hdev, __u16 cmd,
int result)
* command requests) check if the completed command matches
* this, and if not just return. Single HCI command requests
* typically leave req_last_cmd as 0 */
- if (hdev->req_last_cmd && cmd != hdev->req_last_cmd)
- return;
+ /*if (hdev->req_last_cmd && cmd != hdev->req_last_cmd)
+ return; */
if (hdev->req_status == HCI_REQ_PEND) {
hdev->req_result = result;
--
1.7.4.1
I am able to have a clean connect every reboot and hard shutdown/start.
strange thing with this, is I was able to have a clean connect on the
current with nothing added or removed(but only one time out of 6
restarts) with the above every time.
if you guys need any info let me know and/or if you want me to test
anything out(keep in mind I am limited to intranet so I might take some
time to respond)
Justin P. Mattock
^ permalink raw reply related
* [PATCH] Bluetooth: Increment unacked_frames count only the first transmit
From: Suraj Sumangala @ 2011-03-09 9:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
This patch lets 'l2cap_pinfo.unacked_frames' be incremented only
the first time a frame is transmitted.
Previously it was being incremented for retransmitted packets
too resulting the value to cross the transmit window size.
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
net/bluetooth/l2cap_core.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index c9f9cec..ca27f3a 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1116,7 +1116,9 @@ int l2cap_ertm_send(struct sock *sk)
bt_cb(skb)->tx_seq = pi->next_tx_seq;
pi->next_tx_seq = (pi->next_tx_seq + 1) % 64;
- pi->unacked_frames++;
+ if (bt_cb(skb)->retries == 1)
+ pi->unacked_frames++;
+
pi->frames_sent++;
if (skb_queue_is_last(TX_QUEUE(sk), skb))
--
1.7.0.4
^ permalink raw reply related
* Re: how to set adapter to master with bluez 4.69?
From: Brian J. Murrell @ 2011-03-09 11:22 UTC (permalink / raw)
To: public-linux-bluetooth-u79uwXL29TY76Z2rM5mHXA; +Cc: Andrei Warkentin
In-Reply-To: <4D760E47.4000006@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On 11-03-08 06:08 AM, Brian J. Murrell wrote:
> On 11-03-07 05:57 PM, Andrei Warkentin wrote:
>>
>> What do you get for hcitool info 00:1F:20:0F:30:6A?
>
> $ hcitool info 00:1F:20:0F:30:6A
> Requesting information ...
> BD Address: 00:1F:20:0F:30:6A
> Device Name: Bluetooth Laser Travel Mouse
> LMP Version: 2.0 (0x3) LMP Subversion: 0x229
> Manufacturer: Broadcom Corporation (15)
> Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
> <encryption> <slot offset> <timing accuracy> <role switch>
> <sniff mode> <RSSI> <power control> <enhanced iscan>
> <interlaced iscan> <interlaced pscan> <AFH cap. slave>
Was this at all helpful?
Cheers,
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* bluetooth-hid2hci.rules no longer works
From: Malar @ 2011-03-09 12:07 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
Hello,
the udev rules under scripts/bluetooth-hid2hci.rules uses -v and
-p parameters which are no longer supported by the hid2hci in udev.
Instead it uses --devpath parameter.
Please fix these rules as they fail to switch the mode of the
bluetooth device.
regards,
Malar
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC 1/6] Bluetooth: Implement advertising report meta event
From: Anderson Briglia @ 2011-03-09 13:58 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1299270913-8436-2-git-send-email-andre.guedes@openbossa.org>
Hi,
On Fri, Mar 4, 2011 at 4:35 PM, Andre Guedes <andre.guedes@openbossa.org> wrote:
> From: Anderson Briglia <anderson.briglia@openbossa.org>
>
> This patch implements new LE meta event in order to handle advertising
> reports.
>
> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
> ---
> include/net/bluetooth/hci.h | 18 ++++++++++++++++++
> net/bluetooth/hci_event.c | 22 ++++++++++++++++++++++
> 2 files changed, 40 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index d851f8b..fdcc494 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -1011,6 +1011,24 @@ struct hci_ev_le_conn_complete {
> __u8 clk_accurancy;
> } __packed;
>
> +#define ADV_IND 0x00
> +#define ADV_DIRECT_IND 0x01
> +#define ADV_SCAN_IND 0x02
> +#define ADV_NONCONN_IND 0x03
> +#define SCAN_RSP 0x04
> +
> +#define ADDR_DEV_PUBLIC 0x00
> +#define ADDR_DEV_RANDOM 0x01
> +
> +#define HCI_EV_LE_ADVERTISING_REPORT 0x02
> +struct hci_ev_le_advertising_info {
> + __u8 evt_type;
> + __u8 bdaddr_type;
> + bdaddr_t bdaddr;
> + __u8 length;
> + __u8 data[0];
> +} __packed;
> +
> #define HCI_EV_LE_LTK_REQ 0x05
> struct hci_ev_le_ltk_req {
> __le16 handle;
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 5a2ab2c..8acc4a5 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2556,6 +2556,24 @@ static inline void hci_le_ltk_request_evt(struct hci_dev *hdev,
> hci_dev_unlock(hdev);
> }
>
> +static inline void hci_le_adv_report_evt(struct hci_dev *hdev,
> + struct sk_buff *skb)
> +{
> + struct hci_ev_le_advertising_info *ev;
> + u8 num_reports, i;
> +
> + num_reports = skb->data[0];
> +
> + ev = (void *) &skb->data[1];
> +
> + BT_DBG("adv from: %s", batostr(&ev->bdaddr));
> +
> + for (i = 1; i < num_reports; i++) {
> + ev = (void *) (ev->data + ev->length + 1);
> + BT_DBG("adv from: %s", batostr(&ev->bdaddr));
> + }
> +}
> +
> static inline void hci_le_meta_evt(struct hci_dev *hdev, struct sk_buff *skb)
> {
> struct hci_ev_le_meta *le_ev = (void *) skb->data;
> @@ -2571,6 +2589,10 @@ static inline void hci_le_meta_evt(struct hci_dev *hdev, struct sk_buff *skb)
> hci_le_ltk_request_evt(hdev, skb);
> break;
>
> + case HCI_EV_LE_ADVERTISING_REPORT:
> + hci_le_adv_report_evt(hdev, skb);
> + break;
> +
> default:
> break;
> }
> --
> 1.7.1
>
>
Please, do not consider this patch. I have another one with some
modifications proposed by padovan. Andre, rebase your git tree,
please.
--
INdT - Instituto Nokia de tecnologia
+55 2126 1122
http://techblog.briglia.net
^ permalink raw reply
* [PATCH v2] Adjust timeout LE and API
From: Marco Sinigaglia @ 2011-03-09 16:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marco Sinigaglia
The timeout value has been hardcoded on hci_send_req call and, instead, it should be passed from above (for ex from hci_le_set_scan_enable).
This patch removes the hardcoded value from hci_send_req and it increases the timeout to 1000ms.
v1-->v2: used git-format-patch
Signed-off-by: Marco Sinigaglia <marco.sinigaglia@csr.com>
---
lib/hci.c | 12 ++++++------
lib/hci_lib.h | 6 +++---
tools/hciconfig.c | 2 +-
tools/hcitool.c | 6 +++---
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index 02fc0cf..eb00730 100644
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -2735,7 +2735,7 @@ int hci_read_clock(int dd, uint16_t handle, uint8_t which, uint32_t *clock,
return 0;
}
-int hci_le_set_scan_enable(int dd, uint8_t enable, uint8_t filter_dup)
+int hci_le_set_scan_enable(int dd, uint8_t enable, uint8_t filter_dup, int to)
{
struct hci_request rq;
le_set_scan_enable_cp scan_cp;
@@ -2753,7 +2753,7 @@ int hci_le_set_scan_enable(int dd, uint8_t enable, uint8_t filter_dup)
rq.rparam = &status;
rq.rlen = 1;
- if (hci_send_req(dd, &rq, 100) < 0)
+ if (hci_send_req(dd, &rq, to) < 0)
return -1;
if (status) {
@@ -2766,7 +2766,7 @@ int hci_le_set_scan_enable(int dd, uint8_t enable, uint8_t filter_dup)
int hci_le_set_scan_parameters(int dd, uint8_t type,
uint16_t interval, uint16_t window,
- uint8_t own_type, uint8_t filter)
+ uint8_t own_type, uint8_t filter, int to)
{
struct hci_request rq;
le_set_scan_parameters_cp param_cp;
@@ -2787,7 +2787,7 @@ int hci_le_set_scan_parameters(int dd, uint8_t type,
rq.rparam = &status;
rq.rlen = 1;
- if (hci_send_req(dd, &rq, 100) < 0)
+ if (hci_send_req(dd, &rq, to) < 0)
return -1;
if (status) {
@@ -2798,7 +2798,7 @@ int hci_le_set_scan_parameters(int dd, uint8_t type,
return 0;
}
-int hci_le_set_advertise_enable(int dd, uint8_t enable)
+int hci_le_set_advertise_enable(int dd, uint8_t enable, int to)
{
struct hci_request rq;
le_set_advertise_enable_cp adv_cp;
@@ -2815,7 +2815,7 @@ int hci_le_set_advertise_enable(int dd, uint8_t enable)
rq.rparam = &status;
rq.rlen = 1;
- if (hci_send_req(dd, &rq, 100) < 0)
+ if (hci_send_req(dd, &rq, to) < 0)
return -1;
if (status) {
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index de3e636..725eb05 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -115,11 +115,11 @@ int hci_read_rssi(int dd, uint16_t handle, int8_t *rssi, int to);
int hci_read_afh_map(int dd, uint16_t handle, uint8_t *mode, uint8_t *map, int to);
int hci_read_clock(int dd, uint16_t handle, uint8_t which, uint32_t *clock, uint16_t *accuracy, int to);
-int hci_le_set_scan_enable(int dev_id, uint8_t enable, uint8_t filter_dup);
+int hci_le_set_scan_enable(int dev_id, uint8_t enable, uint8_t filter_dup, int to);
int hci_le_set_scan_parameters(int dev_id, uint8_t type, uint16_t interval,
uint16_t window, uint8_t own_type,
- uint8_t filter);
-int hci_le_set_advertise_enable(int dev_id, uint8_t enable);
+ uint8_t filter, int to);
+int hci_le_set_advertise_enable(int dev_id, uint8_t enable, int to);
int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
uint8_t initiator_filter, uint8_t peer_bdaddr_type,
bdaddr_t peer_bdaddr, uint8_t own_bdaddr_type,
diff --git a/tools/hciconfig.c b/tools/hciconfig.c
index 05a8910..aa6d009 100644
--- a/tools/hciconfig.c
+++ b/tools/hciconfig.c
@@ -268,7 +268,7 @@ static void cmd_le_adv(int ctl, int hdev, char *opt)
rq.rparam = &status;
rq.rlen = 1;
- ret = hci_send_req(dd, &rq, 100);
+ ret = hci_send_req(dd, &rq, 1000);
hci_close_dev(dd);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index e79d76b..05f4df8 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2467,13 +2467,13 @@ static void cmd_lescan(int dev_id, int argc, char **argv)
}
err = hci_le_set_scan_parameters(dd, scan_type, interval, window,
- own_type, 0x00);
+ own_type, 0x00, 1000);
if (err < 0) {
perror("Set scan parameters failed");
exit(1);
}
- err = hci_le_set_scan_enable(dd, 0x01, 0x00);
+ err = hci_le_set_scan_enable(dd, 0x01, 0x00, 1000);
if (err < 0) {
perror("Enable scan failed");
exit(1);
@@ -2487,7 +2487,7 @@ static void cmd_lescan(int dev_id, int argc, char **argv)
exit(1);
}
- err = hci_le_set_scan_enable(dd, 0x00, 0x00);
+ err = hci_le_set_scan_enable(dd, 0x00, 0x00, 1000);
if (err < 0) {
perror("Disable scan failed");
exit(1);
--
1.7.1
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ 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