Bluetooth Cf Works Only If Usb Cable Connected

[Russ Palmer]

I was having trouble getting my D-Link BCF-650BT CF card to work and discovered that it works flawlessly if the USB cable is connected between my Zaurus and my Windows PC.

I need this to work without the USB cable. Does anyone have any ideas.

I posted a description of my original problem here:

Bluez On Sl-c3000 Using Dcf-650bt

[speculatrix]

what does "ifconfig -a" and "netstat -r" say?

could it be simply the default route is not being set?

[Russ Palmer]

what does "ifconfig -a" and "netstat -r" say?

could it be simply the default route is not being set?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=97206\"][{POST_SNAPBACK}][/a][/div]

Thanks for the suggestion. I've tried a few things, but haven't made any progress.

When the USB is connected ifconfig -a lists two interfaces:
  lo inet addr: 127.0.0.1 ...
  usbd0 inet addr: 192.168.129.201 ...

And netstat -r lists 192.168.129.0 as the default gateway.

I don't fully understand how the IP routes are used by l2ping which takes as input a bluetooth MAC address.  My end application is to associate a TTY using rfcomm and then interface to the Bluetooth device as I would any serial device.

So I tried the following just to verify that the default routes are not being used by l2ping.

1. Connected the USB cable.
2. Checked the routing table. 192.168.129.0 was there.
3. Verified the l2ping to the Bluetooth device works without problem.
4. Removed the default route using:  route delete -net 192.168.129.0/24 usdb0
5. Verified the routing table was empty.
6. Repeated the l2ping. Which works flawlessly. l2ping didn't care that there was no default route.

I then tried the following:
1. With the USB cable still connected, started the l2ping to the Bluetooth device. Works flawlessly with response times around 40 ms.
2. While the l2ping was in progress, disconnected the USB cable. The l2ping starts reporting response times around 2-3 seconds.
3. After 3 or 4 slow responses, I reconnect the USB cable. The l2ping returns to normal with response times around 40 ms.

Any further suggestions would be appreciated.

[speculatrix]

aha, don't get confused about what l2ping does... it's NOT testing an IP level connection like ping does, it's at a MUCH lower level and tests whether the bluetooth hardware can see the other node. You don't have to have an rfcomm or pand connection for l2ping to work.

I have also observed that if you have a BT connection up, e.g. pand, whilst usb is connected, pulling out usb can affect BT.

To make an IP connection with bluetooth, there are two choices, either PAND, or PPP over RFCOMM. The former simply wraps IP in bluetooth, the latter wraps IP in PPP and sends it over a simulated serial port (rfcomm).

PAND: on the PC, ensure there's a PAND in listen mode, and on the Z use "pand connect" to connect to the PC. Both ends will gain a bnep0 interface if you use "ifconfig -a".

PPP: need to have a DUND on the PC listening/triggered on a connection to /dev/rfcomm0. The Z then uses pppd  to connect to the PC over serial, and then run ppp over that. Both ends will then have an interface ppp0.

A bit brief, but hope that helps.

To check that the pin is set correctly, use "sdptool browse" on the Z and observe that it can see all the services on the PC.

[Russ Palmer]

I'm have no need to support IP over Bluetooth, and therefore I have not looked into PAN or PPP (over RFCOMM).

My Zaurus is communicating via bluetooth to a Bluetooth Serial Port Adapter (connectBlue). On the Zaurus, I have rfcomm configured and am running a C program that opens /dev/rfcomm0 and starts sending and receiving bytes to/from the connectBlue device. The C program runs fine for a few seconds but then stops working. Because the communications using /dev/rfcomm0 wasn't reliable I started debugging the problem using l2ping to verify that the bluetooth communications was working between the Zaurus and the connectBlue device. This is when I reported my initial problem that l2ping wasn't working with my configuration. And then by accident I realized that the Bluetooth communication became reliable when I connected the completely unrelated USB cable.

I don't want to give up on this configuration, but I'm starting to consider switching to OpenZaurus or Cacko.