HD audio buzzzzzzz
So… I’m using a dangerously long audio cable to connect my computer. It’s always caused a buzzing sound when connected to the amp but not my computer. No surprise there.
After a recent hardware refresh, though, it started buzzing while the computer is powered up and connected. It will start buzzing about 10 seconds after a sound is played and continue buzzing until another sound is played. This behavior immediately made me think of a Karmic release note about putting sound cards to sleep.
After figuring out where the kernel documentation is for Ubuntu (it’s the linux-doc package), powersave.txt confirmed my suspicions. The easiest solution for me was to disable this sleep behavior. I’m using a desktop and while it might be nice to put my sound card to sleep, it’s really not necessary.
It turns out that this option is explicitly set to the default in Ubuntu 9.10 in /etc/modprobe.d/alsa-base.conf. To disable this behavior, all you have to do is set power_save=0 in the snd-hda-intel options line. You can change the setting in the running kernel via /sys/module/snd_hda_intel/parameters/power_save.
After a quick “echo 0 >> /sys/module/snd_hda_intel/parameters/power_save”, everything was back to normal, and I could get on with my day.
rsyslog and logwatch don’t play well together
Notice a hell of a lot fewer log messages being reported since you’ve upgraded to a modern syslog supporting RFC 3339-style high-precision timestamps? Yeah, me too.
It seems as though logwatch doesn’t support these timestamps, so it silently filters out all messages recorded by my rsyslog daemons. What’s worse is that I can’t easily figure out a way to disable that behavior. It’s implemented using an executable filter, and — while there’s plenty of documentation about how to override configuration in /etc/logwatch — there’s no documentation about how to *remove* a filter.
Oh well. I never much liked logwatch, anyway. I mostly don’t like any log monitoring scheme that requires me to read through hundreds of daily e-mails that almost always report everything is normal. That’s not sustainable…
freeswitch/sofia doesn’t parse resolv.conf properly
After extensively testing freeswitch in my dev environment — and really liking what I saw — I installed freeswitch 1.0.3 to my production server… and immediately got a seg fault on my first configuration change. This was a bit perplexing. Throughout my entire testing period I didn’t experience a single crash, and here was one 3 minutes into my first install.
The core file illuminated the fact that the sofia library in freeswitch was attempting to dereference a null pointer (in an error handling routine of all places) caused by an empty DNS response. A tcpdump revealed that sofia was attempting to send the DNS query to localhost (strangely) and was being refused (not strangely). Upgrading to 1.0.4pre8 fixed the segfault, but didn’t change the DNS behavior.
It turns out that sofia implements its own resolver instead of using the system resolver. Sofia attempts to discover its nameservers from /etc/resolv.conf, but it uses a somewhat more naive parsing than the system resolver. My production system contained a same-line comment in the nameserver line that was not being parsed out. As a result, sofia attempted to do an inet_pton(3) on “192.168.1.1 # comment”, which failed. When all nameservers failed, sofia inserted 127.0.0.1 as a last-ditch effort to find a resolver.
I’ve created a patch to remedy this behavior and submitted it to the freeswitch dev team.
Update: freeswitch has integrated the patch into their trunk, so if you’re having this problem just update your copy.
racoon only matches against the first IP subjectAltName?
I haven’t examined the source yet to make sure that I’m right, but imperical evidence leads me to believe that racoon is only recognizing the first IP field in an x509v3 subjectAltName extension. That is, for the following certificate:
X509v3 Subject Alternative Name:
DNS:arthur.example.org, IP Address:192.168.35.24, IP Address:10.14.82.152
It appears that only the 192.168.x.x address will be accepted as a valid ID by racoon. Requests with an ID of 10.14.82.152 will be discarded with the error message: ID mismatched with subjectAltName. So far I’ve only tested this with anonymous remote nodes.
Sierra Wireless mobile broadband modem differences
As I was recently signing up for Sprint’s mobile broadband solution, I was presented with the choice between the Sierra Wireless USB 598 modem and the older Sierra Wireless Compass 597 USB. I couldn’t find any explanation of the differences between them, so here’s what I’ve found so far:
- The 598 is prettier with bright, attractive LEDs.
- The 598 supports higher capacity micro-SD cards
- The 598 comes with a longer USB extension cable and a laptop clip to attach the modem to the top of your laptop screen. (I miss this quite a bit, surprisingly)
- The 598 has a power saving mode that turns off the modem when the Sprint Smartview application isn’t running (OS X)
- I can’t get the USB disk feature to work at all with a 2GB micro-SD card on my 597, though I suppose mine could be broken
In the end I went with the 597 because of the out-of-the-box Ubuntu support in 8.10, but the 598 is better for non-Linux use. Of course, I get the impression that Sprint won’t be carrying the 597 for much longer, so the point may be moot…
So far I’ve gotten excellent customer support from Sprint. I’m really not used to such kind, helpful and competent assistance from a mobile company, so I felt like I should mention it.
pfsense, dnsmasq & source interfaces
I’m having issues with dnsmasq on my pfsense router being unable to contact an overridden nameserver because they’re not being sourced from an interface that has an ipsec policy. For example, I have the following config:
Main Office Router A:
LAN address: 192.168.1.1/24
WAN address: 24.1.2.3
Remote Office Router B:
LAN address: 192.168.2.1/24
WAN address: 64.1.2.3
The two sites are connected by an ipsec tunnel. My internal nameserver serving the domain “company.local” is at 192.168.1.10.
Since the remote office is on the other side of the world, I want to use the ISP nameservers for internet resolution, but send all resolutions for company.local through the tunnel to 192.168.1.10.
When dnsmasq sends the packet to 192.168.1.10, however, it uses the default route and sends the packet out of the WAN interface and not through the tunnel. My first thought was to instruct dnsmasq to use the LAN interface as its source address, such as:
/usr/local/sbin/dnsmasq -l /var/dhcpd/var/db/dhcpd.leases -s remote.company.local –server=/company.local/192.168.1.10@192.168.2.1
Indeed that works, but web UI doesn’t allow for that sort of syntax, afaik.
Failing that, I tried adding a bogus route on Router B in hopes that the packet will be redirected through the ipsec tunnel before actually being transmitted on the LAN interface. I added a static route for 192.168.1.10/32 to the gateway 192.168.1.1. This appears to work, so my problem is resolved for now. It doesn’t seem to be a particularly elegant solution, however.
Simple encrypted disk images in Linux
The Linux kernel supports encrypted loop images via the cryptoloop driver, so you can use losetup(8) to create simple encrypted loop devices for those situation when cryptsetup/LUKS/device-mapper is unavailable or too complicated.
You’ll need the following modules loaded (or compiled in):
- loop
- cryptoloop
- twofish (or whatever algorithm you prefer)
First you’ll need to allocate the file:
# dd if=/dev/zero of=<file> bs=1k count=<fs-size-in-kilobytes>
After that, you can ask losetup to loop it to the first free loop device and report back which it chose:
# losetup -e twofish -f -s <file>
The first time out you’ll want to format the device (e.g. mke2fs -j /dev/loop0), after that it’s just a matter of mounting (mount /dev/loop0 /mnt). After you’re done you can use losetup to close the file and remove the device:
# losetup -d /dev/loop0
An important note about this method is that there is no sort of password validation. Whatever password you enter will be used by the encryption algorithm. That means if you enter the incorrect password then you’ll just read (or worse: write) a bunch of garbled data from the device.
Helping openssl find your cert
For those situations where you end up with a directory of certificates — openssl will use a hash to look up the cert it needs in that directory. You can generate that hash using the following command:
openssl x509 -hash -in <cert.pem> -noout
openssl will then look for HASH.0 for the certificate and HASH.r0 for the CRL associated with that cert.
For example, the following could be useful:
# ln -s ca.crt `openssl x509 -hash -noout -in ca.crt `.0
# ln -s ca.crl `openssl x509 -hash -noout -in ca.crt `.r0
racoon requires subjectAltName for x509 IKE
Having trouble getting your ipsec working with x509 certs? It would appear that racoon requires the subjectAltName extension to be set. It won’t use the CN. You have to set a subjectAltName field even if it contains nothing besides a copy of the CN.
Heed this warning, or you’ll fall victim to the following:
racoon: 2008-12-02 14:47:21: ERROR:
racoon: 2008-12-02 14:47:21: ERROR: failed to get subjectAltName
racoon: 2008-12-02 14:47:21: ERROR: no peer's CERT payload found.
Of course… the misery that is tricking openssl to create a cert with the subjectAltName in it is outside the scope of this simple blog entry. Maybe a lengthy one at a later date…
http://www.mail-archive.com/openssl-users@openssl.org/msg47641.html
Installing Apache modules on Mac OS X Leopard
Installing mod_python on my mac laptop was surprisingly difficult. My first attempt of simply compiling it with {LD,C}FLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64" failed in a bit of a strange way. It appeared to create a universal binary for the DSO, but apache failed to load it with the following error message:
httpd: Syntax error on line 118 of /Volumes/Workplace/pflex/2.1.x/Build/build/ValidationWeb/apache/etc/httpd.conf: Syntax error on line 22 of /Volumes/Workplace/pflex/2.1.x/Build/build/ValidationWeb/apache/etc/platform/i386.Mac OS X/httpd.conf: Can't locate API module structure `python_module' in file /usr/libexec/apache2/mod_python.so: dlsym(0x100201000, python_module): symbol not found
As it turns out, the build process was respecting the LDFLAGS & CFLAGS for processes called directly by make, but it was not passing them on to apxs. Adding the following to src/Makefile (after the initial INCLUDE declaration) worked to put apxs on the right track:
INCLUDES+= -Wc,-arch -Wc,ppc -Wc,-arch -Wc,ppc64 -Wc,-arch -Wc,i386 -Wc,-arch -Wc,x86_64
INCLUDES+= -Wl,-arch -Wl,ppc -Wl,-arch -Wl,ppc64 -Wl,-arch -Wl,i386 -Wl,-arch -Wl,x86_64
So, the procedure to install mod_python is:
- Download source here
- ./configure
- Add above two lines to src/Makefile
- make
- sudo make install or sudo make install_dso
tech stuff. 
You must be logged in to post a comment.