is bluetooth 2.0 speeds supported on freebsd?

[Maksim Yevmenkin]

Iain Hibbert wrote:
> On Wed, 10 Jan 2007, Alexander V. Ribchansky wrote:
> 
>> Iain Hibbert ?????:
>>> 	ptype: [0xcc18] DM1 DH1 DM3 DH3 DM5 DH5 2-DH1 3-DH1 2-DH3 3-DH3 2-DH5 3-DH5
>> I'm a very-very newbie in bluetooth, but if the whole problem is to
>> properly detect adapter capabilities and to properly config frame mask
>> if adapter supports EDR, could someone tell me a place in src, where I
>> should apply WHERRY DIRTY HACK to insist that adapter support EDR
>> frames? just to test if it work with 2.0 adapter. Or I miss something,
>> reading this thread?
> 
> You need to adjust the packet types that are allowed - look at
> sys/netgraph/bluetooth/hci/ng_hci_ulpi.c and search for CREATE_CON to see
> where the connection is made. Just a few lines down hardwire
> req->cp.pkt_type=0xcc18 which should enable all the packet types as
> above.
> 
> To make it work properly, you would have to interpret the other packet
> types from the mask.

actually, it appears that nothing is required to be done at all. i got 
my self a couple of bluetooth 2.0+edr dongles from bestbuy, specifically

Jan 10 14:21:40 beetle kernel: ubt0: <Kensington Bluetooth EDR Dongle, 
class 224/1, rev 2.00/0.00, addr 2> on uhub2
Jan 10 14:21:40 beetle kernel: ubt0: Kensington Bluetooth EDR Dongle, 
rev 2.00/0.00, addr 2
Jan 10 14:21:40 beetle kernel: ubt0: Interface 0 endpoints: 
interrupt=0x81, bulk-in=0x82, bulk-out=0x2
Jan 10 14:21:40 beetle kernel: ubt0: Interface 1 (alt.config 5) 
endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, 
buffer size=294

and

Jan 10 14:21:46 beetle kernel: ubt1: <Broadcom Corp 
BCM92045DG-Flash_UHE, class 224/1, rev 2.00/1.00, addr 3> on uhub6
Jan 10 14:21:46 beetle kernel: ubt1: Broadcom Corp BCM92045DG-Flash_UHE, 
rev 2.00/1.00, addr 3
Jan 10 14:21:46 beetle kernel: ubt1: Interface 0 endpoints: 
interrupt=0x81, bulk-in=0x82, bulk-out=0x2
Jan 10 14:21:46 beetle kernel: ubt1: Interface 1 (alt.config 4) 
endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, 
buffer size=320

and connected them to two different freebsd boxes, specifically

FreeBSD beetle.savvis.net 7.0-CURRENT FreeBSD 7.0-CURRENT #79: Tue Nov 
21 17:21:46 PST 2006 max at beetle.digisle.com:/usr/obj/usr/src/sys/GENERIC 
  i386

and

FreeBSD peahi.savvis.ad.savvis.net 7.0-CURRENT FreeBSD 7.0-CURRENT #14: 
Tue Nov 21 10:57:25 PST 2006 
max at peahi.savvis.ad.savvis.net:/usr/obj/usr/src/sys/GENERIC  sparc64

both boxes are sitting about two meters apart in my office. i used ttcp 
(ports/benchmarks/ttcp) as basic tool to measure throughput. both 
machines connected using bluetooth lan profile (i.e. ppp over rfcomm link)

ppp config on server:

rfcomm-server:
  #enable force-scripts
  set timeout 0
  set lqrperiod 10
  set ifaddr 192.168.1.2 192.168.1.1 255.255.255.255
  enable lqr
  accept lqr
  disable pap
  deny pap
  disable chap
  deny chap
  accept dns

ppp config on client

rfcomm-client:
  set dial
  set timeout 0
  set ifaddr 192.168.1.1 192.168.1.2 255.255.255.255
  accept dns

now results

receiver side:

peahi% ttcp -r -s -f m
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.2
ttcp-r: 16777216 bytes in 72.29 real seconds = 1.77 Mbit/sec +++
ttcp-r: 11684 I/O calls, msec/call = 6.34, calls/sec = 161.63
ttcp-r: 0.1user 2.6sys 1:12real 3% 166i+1416d 1860maxrss 0+0pf 11682+1039csw

sender side:

beetle# ttcp -t -s 192.168.1.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 
192.168.1.1
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 72.28 real seconds = 226.66 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 36.14, calls/sec = 28.33
ttcp-t: 0.0user 0.2sys 1:12real 0% 1i+341d 424maxrss 0+0pf 7774+17csw

as you can see i got close to 2 Mbit/sec throughput (receiver reports in 
Mbit/sec and sender reports in Kbytes/sec). numbers look consistent on 
both sides. in theory bluetooth 2.0+edr  can give you up to 3 Mbit/sec 
(please correct me if i wrong here), but in real life you unlikely to 
see this because of protocol header overhead. in this case its protocol 
stack looks something like

tcp -> ip -> ppp -> rfcomm -> l2cap

bottom line: it looks like bluetooth 2.0+edr dongles will talk high 
speed without stack doing anything at all. i'm not sure why do you see 
low transfer speed, but perhaps it has something to do with obex?

thanks,
max