Hi,
I'm a student in computer science, working on making Bluetooth do a
certain task. I wrote my own application as a proof-of-concept, using
the source code from the various BlueZ utilities as an example. Now
I'm stuck, and I need some help troubleshooting.
Here's what my program does:
First, host A starts up listening on RFCOMM channel 10. Then host B
connects, B sends to A, A sends to B ... for a total of three
send()/recv() cycles. Then both sides close() their sockets and sleep
for ~ 30 seconds. Then they switch roles and B listen()s for A to
connect(). [ I don't actually explicitly issue any HCI command for
this role switch, it just automagically happens. ] Go back to the
beginning and repeat 3 times.
So much for the program overview. Now on to the post mortem of where
it fell apart:
For the first cycle, they connect, exchange messages, disconnect, and
both sides close their sockets. Everything works as expected.
Then I switch roles, so that host B listens and host A connects. This
second cycle also works as expected.
On the third cycle, I try to switch roles again, so that A listens and
B connects. Every time I get to this third cycle, host A fails on
bind() with EADDRINUSE, "Address already in use". (I set
SO_REUSEADDR, with no effect.)
Both hosts have Linux 2.6.11.6-mh2, hcidump ver. 1.19, and identical
USB dongles (hciconfig posted below). Can you help me understand what
I've run into? Is this a bug in BlueZ (probably not!), or a
limitation of Bluetooth? Or is it my mistake?
Sorry for the super-long post, all my logs are attached.
Thanks for your time,
Jeff
# hciconfig hci0 version
hci0: Type: USB
BD Address: 00:E0:98:85:E8:40 ACL MTU: 192:8 SCO MTU: 64:8
HCI Ver: 1.1 (0x1) HCI Rev: 0x175 LMP Ver: 1.1 (0x1) LMP Subver: 0x175
Manufacturer: Cambridge Silicon Radio (10)
host A # hcidump -X -V [ see attachment host-a.txt ]
host B # hcidump -X -V [ see attachment host-b.txt ]
Right you are. I finally found the bug. I forgot to close a socket
file descriptor. This is what caused bind() to fail.
Once I found the bug, I tested through several iterations. I reduced
my pause between iterations and was able to reduce the pause to 0. I
increased my iterations and stopped counting after reaching 30
iterations.
So! Very definitely *not* a limitation of Bluetooth or BlueZ! Thanks
again for your time.
Regards,
jw
On 9/13/05, Marcel Holtmann <[email protected]> wrote:
> Hi Jeff,
>=20
> this sounds like a bug inside your code.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jeff,
> I'm a student in computer science, working on making Bluetooth do a
> certain task. I wrote my own application as a proof-of-concept, using
> the source code from the various BlueZ utilities as an example. Now
> I'm stuck, and I need some help troubleshooting.
>
> Here's what my program does:
> First, host A starts up listening on RFCOMM channel 10. Then host B
> connects, B sends to A, A sends to B ... for a total of three
> send()/recv() cycles. Then both sides close() their sockets and sleep
> for ~ 30 seconds. Then they switch roles and B listen()s for A to
> connect(). [ I don't actually explicitly issue any HCI command for
> this role switch, it just automagically happens. ] Go back to the
> beginning and repeat 3 times.
>
> So much for the program overview. Now on to the post mortem of where
> it fell apart:
>
> For the first cycle, they connect, exchange messages, disconnect, and
> both sides close their sockets. Everything works as expected.
>
> Then I switch roles, so that host B listens and host A connects. This
> second cycle also works as expected.
>
> On the third cycle, I try to switch roles again, so that A listens and
> B connects. Every time I get to this third cycle, host A fails on
> bind() with EADDRINUSE, "Address already in use". (I set
> SO_REUSEADDR, with no effect.)
>
> Both hosts have Linux 2.6.11.6-mh2, hcidump ver. 1.19, and identical
> USB dongles (hciconfig posted below). Can you help me understand what
> I've run into? Is this a bug in BlueZ (probably not!), or a
> limitation of Bluetooth? Or is it my mistake?
this sounds like a bug inside your code.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel