Entries Tagged 'Linux' ↓

Moblock is a fantastic alternative to PeerGuardian for Linux systems. Running some form of blocking software is important to protect your privacy when using P2P applications like BitTorrent and Gnutella; if you’re not using anything, you should be.

Unfortunately, in it’s default configuration the filtering can be a little aggressive. There is nothing whitelisted (explictly allowed), so any IP address caught in the filter is blocked. This list of filtered IP address ranges includes addresses belonging to Microsoft and Google, meaning that all traffic to those companies is blocked - including HTTP traffic and instant messaging.

To enable both MSN and Google Talk, find the following line in the file /etc/moblock/moblock.conf:

#WHITE_TCP_OUT="http https"

Now, remove the ‘#’ from the start and add the ports as follows:

WHITE_TCP_OUT="http https 1863 5222"

Presto!

The numbers 1863 and 5222 are the port numbers for the MSN protocol and XMPP protocol that Google Talk uses. If you have another application that is being blocked by Moblock, you should be able to find what port it uses here.

For installation instructions on Ubuntu, check out this Ubuntu Forums thread.

Like any self-respecting geek, I run Linux on my box at work. We have an internal Fedora mirror, so Fedora Core 6 is used by quite a few of us. (A few of the others use an internal deployment of IBM’s OpenClient, which was recently announced).

I recently noticed that after a regular “yum update”, the network on my work system was running slow. Not just a little slow, REALLY slow. As in 3 kB/s slow. Initially I wrote it off as network congestion, but after chatting with colleagues I realised that the slow speeds were limited to only some of the Linux machines in the lab.

Googling found nothing, so I had to grin and bear it until the sysadmin found a fix. After a while, he came across this solution (from here).

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

Apparently kernel 2.6.17 and later has some changed window scaling parameters which were messing with an upstream router somewhere. Unfortunately, we had no way of finding out which router it was as it’s beyond our boundary firewall. Setting the scaling to 0 seems to have fixed the problem though.

Thanks Nathan!

UPDATE 2007-04-04: Looks like Microsoft Windows Vista is having this problem as well. According to this article on Ars Technica the problem is caused by upstream routers or packet filters not being aware of RFC 1323, which introduced the TCP window scaling parameter, and incorrectly dropping otherwise valid packets.