[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] Security implementation

 I am intersted in implementing a generic security manager for the stack
 any useful information and details on existing implementation are

Thus Said Gordon McNutt On Mon, Feb 12, 2001 at 07:20:41PM -0700 :
*->Matthew Palmer wrote:
*->> Hmm.  I've had a quick scan - what would be the practicality of developing a
*->> library which implemented the setup, inquiry, and connection functions.
*->If it could be done it might be very practical. It is a pain in the ass to have to
*->start another app just to start the one you really want. But the issue is letting
*->multiple apps use bluetooth at the same time. The two scenarios in effect right now
*->1. A btd-like 'manager' app sets up the physical connection and leaves it open.
*->Other apps come along and compete with each other for RFCOMM channels (and an
*->SCO channel, when that sorts itself out). And somehow SDP needs to get involved to
*->keep track of which apps have which channels, right? You SDP folks can help me out
*->here. Note that this is the solution IrDA uses.
*->2. Or, each app sets up the connection itself, thus one app can use the stack at a
*->time. Not cool.
*->> and possibly moving portions of the stack out of kernel space?  At a
*->> guess, I'd say that L2CAP would probably be best left in the kernel, but
*->> surely the layers above don't need kernel features?
*->RFCOMM must remain in the kernel because it must implement a tty driver. This is per
*->the spec and, sure enough, ppp needs it.
*->SDP can probably move out, and the SCO users will almost definitely be out. The
*->problems then is one of providing an interface to L2CAP for them to use. I'll spare
*->you all my rant on that subject, but you can probably find portions of it in the
*->> Ah, that's a help.  So if I execute btd with appropriate commands to make
*->> several connections, I can then talk on /dev/ttyBT{0..n} (for n < 7, at
*->> least on my install) via ordinary everyday serial functions.
*->That's the idea. I don't know if anyone has suceeded there or not. Someone was
*->trying to make minicom work...
*->While we're on the subject I'll throw in my two cents concerning architecture. IrDA
*->is probably more like Bluetooth than anything else in terms of the variety of
*->protocols and interfaces. In most cases you can find an analog for any Bluetooth
*->protocol layer or interface (IrCOMM = RFCOMM, IAS = SDP, IrLAP = basband, IrLMP =
*->L2CAP, etc). The combination of specified interfaces and where they branch in and
*->land on the protocol stack is similar and, I think, very very weird in a 'datalink
*->So I propose that people who are interested in developing/improving the stack take a
*->look at how IrDA was done. To sum up, they implement a network interface on top of a
*->tty which controls the hardware link, and this is the rock bottom of the stack.
*->IrLAP sits on top of that, and everything else stacks on IrLAP.
*->In the case of Bluetooth, by analogy, the underbelly of HCI could provide the
*->network interface. In other words, HCI-USB or HCI-UART would be a tty which
*->registered a network interface to the kernel. The generic HCI and friends would
*->stack above that and do whatever. I may have blundered some details here, but if
*->you're interested go look for yourself.
*->To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
*->the body of a message to majordomo@xxxxxxx.com


    Daniel D. Ezekiel                                
    E-Mail  : danny@xxxxxxx.com                         
    Fone    : 91-80-5281461  Extn: 3322 

    PGP Key : hkp://keys.pgp.com/danny@xxxxxxx.com       
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com