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 [EMAIL PROTECTED]:/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
[EMAIL PROTECTED]:/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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
