How to get Teamspeak 3 running on a current Linux

Teamspeak is know for lagging a bit behind with development.

The last few days I have been upgrading my servers to current distributions, today the Voice servers were on the list to get Debian 6 / Ubuntu 11.04. And again I ran into problems with Teamspeak, turns out they won’t work with libmysqlclient 16 libraries and require the good old 15 version (which isn’t available out-of-the-box in the latest Debian and Ubuntu release).

So anybody running into the same problem (do a ldd libts3db_mysql.so to check), can hop on over to http://packages.debian.org/lenny/libmysqlclient15off and download the package for your architecture and install it with dpkg -i

captcha cracking

This is a pretty old posting from 2009 I just recently discovered in my “drafts” directory. Nowadays there are probably easier and more elegant ways of defeating a captcha, but for old times sake, here is my simple approach.
———————–

Eclectic and Marko were so kind as to “provide” me a captcha to play around with. Took me a few days of poking around and googling but in the end it was easier than I had thought. As long as there aren’t and logic errors in the code (e.g. bad or no session handling) you probably won’t get around some kind of OCR. As OCR software I decided to use gocr because it is free, runs under linux, and it is fairly easy to train to specific needs. Because I knew which libraries were being used to create the captcha images, it was possible for me to build a testing area. This just speeds things up a bit, the process would have worked just as well off the original website. First off: the spambot in action -> http://captcha.dopefish.de/spambot.php, and the website it accesses: http://captcha.dopefish.de/

Now I’ll describe the steps I took to defeat the captcha. Look at what happens on failed and successful inputs, first write a script that works if you enter the solution manually. I used the following 2 php functions for getting and posting stuff (and keeping the session intact)

Now train a gocr database for the images. Obviously it get’s better the more you train it.
Since curl is taking care of  session handling, we can use the get_url() function for downloading the captcha image. I pipe it through this shell command to make it easier for gocr to read:

It turnes this:

into this:

Since the valid captcha result is always the same length, we can check if gocr matched all the chars. If it looks good we can use post_url() to continue our session and throw all the fields at the form and submit it. See, wasn’t that hard. Most of the time is spent training gocr and converting the image into something easier to read. It doesn’t solve 100% of the images, more like 80-90%, but still better than nothing ;-).

Wireless bridge & dd-wrt

I recently bought the WL-330gE_M from Asus. It is a pair of access points pre-configured to bridge 2 LAN networks via wireless, all you have to do is take them out of the box and plug them in, straightforward and simple, no configuration needed. They are intended to enable hooking up devices to the internet that don’t have wireless and without pulling cables through the house (e.g. dvd player, TV, cable box, …).

The package arrived last week and it was a matter of minutes plugging the devices in and having everything working.  Everything worked without any setup, took me longer to get them out of the box than to hook them up.

 

Unfortunately our network storage (NAS) is also on the other end of this wireless bridge, and I noticed that when I move large files around (>2GB) or while streaming video/audio off the NAS the connection was dropping out. I don’t mean “ups and downs in the speeed” that is to be expected over wireless, I mean “connections resetting, copy actions aborting with error messages”. Not fun. Unfortunately since the devices are geared toward the “no configuration necessary, just unpack and hook up” crowd, there is no webinterface to see a syslog of what is happening or changing settings. Nada.

After this happening a few times it got really frustrating. I can live with slow, but connections dropping is out of the question. My original plan was to just reset the devices, flash them with a WL-330gE firmware and reconfigure the bridging (the only difference I could find was that the WL-330gE_M is black and not white, and comes preconfigured, and probably has a slightly different firmware without management capabilities).  While I was looking at different options and possibilities I went over to dd-wrt and happily saw that the WL-330gE was supported in the router database. So I decided if I was going to mess around with firmware, I could just as well throw dd-wrt on it.

Even though I am a system administrator, I don’t have the urge to have every device in the house running on Linux with a shell I can ssh in to. I’m perfectly fine with a simple interface that does what I want it to. But the wireless settings I can fine tune in dd-wrt are priceless (especially since I wanted to debug and fix the connection dropouts), normally you only get these options with cisco grade hardware.

The firmware upgrade process of the devices is simple and straightforward. Pull and reapply power with the reset button pressed until the power LED starts flashing, then shove the new firmware onto the device via tftp. Either with the “Firmware Restoration” tool from asus, or with a normal tftp client. I used later. Since this is so straightforward I guess I could also switch over to the official firmware if I wanted to, making two WL-330gE out of the WL-330gE_M pair (saves money since the pair is cheaper that buying two separately).

When in recovery mode (waiting for someone to tftp a new firmware onto it), the device has the IP 192.168.1.220 by default. This is just a rough summary of the steps, anyone wanting to do this should really read through the whole process of deploying dd-wrt with asus, there is important information there (even if the example is a WL500, the WL330 is similar). Just because it worked for my hardware,firmware,setup doesn’t mean you have the same hardware or are deploying the same version I did. Read the dd-wrt documentation before you brick your device.

Clear current settings from the nvram:

Wait 5 min, reboot into recovery, throw a dd-wrt firmware on the device ( I used DD-WRT v24-sp2 (08/12/10) mini – build 14929, standard works fine too).

Wait 5 mins, reboot and open http://192.168.1.1 To be on the safe side feel free to navigate to Administration -> Factory Defaults to make sure no junk was left behind.  To get bridging configured there are multiple possibilites depending on your needs. For plain LAN bridging you will probably want WDS or one device setup as a AP and the second as a Client Bridge (I used the latter option). One thing you will want to do is go to Setup -> Networking and set the WAN port to “disabled” since the device only has LAN and Wireless.

The rest is fairly ease, set up one device as an AP, chose WPA2 with a good long strong PSK. After testing if the AP works with e.g. a laptop, you can set up the 2nd device as a Client Bridge, just make sure you are on the same channel, same SSID, same security settings.  After everything is up and running now would be a good time to pull backups from the configuration. Might as well tweak around in the wireless advanced settings. If you mess up anything badly enough that it won’t connect again … well that is why you made the configuration backups 😉

As you probably guessed by now, the connection drops are gone, connection is smooth and stable. Peak speed is not quite as fast as before because I throttled some things and tweaked settings for stability, but still good. Turning the TX antenna output power from 71 down to 65 helped a lot and got the maximum out of the connection (probably less crap pulling my SNR down). And now I can see what the access point is doing and where problems are when they arise 😉

back online

The hard drive crash threw me offline a few days due to strange problems with software raids, Xen and acpi. Turns out that using the latest Xen kernel from debian testing branch on a software raid only works of you don’t set “acpi=off” as a kernel parameter. If acpi is turned off, the script “scripts/local-top/mdadm” in the initrd can’t find the devices needed to mount the software raid … causing the whole boot process to come to a grinding halt.

If I find some time I’ll do some more tests, untill then my server will be running with acpi turned on

btw. the hard disk replacement was easy. after the new drive was popped in it was just a copy the partition table and add the partitions of the new disk to the raid

Serverdown

Server was down for the last 6 hours due to me updating a few stuff that really really didn’t work out too well (grub, xen and kernel at the same time). I gave up and afer a few hours of work managed to revert back to the old configuration so I can recieve mail again till I figure out what went wrong. Server may be down tomorrow a bit too while I try to figure out what exactly broke and try to at least get grub and xen updated.