Connecting to WIFI from commandline in Linux

For the longest time I was unable to properly connect to any WPA2 enabled WiFi from Linux from pure command line in Ubuntu/Fedora, and had to rely exclusively on NetworkManager. While NetworkManager does a good job of connecting to new networks etc, I wanted more control over the connection process, since I was trying to configure my old thinkpad as a secondary router. In this aspect NetworkManager added unnecessary layers of complexity and opaqueness to the whole process, and frankly sucked.

So after a very long time I was able to properly figure out the simplest set of commands (Run as root user/sudo). Hopefully this helps folks who are trying to manually configure the network.

#!/bin/bash

set -ex

# This can be any file used in the wpa_supplicant command.
WPA_SUPPLICANT_PID_FILE=/var/run/wpa_supplicant.pid
WPA_CONFIG_FILE=/etc/wpa_supplicant.conf

# You can get it from lsmod.
WLAN_MODULE=iwl3945

# You network specific configuration.
IFACE=wlan0
SSID=
LOCAL_IP=
NETMASK=
ROUTER_IP=

# Cleans up any previous state (Optional)
modprobe -r ${WLAN_MODULE}
modprobe ${WLAN_MODULE}

# wpa_supplicant requires the interface to be up.
ifconfig ${IFACE} up

# Do not restart wpa_supplicant if this exists.
if [ ! -f ${WPA_SUPPLICANT_PID_FILE} ]; then
        wpa_supplicant -c${WPA_CONFIG_FILE} -B -i${IFACE} -Dnl80211 -P${WPA_SUPPLICANT_PID_FILE}
fi

# Configure static ip.
ifconfig ${IFACE} ${LOCAL_IP} netmask ${NETMASK} up

# Exit at this point if you want to prevent this from accessing the internet.
# exit 0

# Configure default route.
route add default gw ${ROUTER_IP}

# Add Google's DNS servers for name resolutions, coz comcast's DNS is slow and sucks!
echo nameserver 8.8.8.8 > /etc/resolv.conf
echo nameserver 8.8.4.4 >> /etc/resolv.conf

Google DNS server

Now-a-days my airtel DSL connection's DNS servers fail to resolve some DNS addresses. I dont have an idea about what the problem is, but frequently I see many domains unable to be resolved and sometimes pretty slow too. So I decided to move to using the Google Open DNS Server. The IP is also a beautifully easy to remember - 8.8.8.8 . 8.8.4.4 is another DNS server of google which can be used as an alternate.

To keep this IP from being overwritten on my Fedora 12 Box, I figured out that the best way to do it would be to write a new file in /etc/NetworkManager/dispatcher.d/ which I names as 25-setdns with the following contents

#!/bin/sh
if [ "$2" = "up" ]; then
cp -f /etc/resolv.conf /etc/resolv.conf.BAK
echo nameserver 8.8.8.8 > /etc/resolv.conf
echo nameserver 8.8.4.4 >> /etc/resolv.conf
fi

This will ensure that the Google DNS will always be used to resolve my domain names.

Do note that I took a very crude, but simple approach here since I dont use any VPNs. If you do use VPN software, then you should make sure that the google DNS is the next entry. since your VPN's local DNS will resolve your VPN internal domains, which are unknown to outside world!

For the paranoid, this is yet more information you are pushing to google! :D

TCP Offload Engine support in Linux

TCP Offload Engines (TOE) are customized hardware which handle TCP connections completely in the network card itself, instead of in the kernel. Lately 10Gbps Ethernet cards are becoming the industry standard in the high end server market. A simple rule of thumb regarding TCP processing in the CPU requires 1 HZ of CPU for every 1 bit of TCP data handled per second. This means that a 10GigE card, requiring 10 GHz, can quickly eat the CPU like there is no tomorrow. Even with multiple CPUs and multiple cores per CPU, the impact is significant.

Added to this, IEEE standards are already being prepared for 40Gbps and 100Gbps Ethernet. So in this situation, using TOE becomes inevitable. There are already many TCP functions already being done in hardware like checksumming, LRO (Large Receive offload), LSO (Large Send Offload) etc. But a TOE provides a complete end-to-end solution.

TCP Offload Engines were never a hit with the linux networking community. Linux Kernel Maintainers, esp David Miller, have been against the idea of TOE due to various valid reasons like it reduces maintainability of code, etc. Also the kernel maintainers argue that TOE was only a stopgap solution, before CPU speeds caught up with the loads, citing cases in the past where TOE was implemented even for 100Mbps links. More details about their position can be found in this article - Linux and TCP Offload Engines. This has caused a situation where the 10GigE vendors like Chelsio are forced to maintain the TOE patches to the Linux kernel, out-of-tree. This causes the code to be inherently unstable.

Anyway, the end users do not face any loss of functionality since the vendor provided patches to the Linux kernel can be used to build kernel modules, which provide support for TOE hardware in Linux machines. This is what I like about Open Source. You do not have to be bound by what others think. You leave that decision to time.

Tunneling to the inside - using SSH

Many networks are setup in such a way that you can access a machine (lets say GGG) in the network through SSH and then you can access any other machine (lets say XXX) in that network using protocols like SSH, telnet, samba etc. But wouldn't it be great to access those services right from the machine (lets say LLL) you are sitting at itself?

Enter the SSH Tunnel. SSH tunnel could be used to create an end to end SSH connection between the local machine (LLL) and the gateway machine (GGG). Then you can access any machine (XXX) from (LLL) itself. The best part is you do not have to be root for this!

First establish the SSH tunnel connection between GGG and LLL using the following command on LLL

ssh user@GGG -L 2000:XXX:22 -N

where, 2000 is the local port on LLL which will act as
       a gateway (this can be any port you want)
22 is the remote port on the machine XXX to which you 
       want to connect to (For example this will be 23
       for telnet, 139 for SMB, 22 for SSH etc)

Now your tunnel is setup. Just connect to the machine by connecting to LLL on port 2000 - you will be automatically forwarded to connect to 22 on XXX machine!

TCP Congestion

It surprises me to no end that TCP, the most widely used protocol, has remained practically unchanged from its RFC proposal in 1982. From a time where connections were in hundreds of bytes per second to 10Gbps links now-a-days, It is still used in a more or less unchanged form.

However this flexibility comes at a cost - you will not get the maximum throughput your link supports right away. The "right away" part is important. True TCP can eventually take up the entire bandwidth. But there is an over looked issue - TCPs Congestion control. TCPs congestion control rapidly reduces the connections speed as soon as it starts seeing lost packets, and it does not recover as quickly. This has caused linux to adopt newer congestion control algorithms in TCP in a pluggable fashion.

The default congestion control algorithm is CUBIC which is a less aggressive version of BIC. You have a plethora of congestion control algorithms to choose from. They can be checked by reading from and changed by writing to /proc/sys/net/ipv4/tcp_congestion_control file.

This Linux Gazette article has a detailed description of the remaining options.

Drivers & Hardware

My friend who works in NVidia always complains about how Software drivers have to cover all the mistakes in the hardware. I never faced any issue like that, until today. There was this GBPS network card which gives a pathetic netperf throughput of 780Mbps. After checking a lot of stuff I chanced upon a discussion in netdev about the same driver and how the driver works around a software bug by disabling a very important feature.

I removed the workaround from the kernel, recompiled and installed it on the test machine. I ran netperf and presto! It comes to 989Mbps, as close as possible to the line speed of the interface! As for the hardware bug, it does not get triggered in this particular hardware setup since it requires the PCI-X bus running at 100/133MHz, whereas the test machine's bus is only 66MHz. Problem solved.

Same Subnet Interfaces in Linux issue

I always thought that the Linux Networking stack was a fully functional component which is never lacking in features, when compared to other OSs. However a few days ago, I came across a missing piece of functionality - interfaces on the same subnet issue.

You see when you configure 2 interfaces on the same subnet, and try to talk to other machines in the subnet, something unexpected happens. The packets can come in on both interfaces, but can leave only on one of them! This is because of the inherent design of the Linux Forwarding Base, which routes solely based on the destination address, ignoring the source.

Ofcourse its not a deadend in any way. You can still configure a bonding between the 2 interfaces and then assign the 2 ips to the bond virtual interface. But that would be too much trouble, and not exactly a solution for someone seeking resource compartmentalization. Solaris provides a concept called interface grouping for this issue.