[HCI Events] Connection Event Processing

[HCI Events] Connection Event Processing

[Shreesh Holla]

Hi,

I'm trying to build a  handler for a project and needed to  process the 
Connection Request Event.
I'm able to get that  properly. But I tried adding a "reject Connection" - 
command in the  handler and invariably an "Accept Connection" command is 
issued.This  is what I can see from hcidump and my event handling code.

I  need to override that. So where is this done? In the Bluez library,  
bluetoothd 

or btusb? Or somewhere else? Or is there some other kind  of setup/hooks that 
needs to be modified to insert my own event  handler?

Any help would be great here.

Thanks

Shreesh

Re: [HCI Events] Connection Event Processing

[Johan Hedberg]

Hi Shreesh,

On Fri, Jul 16, 2010, Shreesh Holla wrote:
> I'm trying to build a  handler for a project and needed to  process the 
> Connection Request Event.
> I'm able to get that  properly. But I tried adding a "reject Connection" - 
> command in the  handler and invariably an "Accept Connection" command is 
> issued.This  is what I can see from hcidump and my event handling code.
> 
> I  need to override that. So where is this done? In the Bluez library,  
> bluetoothd 
> 
> or btusb? Or somewhere else? Or is there some other kind  of setup/hooks that 
> needs to be modified to insert my own event  handler?
> 
> Any help would be great here.

The response to the connect request is more or less hardcoded into the
hci_conn_request_evt function in net/bluetooth/hci_event.c. There's a
patch[1] in the bluetooth-next-2.6 tree which adds blacklist support,
but afaik it's only headed for 2.6.36. It's also only a static list of
addresses to be rejected, so if you want something more dynamic it wont
be of much help.

Another way to avoid the kernel response to the connect request is to
set the HCI device into RAW mode but then you also loose all other
Bluetooth functionality provided by the kernel and userspace (i.e. you'd
essentially need to implement a full host stack yourself).

Johan

[1] http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-next-2.6.git;a=commitdiff;h=a1e716eedbed0bac3e9b84b7f53de182e12345cb

Re: [HCI Events] Connection Event Processing

[Shreesh Holla]

Johan,
ugh! I see the issues now. As you said - neither of those approaches would work for me since we need to conditionally handle the incoming connection really.

Wonder if there is some design reason this was done i.e. hardcoding it in hci_event.c? Or is it for performance reasons?   Any plans on supporting this in the future? 

What I'm considering is plugging in our own handler inside hci_event.c.

We can do this inside some custom hardware - but we are trying to avoid this since we already have other custom hardware we need to do in our device which is a wireless access control system.

Thanks,
Shreesh

--- On Sun, 7/18/10, Johan Hedberg <johan.hedberg@gmail.com> wrote:

> From: Johan Hedberg <johan.hedberg@gmail.com>
> Subject: Re: [HCI Events] Connection Event  Processing
> To: "Shreesh Holla" <hshreesh@yahoo.com>
> Cc: linux-bluetooth@vger.kernel.org
> Date: Sunday, July 18, 2010, 1:02 AM
> Hi Shreesh,
> 
> On Fri, Jul 16, 2010, Shreesh Holla wrote:
> > I'm trying to build a  handler for a project and
> needed to  process the 
> > Connection Request Event.
> > I'm able to get that  properly. But I tried
> adding a "reject Connection" - 
> > command in the  handler and invariably an "Accept
> Connection" command is 
> > issued.This  is what I can see from hcidump and
> my event handling code.
> > 
> > I  need to override that. So where is this done?
> In the Bluez library,  
> > bluetoothd 
> > 
> > or btusb? Or somewhere else? Or is there some other
> kind  of setup/hooks that 
> > needs to be modified to insert my own event 
> handler?
> > 
> > Any help would be great here.
> 
> The response to the connect request is more or less
> hardcoded into the
> hci_conn_request_evt function in net/bluetooth/hci_event.c.
> There's a
> patch[1] in the bluetooth-next-2.6 tree which adds
> blacklist support,
> but afaik it's only headed for 2.6.36. It's also only a
> static list of
> addresses to be rejected, so if you want something more
> dynamic it wont
> be of much help.
> 
> Another way to avoid the kernel response to the connect
> request is to
> set the HCI device into RAW mode but then you also loose
> all other
> Bluetooth functionality provided by the kernel and
> userspace (i.e. you'd
> essentially need to implement a full host stack yourself).
> 
> Johan
> 
> [1] http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-next-2.6.git;a=commitdiff;h=a1e716eedbed0bac3e9b84b7f53de182e12345cb
> 

Re: [HCI Events] Connection Event Processing

[Marcel Holtmann]

Hi Shressh,

first of all, stop top posting. This is rude and we will ignore further
emails from you if you keep doing this.

> ugh! I see the issues now. As you said - neither of those approaches would work for me since we need to conditionally handle the incoming connection really.
> 
> Wonder if there is some design reason this was done i.e. hardcoding it in hci_event.c? Or is it for performance reasons?   Any plans on supporting this in the future? 
> 
> What I'm considering is plugging in our own handler inside hci_event.c.
> 
> We can do this inside some custom hardware - but we are trying to avoid this since we already have other custom hardware we need to do in our device which is a wireless access control system.

I really don't know what you are trying to achieve here, but you might
better not use BlueZ if you wanna do something like this. The connection
handling needs to be done in the kernel and it does this the right way.

Use your own Bluetooth stack or switch the device into RAW mode and
program it as you like. As Johan mentioned RAW devices are left alone by
the kernel.

Regards

Marcel

Re: [HCI Events] Connection Event Processing

[Shreesh Holla]

Marcel,=0A=0AFirstly, my intention has not been to be rude etc - I really d=
ont know what top posting is. But, if I have posted something that has offe=
nded anyone - please excuse that and as it was not intentional - only tryin=
g to figure out the best approach to our issue.=0A=0ABut, from your comment=
s below I do see that this connection hookup needs to happen in the kernel.=
 And I shall explore the RAW mode - if it can work for us.=0A=0ABut thanks,=
=0AShreesh=0A=0A--- On Mon, 7/19/10, Marcel Holtmann <marcel@holtmann.org> =
wrote:=0A=0A> From: Marcel Holtmann <marcel@holtmann.org>=0A> Subject: Re: =
[HCI Events] Connection Event  Processing=0A> To: "Shreesh Holla" <hshreesh=
@yahoo.com>=0A> Cc: "Johan Hedberg" <johan.hedberg@gmail.com>, linux-blueto=
oth@vger.kernel.org=0A> Date: Monday, July 19, 2010, 11:10 AM=0A> Hi Shress=
h,=0A> =0A> first of all, stop top posting. This is rude and we will=0A> ig=
nore further=0A> emails from you if you keep doing this.=0A> =0A> > ugh! I =
see the issues now. As you said - neither of=0A> those approaches would wor=
k for me since we need to=0A> conditionally handle the incoming connection =
really.=0A> > =0A> > Wonder if there is some design reason this was done=0A=
> i.e. hardcoding it in hci_event.c? Or is it for performance=0A> reasons?=
=A0=A0=A0Any plans on supporting this in=0A> the future? =0A> > =0A> > What=
 I'm considering is plugging in our own handler=0A> inside hci_event.c.=0A>=
 > =0A> > We can do this inside some custom hardware - but we=0A> are tryin=
g to avoid this since we already have other custom=0A> hardware we need to =
do in our device which is a wireless=0A> access control system.=0A> =0A> I =
really don't know what you are trying to achieve here,=0A> but you might=0A=
> better not use BlueZ if you wanna do something like this.=0A> The connect=
ion=0A> handling needs to be done in the kernel and it does this=0A> the ri=
ght way.=0A> =0A> Use your own Bluetooth stack or switch the device into RA=
W=0A> mode and=0A> program it as you like. As Johan mentioned RAW devices a=
re=0A> left alone by=0A> the kernel.=0A> =0A> Regards=0A> =0A> Marcel=0A> =
=0A> =0A> 

Re: [HCI Events] Connection Event Processing

[Marcel Holtmann]

Hi Shreesh,

> Firstly, my intention has not been to be rude etc - I really dont know what top posting is. But, if I have posted something that has offended anyone - please excuse that and as it was not intentional - only trying to figure out the best approach to our issue.

and you did it again. Really? Just typing top-posting into Google or
Wikipedia would have resulted in proper information:

http://en.wikipedia.org/wiki/Top_Posting

And while at it. Here is another nice read:

http://www.catb.org/~esr/faqs/smart-questions.html

And all of this is linked from bluez.org website:

http://www.bluez.org/development/lists/

Regards

Marcel

Re: [HCI Events] Connection Event Processing

[Shreesh Holla]

--- On Mon, 7/19/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [HCI Events] Connection Event  Processing
> To: "Shreesh Holla" <hshreesh@yahoo.com>
> Cc: "Johan Hedberg" <johan.hedberg@gmail.com>, linux-bluetooth@vger.kernel.org
> Date: Monday, July 19, 2010, 11:39 AM
> Hi Shreesh,
> 
> > Firstly, my intention has not been to be rude etc - I
> really dont know what top posting is. But, if I have posted
> something that has offended anyone - please excuse that and
> as it was not intentional - only trying to figure out the
> best approach to our issue.
> 
> and you did it again. Really? Just typing top-posting into
> Google or
> Wikipedia would have resulted in proper information:
> 
> http://en.wikipedia.org/wiki/Top_Posting
> 
> And while at it. Here is another nice read:
> 
> http://www.catb.org/~esr/faqs/smart-questions.html
> 
> And all of this is linked from bluez.org website:
> 
> http://www.bluez.org/development/lists/
> 
> Regards
> 
> Marcel
> 
> 
> 

Marcel,

I understand what it is now. I was really just using the default of Yahoo Mail. But shall follow this approach henceforth of bottom posting.

Thanks,
Shreesh