Friday, November 13, 2009

HOWTO: Flooding wireless networks...

Recipe:

1 wireless network
1 part Fedora 12
1 part Pulseaudio gravy
1 foolish setting:


What do you get?! A nice flood towards your wireless network with empty 16-bit audio packets even when no application whatsoever is playing audio.

One thing I don't remember... if I ever activated that setting while playing with my VirtualGL / remote wine gaming setup.. or if it was an effect from the Fedora upgrade... either way, best to double check your own setting after upgrading, as the effect is a pretty dead wireless network at seemingly random times.

Thursday, November 12, 2009

Karmic Koala

Before upgrading ubuntu 9.04 with the br0ken network to 9.10, I grabbed and compiled the mainline 2.6.32-rc6 kernel to make sure I had at least a working kernel to fix issues if the Karmic kernel was broken too.
Since the mainline kernel worked fine, I continued to upgrade to Karmic Koala, which uses a 2.6.31 kernel. I was happy to find out that the ubuntu 9.10 kernel didn't have any issues with my VLAN setup.
I still wonder if the issue was caused by an ubuntu specific patch or if the mainline kernel had issues. Maybe I'll git bisect it to feed my curiosity.

Tuesday, November 10, 2009

Murphy...

Since I was already busy with upgrading my laptop, I figured I might aswell upgrade my home server which was running ubuntu 8.04. However after upgrading to 8.10 my network didn't work anymore. When booting an older kernel it worked fine. Figured it was an issue in the kernel, Ubuntu 8.10 was using and since the target was to get to 9.10, I thought I might aswell continue. So upgraded the 8.10 to 9.04, however the network issue remained. With 2.6.28 on 9.04, I was unable to ping my WRT54G which runs OpenWRT. With 2.6.24 on 9.04 it works 'fine'. My home setup uses a couple of VLANs and it seems that that was causing the problems, without the VLANs the new kernel was able to ping the router.

As it was already getting late, I booted the machine with 2.6.24 and decided to call it a day.

Today, when I tried to initiate an OpenVPN connection to my home server from a remote location, the connection failed. Even a secure shell to the server didn't work. Going via the OpenWRT's shell to the server did work for some bizarre reason.

After some tracing with tcpdump and wireshark, it showed that the port number of the connection was somehow changing... ie. make a connection to port 1000 and it arrived on the server at port 1040 according to the packet trace.

First thought it had to do with the VLAN tagging and that for some reason the ubuntu kernel was interpreting the packets wrong, as I already had issues with the VLAN... but when I did the packet trace on the OpenWRT on the incoming interface, it was correct.. on the outgoing interface however it was wrong... which showed the cause was not with the ubuntu server but with the OpenWRT device. After rebooting it, the connections worked fine again.

Goes to show that when stuff goes bad, it really goes bad.. as in 2 different things going banana's at the exact same time!


Anyway the OpenWRT issue seems to be a bug in the 7.07 Kamikaze release, which is fixed in 8.09

Kamikaze 8.09 Release notes states:

* fix port forwarding NAT issues in brcm-2.4


So it looks like I'll have to update yet another device.

Monday, November 9, 2009

F12 systray / panel spacing

After the upgrade, the spacing between the icons in the systray area was way too large. Apparently it's a 'feature'. *sigh*

Fix with:

$ gconftool-2 --type int --set /apps/panel/applets/systray/prefs/padding 0

Preupgrade to Fedora 12

Used preupgrade to upgrade my Fedora 11 to rawhide / Fedora 12. The upgrade went smoothly except for 1 issue. Apparently my /boot partition was too small (190Mb with 142Mb still free), so after preupgrade downloaded all the packages and reboot into anaconda, I was presented with a nice out of diskspace error. ouch.
I tried to remove some left over old kernels from the boot partition but it wasn't enough. Luckily I always have an external USB drive with me, so I copied the preupgrade image to that drive, tweaked grub to load it from there and that did the trick.

Friday, July 24, 2009

Use the power!

Picked up a pair of Devolo DLAN AV200 HomePlug adapters, since my wireless connection to my desktop which had an USB USRobotics wifi adapter was flakey at best.. and it's not because there's many wireless networks in my neighbourhood (only 3 and my laptop's Intel PRO/Wireless 3945 works fine).

The box mentioned linux compatibility, but I wasn't expecting to find source code to the configuration program for linux.. afterall these things can be run without any computer intervention, so I figured that's why they listed linux.

The copyright notice on the source files is a bit odd though:


/*
dlanconfig.c: dlanconfig software for HomePlug devices for linux

Copyrighted 2007 by devolo AG

Redistribution in source form, with or without modification,
are NOT permitted.
This program uses explicitly confidential information
about HomePlug standard.
*/


Anyway... first impression is positive... the speed is nice, stability also.. the 200mbps claim is a bit misleading since they just have a 100mbit ethernet port, but all of the homeplug devices use that marketing ploy.

Wednesday, July 22, 2009

Wine fun #4

As I mentioned before, I was fooling around with running a game via wine on a remote server. After fixing wine to run the game, it was time to look for improvements in the remote connection.

While it worked via vino / VNC, it wasn't really playable.

VirtualGL and TurboVNC seemed like they could provide a satisfactory experience. My first attempt using TurboVNC as the X11 target for VirtualGL didn't work. It always resulted in a busy loop inside the nvidia closed source OpenGL library.

VirtualGL using the VGL Transport to my fedora 11 laptop, does work however! It's actually quite playable over a Wifi connection. The nice thing about this setup, is that the server is doing all the hard work, hence you could even use an under powered netbook as a game station.

I wonder if there would be much to gain by implementing a more advanced video compression engine in virtualgl. Maybe if I find the time, I might try to hook it up with libavcodec or something along those lines.