blog of Joost Yervante Damad
lang:en
amavisd-new clamav crashes tmp files
May 7th
Since I still run my own mail infrastructure, I also run anti-spam and anti-virus on it.
Today I noticed that free space on my server running lenny was ALOT less then usual. Turned out that clamav was crashing all the time causing lots of temporary files in /var/lib/amavis/tmp.
An upgrade of clamav also stopped the crashes.
While at it I also disabled quarantining virus mails, I never had to retrieve any mail out of there anyway…
Nokia N82 Bluetooth + GPRS/3G
Feb 12th
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!
how to set a serial port at MIDI speed in linux
May 30th
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.
usb tiny isp programmer / user accessible
Apr 28th
To make an usbtiny programmer usable directly as user from avrdude or the arduino toolkit, add the following line to a new file in /etc/udev/ :
ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", MODE="0664", GROUP="plugdev"
I created a file called /etc/udev/joost.rules with this line.
Reload udev with /etc/init.d/udev reload
arduino toolkit on x86_64 linux Debian/Ubuntu
Apr 28th
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!
glibc 2.9 – maradns
Mar 1st
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.
