Bluez Works, But Has Some Quirks

[Ragnorok]

- After lots of floundering around like a brainless Noob, I finally downloaded, installed, and configured the RIGHT BlueZ version, and it works!  Kudos to Tumnus, who did a good job of porting, and a good job of ignoring useless drivel from someone who should have just been paying more attention to start with.  (vaccuous drool)

- But there is some wierdness, which is to be expected.  BlueZ on the CxK is, after all, *alphaware*.  (wide grin)  Here's what I notice:

1. It doesn't seem to pair "permanently".
- I have to keep putting the phone into "Show always" mode on BT before the Z will find and connect to it, sort of like it has to search and find before it will pair.  If I set the phone to "Wait for pairing" so I get the Z into the phone's "permanent" pairing list, it never does "pair" from there.  I think if I can get the Z into the phone's permanent list, I won't have to set the phone to "Show always" in order to use it as a modem.
- It may not be possible to do this, but if I can, I'd like to be able to link to my phone without having to leave it exposed to the world via BT.  I'm certainly brand-spanky new at the entire BT thing, having just jumped in with both feet last Saturday when the AmbiCom arrived.  (wide grin)

2. It seems to lose DNS.
- When I surf, in either Opera 7.3 or the "native" NetFront, I can load two or three pages, then it just stops resolving names for some reason.  When this happens, I can't l2ping anything, either, which implies something has gone awry in BlueZ, as opposed to the browser not using the link correctly.
- When this happens, it's usually an effort to get it working again.  I haven't yet figured out a reliable sequence to restore operation.  I do know that popping the CF without using "Eject Card" first locks up hiroshi such that I have to use the reset button to get going again.

Background, asides:
- I'm using an LG PM325 with the v18 SW upgrade that xqlan (sp?) mentioned, and the BlueZ alpha4 drivers on a C1000 w/ an AmbiCom BT2000E CF (yellow sticker).

- As an aside, I'd be delighted to build BlueZ myself, so as to be running a "debug" version of the drivers.  I do have an entire build environment installed, but I'm an even more rank Noob at Z development than I am at BT.  I'm old at with C/C++, just not on the Z.  (wink)  If someone could toss me a clue on how to get BlueZ set up for compilation, I'd be as happy as if I knew what I was doing.  So far I haven't located anything of that nature via numerous web searches, but I'll keep looking in lieu of any response here.

- Thanks for your time!...

[Bombur]

- After lots of floundering around like a brainless Noob, I finally downloaded, installed, and configured the RIGHT BlueZ version, and it works!  Kudos to Tumnus, who did a good job of porting, and a good job of ignoring useless drivel from someone who should have just been paying more attention to start with.  (vaccuous drool)

- But there is some wierdness, which is to be expected.  BlueZ on the CxK is, after all, *alphaware*.  (wide grin)  Here's what I notice:

1. It doesn't seem to pair "permanently".
- I have to keep putting the phone into "Show always" mode on BT before the Z will find and connect to it, sort of like it has to search and find before it will pair.  If I set the phone to "Wait for pairing" so I get the Z into the phone's "permanent" pairing list, it never does "pair" from there.  I think if I can get the Z into the phone's permanent list, I won't have to set the phone to "Show always" in order to use it as a modem.
- It may not be possible to do this, but if I can, I'd like to be able to link to my phone without having to leave it exposed to the world via BT.  I'm certainly brand-spanky new at the entire BT thing, having just jumped in with both feet last Saturday when the AmbiCom arrived.  (wide grin)

2. It seems to lose DNS.
- When I surf, in either Opera 7.3 or the "native" NetFront, I can load two or three pages, then it just stops resolving names for some reason.  When this happens, I can't l2ping anything, either, which implies something has gone awry in BlueZ, as opposed to the browser not using the link correctly.
- When this happens, it's usually an effort to get it working again.  I haven't yet figured out a reliable sequence to restore operation.  I do know that popping the CF without using "Eject Card" first locks up hiroshi such that I have to use the reset button to get going again.


Background, asides:
- I'm using an LG PM325 with the v18 SW upgrade that xqlan (sp?) mentioned, and the BlueZ alpha4 drivers on a C1000 w/ an AmbiCom BT2000E CF (yellow sticker).

- As an aside, I'd be delighted to build BlueZ myself, so as to be running a "debug" version of the drivers.  I do have an entire build environment installed, but I'm an even more rank Noob at Z development than I am at BT.  I'm old at with C/C++, just not on the Z.  (wink)  If someone could toss me a clue on how to get BlueZ set up for compilation, I'd be as happy as if I knew what I was doing.  So far I haven't located anything of that nature via numerous web searches, but I'll keep looking in lieu of any response here.

- Thanks for your time!...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80029\"][{POST_SNAPBACK}][/a][/div]

Your issue may be due to a frame check sequence problem.
Try   echo 1 > /proc/lock_fcs
I had this problem...seemed like the phone would disconnect or stop resolving names.
Try searching this forum for more info ... this solution worked for me.

[tumnus]

With regards to building BlueZ for a 2.4.20 kernel based zaurus here are some simple instructions, going off memory. (I really need to write a full howto if only for myself):

Download the following:
http://developer.ezaurus.com/sl_j/source/c...rom1_01.tar.bz2
http://www.bluez.org/redirect.php?url=http...ibs-2.17.tar.gz
http://www.bluez.org/redirect.php?url=http...ils-2.17.tar.gz
http://www.bluez.org/redirect.php?url=http...-2.4.20-mh18.gz

Then do the following in a directory of your choice:
tar jxvf linux-c3000-20041116-rom1_01.tar.bz2
ln -s linux linux-2.4.20
zcat patch-2.4.20-mh18.gz | patch -p0 (that's a zero)
cd linux
make menuconfig
Load alternate configuration file and enter 'arch/arm/def-configs/spitz-j'
Then go into Bluetooth Support and set everything as modules and select every option.
Save and exit the kernel configuration.
Edit Makefile and delete the mh18 after the 'EXTRAVERSION ='

Some code needs to be added to the bluez patch and the Sharp kernel sources are missing bits. After the includes at the top of net/bluetooth/bnep/sock.c and net/bluetooth/cmtp/sock.c you need to insert the following:

Code: [Select]

static inline struct socket *socki_lookup(struct inode *inode)
{
 Â      return &inode->u.socket_i;
}

static struct socket *sockfd_lookup(int fd, int *err)
{
 Â      struct file *file;
 Â      struct inode *inode;
 Â      struct socket *sock;

 Â      if (!(file = fget(fd))) {
 Â              *err = -EBADF;
 Â              return NULL;
 Â      }

 Â      inode = file->f_dentry->d_inode;
 Â      if (!inode->i_sock || !(sock = socki_lookup(inode))) {
 Â              *err = -ENOTSOCK;
 Â              fput(file);               return NULL;
 Â      }

 Â      if (sock->file != file) {
 Â              printk(KERN_ERR "socki_lookup: socket file changed!\n");
 Â              sock->file = file;
 Â      }
 Â      return sock;
}
Make sure you have your cross-compile environment setup before doing any compiling.

Then as usual run:
make dep
make modules

You should find the core BlueZ modules under net/bluetooth, which are:
bluez.o
bnep/bnep.o
l2cap.o
rfcomm/rfcomm.0
sco.o

The BlueZ driver modules are under drivers/bluetooth, which are:
bfusb.o
bluecard_cs.o
bt3c_cs.o
btuart_cs.o
dtl1_cs.o
hci_uart.o
hci_usb.o
hci_vhci.o

The bluez-libs and bluez-utils packages are setup using the configure script. For bluez-libs this is simply:

Code: [Select]

CC=arm-linux-gcc ./configure --host=arm-linuxThen run 'make'
The resultant library is bluez-libs/src/.libs/libbluetooth.so

bluez-utils needs to be pointed to the include and libs just compiled in bluez-libs. I think it goes something like:

Code: [Select]

CPPFLAGS="-Iyour/path/bluez-libs/include -Lyour/path/bluez-libs/src/.libs" CC=arm-linux-gcc ./configure --host=arm-linuxThen run 'make' again.
The binaries creates are:
bluez-libs/dund/dund
bluez-libs/pand/pand
bluez-libs/hcid/hcid
bluez-libs/rfcomm/rfcomm
bluez-libs/tools/hciattach
bluez-libs/tools/hciconfig
bluez-libs/tools/l2ping
bluez-libs/tools/sdptool

Hope I got that right.

[Ragnorok]

- SWEET, Tumnus.  Thanks!  I've snagged the indicated source/patches, bookmarked this "HowTo", and will see what havoc may be wrought from it. (wolfish grin)

- BTW, on BlueZ itself, I find it works very, very consistently if I start with BT stopped, and I:
1. Insert the BT card
2. Start BlueZ
3. Run my "fix" script
It will work every single time.  Never lose DNS.  Never fail to pair, even when the phone is "hidden".

- This may or may not have to do with what Bombur mentioned ... for all I know this sequence fixes that, too.  (shrug)  I'm thinking I want to make a connection script that does all this stuff, then ejects the card and shuts down BlueZ when I disconnect.  It will also update /etc/bluetooth/rfcomm.conf, because I'm under the *impression* that BlueZ can't  be configured for more than on channel at a time, but if I want to use, say, wife unit's Stowaway BT keyboard, I'll have to change channels from the one that DUN uses, and I'll be restarting BT, anyway.

- I haven't researched if all that's necessary for a BT device change.  But stopping on disconnect and reloading on connect does seem to dramatically improve stability, so if I can script that, it's going to get done regardless.  I don't mind a few seconds extra wait to ensure things work smoothly.  (grin)

- Thanks for your time...

[speculatrix]

also update /etc/bluetooth/rfcomm.conf, because I'm under the *impression* that BlueZ can't  be configured for more than on channel at a time, but if I want to use, say, wife unit's Stowaway BT keyboard, I'll have to change channels from the one that DUN uses, and I'll be restarting BT, anyway.

I believe you're right, that you can only run one rfcomm channel at a time. Whether it's one per host-host link, or only one on a host, I don't know. I got this from reading about the KDE bluetooth apps.

Paul

[Ragnorok]

- Uh oh.  If I'm a newbie at Z coding, that makes me look like a guru compared to how new I am at the Linux patch process.  (drool)  Followed the suggestions, but two things happened.

- First, the patch file wasn't in gzip format, even though it has a .gz.  It's just plain text, so I looked at the man page for patch and determined that should be done as "patch -p0 < patch-2.4.20-mh18", which I did.

- Second, it failed.  I have two ".rej" files, one at ./lib/Makefile and one at ./drivers/char/pcmcia/serial_cs.c.rej.  The first one's pretty small.  The second bigger.  The patch run also had a number of "Hunk #<so and so> failed at <offset>", which I presume relates to what I see in the .rej file.  SInce this is A) the first patch I've done and B) the first .rej I've looked at, I haven't made a lot of sense of it, yet.  Just thought I'd toss this out in case some simple thing existed to overcome this that I don't know about 'cause I'm such a Noob.

- Here's the patch output in case that's important (sorry it's so long; didn't think to tee it to a file):

Code: [Select]

$ patch -p0 < $BLUEZ/patch-2.4.20-mh18
patching file linux-2.4.20/arch/sparc64/kernel/ioctl32.c
patching file linux-2.4.20/CREDITS
Hunk #1 succeeded at 1344 (offset 7 lines).
patching file linux-2.4.20/Documentation/Configure.help
Hunk #1 succeeded at 12238 (offset 501 lines).
Hunk #2 succeeded at 13878 (offset 17 lines).
Hunk #3 succeeded at 21866 (offset 576 lines).
Hunk #4 succeeded at 21334 (offset 17 lines).
Hunk #5 succeeded at 21961 (offset 576 lines).
Hunk #6 succeeded at 21431 (offset 17 lines).
Hunk #7 succeeded at 22007 (offset 576 lines).
Hunk #8 succeeded at 21477 (offset 17 lines).
Hunk #9 succeeded at 22050 (offset 576 lines).
patching file linux-2.4.20/Documentation/devices.txt
patching file linux-2.4.20/Documentation/firmware_class/firmware_sample_driver.cpatching file linux-2.4.20/Documentation/firmware_class/hotplug-script
patching file linux-2.4.20/Documentation/firmware_class/README
patching file linux-2.4.20/drivers/bluetooth/bfusb.c
patching file linux-2.4.20/drivers/bluetooth/bluecard_cs.c
patching file linux-2.4.20/drivers/bluetooth/bt3c_cs.c
patching file linux-2.4.20/drivers/bluetooth/btuart_cs.c
patching file linux-2.4.20/drivers/bluetooth/Config.in
patching file linux-2.4.20/drivers/bluetooth/dtl1_cs.c
patching file linux-2.4.20/drivers/bluetooth/hci_bcsp.c
patching file linux-2.4.20/drivers/bluetooth/hci_bcsp.h
patching file linux-2.4.20/drivers/bluetooth/hci_h4.c
patching file linux-2.4.20/drivers/bluetooth/hci_h4.h
patching file linux-2.4.20/drivers/bluetooth/hci_ldisc.c
patching file linux-2.4.20/drivers/bluetooth/hci_uart.h
patching file linux-2.4.20/drivers/bluetooth/hci_usb.c
patching file linux-2.4.20/drivers/bluetooth/hci_usb.h
patching file linux-2.4.20/drivers/bluetooth/Makefile
patching file linux-2.4.20/drivers/bluetooth/Makefile.lib
patching file linux-2.4.20/drivers/char/pcmcia/serial_cs.c
Hunk #2 FAILED at 28.
Hunk #3 succeeded at 72 (offset 3 lines).
Hunk #5 succeeded at 152 (offset 3 lines).
Hunk #7 succeeded at 173 (offset 3 lines).
Hunk #9 succeeded at 217 (offset 3 lines).
Hunk #11 FAILED at 243.
Hunk #12 succeeded at 273 (offset 9 lines).
Hunk #14 succeeded at 354 (offset 9 lines).
Hunk #16 succeeded at 378 (offset 9 lines).
Hunk #18 succeeded at 450 (offset 9 lines).
Hunk #20 FAILED at 508.
Hunk #21 succeeded at 552 (offset 31 lines).
Hunk #23 succeeded at 616 with fuzz 2 (offset 58 lines).
Hunk #25 succeeded at 649 (offset 58 lines).
Hunk #27 succeeded at 670 (offset 58 lines).
Hunk #29 succeeded at 689 (offset 58 lines).
Hunk #30 succeeded at 678 (offset 6 lines).
3 out of 30 hunks FAILED -- saving rejects to file linux-2.4.20/drivers/char/pcmcia/serial_cs.c.rej
patching file linux-2.4.20/drivers/char/serial.c
Hunk #1 succeeded at 961 (offset 119 lines).
patching file linux-2.4.20/drivers/input/Config.in
patching file linux-2.4.20/drivers/input/keybdev.c
Hunk #1 succeeded at 166 (offset 12 lines).
patching file linux-2.4.20/drivers/input/Makefile
patching file linux-2.4.20/drivers/input/uinput.c
patching file linux-2.4.20/drivers/isdn/avmb1/capidrv.c
patching file linux-2.4.20/drivers/isdn/avmb1/kcapi.c
patching file linux-2.4.20/drivers/usb/Config.in
Hunk #1 succeeded at 63 (offset 31 lines).
patching file linux-2.4.20/drivers/usb/hid-core.c
patching file linux-2.4.20/include/linux/firmware.h
patching file linux-2.4.20/include/linux/input.h
patching file linux-2.4.20/include/linux/net.h
patching file linux-2.4.20/include/linux/uinput.h
patching file linux-2.4.20/include/net/bluetooth/bluetooth.h
patching file linux-2.4.20/include/net/bluetooth/hci_core.h
patching file linux-2.4.20/include/net/bluetooth/hci.h
patching file linux-2.4.20/include/net/bluetooth/l2cap.h
patching file linux-2.4.20/include/net/bluetooth/rfcomm.h
patching file linux-2.4.20/include/pcmcia/ciscode.h
patching file linux-2.4.20/kernel/ksyms.c
Hunk #1 succeeded at 51 (offset 3 lines).
Hunk #2 succeeded at 585 with fuzz 2 (offset 29 lines).
patching file linux-2.4.20/lib/Config.in
Hunk #1 succeeded at 9 with fuzz 2 (offset -26 lines).
patching file linux-2.4.20/lib/firmware_class.c
patching file linux-2.4.20/lib/Makefile
Hunk #1 FAILED at 8.
1 out of 2 hunks FAILED -- saving rejects to file linux-2.4.20/lib/Makefile.rej
patching file linux-2.4.20/MAINTAINERS
patching file linux-2.4.20/Makefile
patching file linux-2.4.20/net/bluetooth/af_bluetooth.c
patching file linux-2.4.20/net/bluetooth/bnep/bnep.h
patching file linux-2.4.20/net/bluetooth/bnep/Config.in
patching file linux-2.4.20/net/bluetooth/bnep/core.c
patching file linux-2.4.20/net/bluetooth/bnep/Makefile
patching file linux-2.4.20/net/bluetooth/bnep/netdev.c
patching file linux-2.4.20/net/bluetooth/bnep/sock.c
patching file linux-2.4.20/net/bluetooth/cmtp/capi.c
patching file linux-2.4.20/net/bluetooth/cmtp/cmtp.h
patching file linux-2.4.20/net/bluetooth/cmtp/Config.in
patching file linux-2.4.20/net/bluetooth/cmtp/core.c
patching file linux-2.4.20/net/bluetooth/cmtp/Makefile
patching file linux-2.4.20/net/bluetooth/cmtp/sock.c
patching file linux-2.4.20/net/bluetooth/Config.in
patching file linux-2.4.20/net/bluetooth/hci_conn.c
patching file linux-2.4.20/net/bluetooth/hci_core.c
patching file linux-2.4.20/net/bluetooth/hci_event.c
patching file linux-2.4.20/net/bluetooth/hci_sock.c
patching file linux-2.4.20/net/bluetooth/hidp/Config.in
patching file linux-2.4.20/net/bluetooth/hidp/core.c
patching file linux-2.4.20/net/bluetooth/hidp/hidp.h
patching file linux-2.4.20/net/bluetooth/hidp/Makefile
patching file linux-2.4.20/net/bluetooth/hidp/sock.c
patching file linux-2.4.20/net/bluetooth/l2cap.c
patching file linux-2.4.20/net/bluetooth/Makefile
patching file linux-2.4.20/net/bluetooth/rfcomm/Config.in
patching file linux-2.4.20/net/bluetooth/rfcomm/core.c
patching file linux-2.4.20/net/bluetooth/rfcomm/crc.c
patching file linux-2.4.20/net/bluetooth/rfcomm/Makefile
patching file linux-2.4.20/net/bluetooth/rfcomm/sock.c
patching file linux-2.4.20/net/bluetooth/rfcomm/tty.c
patching file linux-2.4.20/net/bluetooth/sco.c
patching file linux-2.4.20/net/bluetooth/syms.c
patching file linux-2.4.20/net/netsyms.c
Hunk #1 succeeded at 168 (offset 9 lines).
$I'm off to see the wizard ... no, that's not right.  I'm off to look at .rej files vs patch info.  That's it!  I'll stick those on here, too, just 'cause I can. (bemused grin)  If'n they aren't present, that because it's also the first files I've posted to the Forum, and may be just botched the whole thing.  (snicker)  Just full o' firsts tonight!

- Thanks in advance...

[tumnus]

Yeah, I got some failed chunks too. It still compiled and worked though. It seems to be centered around the serial driver, but it doesn't appear to have any negative affect as all the serial based drivers are working.

[Ragnorok]

- Cool.  The .rej files are just snippets of the diff that represents the patch.  It doesn't apply the updates for those hunks, at least mine didn't, so I've been manually sticking the mods in.  For instance, the Makefile in the kernal source has an extra "md5.0", so that hunk fails without a match on that dependency line.  I left that there and stuck the new .o on the end.  I've limited time to apply to this, but I'll see what happens eventually.  No rain today, so I was crusin' on the motorcycle instead of debugging.  (cheshire grin)
- I also did the /proc/lock_fcs thing that Bombur suggested ... it's a little more consistent.  If it doesn't work right from inserting the card, it takes quite a bit of fiddling to get it working.  Once it works ... fine as frog hair for that session.  Surf as long as I like.  (shrug)
- Once I get all this built I'll have a look-see at what may be going on in there.  I'd also like to have it scan the phone to see what channel DUN is on this session, since my phone keeps changing that on me for some obtuse reason.  Half the time it doesn't work, the phone either doesn't indicate it supports DUN (which it does), or the channel is different than what rfcomm is set to use.  (befuddled look)
- Thanks for letting me know!  I just don't like failed things ... have to figure out what's up with that (snicker)...