lang:en

A few months ago I did an interesting discovery about using my cellphone to go on the internet via bluetooth. I had this strange situation before where it just stopped working, and after revisiting all configs it worked again.

What really happens is that my cellphone somehow crashes, after which I power cycle it by removing the batteries. The phone then boots again, but here is the twist: the service channels in the phone are re-allocated and apparently in a random order!

This implies that the RFCOMM channel configured in the /etc/bluetooth/rfcomm.conf file is possible wrong now!

Solution: just browse the services again with sdptool browse, adapt the file and it should work again!

Linux serial ports only work at standard speeds by default. MIDI runs at 31250 baud, which is not a standard speed. However there are tricks to get custom speeds, but documentation is quite fuzzy. This is a simple recipe that worked for me with an FT232 USB-Serial board.

Check the baud base of the device:

$ setserial -g -a /dev/ttyUSB0
/dev/ttyUSB0, Line 0, UART: unknown, Port: 0×0000, IRQ: 0
        Baud_base: 24000000, close_delay: 0, divisor: 0
        closing_wait: infinite
        Flags: spd_normal low_latency

As you can see the baud base is 24000000 here.
Next calculate the divisor by dividing the baud_base you see here by the speed you want.
In my case 24000000/31250=768.

Apply the new setting:

$ setserial -v /dev/ttyUSB0 spd_cust divisor 768

Next start your serial application, you might want to make sure it is already set to the correct speed before you do the above changes else it might destroy your settings. The correct speed is 38400 baud, which is now aliased to 31250.

With minicom just use the menu (CTRL-A Z) to change the settings.

Screen can be used like this:

screen /dev/ttyUSB0 38400

Exit screen by pressing CTRL-A CTRL-\

Sweet.

Update:

I received an email from Ethan Bisset with a much nicer solution: just use the debian provided serial library instead of the one provided with the arduino software.

This is his recipe:

1. Get arduino software
2. apt-get install sun-java6-bin binutils-avr avr-libc gcc-avr librxtx-java
3. Untar arduino software
4. Delete <arduino>/lib/librxtxSerial.so
5. Done!

(below is the old entry:)

Download the linux 32-bit arduino toolkit from the arduino toolkit download page and untar in a directory.

Install the avr tools: apt-get install avr-libc binutils-avr gcc-avr

Install “ia32-sun-java5-bin”. ( apt-get install ia32-sun-java5-bin )

Adapt the “arduino” startup script script and replace java in it by

/usr/lib/jvm/ia32-java-1.5.0-sun/bin/java

Execute the “arduino” startup script. It works just fine now.

Thats all.

Many thanks to the Debian java packagers for providing this 32-bit compatibity jvm!

As Debian has been released my “unstable” box recently upgraded to glibc 2.9.
This caused DNS resolving to mysteriously fail in some applications.

Turns out that only IPv6 enabled applications suffer.

Apparently libc now fires both an IPv4 and IPv6 DNS resolving request in parallel. It looks like some DNS servers don’t handle that correctly and answer an error on the IPv6 request before the IPv4 request even has time to resolve further in the internet.

In my case it was my local NSLU2 running Debian lenny causing the trouble, more specific the maradns local DNS server and DNS proxy running on it.

I manually upgraded maradns to the latest version (> 1.3.10) and things are “back” to normal.

Another solution is to disable IPv6 systemwide but I prefer not to do that as I use IPv6 occationally for testing.

I fear that this will cause more trouble for alot of people with routers doing DNS proxying.