Of server racks and linux distro’s

Ok, so for my industrial experience project, an opportunity to have a server housed in an ISP’s datacenter for our source control system was made available.

What an excellent proposition, no bandwidth charges, fast link for everyone concerned (no more sharing my precious torrent upload bandwidth, ha!). The only catch, you have to install your software on an aging Cobalt 4i Rackmount Server.

Just to give you a rundown, the cobalts use an OS based on Redhat Linux 7. Not too bad, they also have an aging pkg format to install stuff on, however there aren’t many packages available nowadays for this.

So, the unit itself is great, but I do want to get svn running and apache2 to make use of committing over port 80. This meant it was time for a new distro.

Basically getting a recent linux distro to run on it is possible, but there are a couple of hoops you have to jump through.

  1. The ROM

    The box we had come with a 2.3.35 rom installed. The first step was to go to the sourceforge Cobalt-ROM project and update to 2.10.3-ext3-1M rom in order to make available the bulk of the linux distro’s available to us.
    Since the original cobalt site has been down for a long time, so too were the instructions of how to install the flashrom. Although its work-out-able, flashing ROM’s especially when you are going by guesses greatly increases the chances of bricking your router. Thankfully the bottom half of this page explains the steps involved. Especially making a backup of the existing rom first just in case things go awry.

  2. Weapons of Mass Panic

    W00t! Power cycling the router bought some nice new LCD graphics (ok, Kon, get a grip, they are just mono-colour pixel graphics). This allowed me to guess that the flash was successful but after a little waiting all I had on the screen was a clock icon, with Sun Cobalt written at the top and a knight rider esk cursor moving from left to right and back again. Ooops! Maybe its taking longer getting used to its new life in the new rom? Once ten mins had passed and it was still the same, I recall reading that the boot rom defaults to booting from a network. This means that there must be a way to configure it. Here was my saving grace. Hold down the S key on bootup and you’ll get to the boot options menu where you can choose to boot from disk instead of network. The network option i guess will come in handy later.

  3. Re-Conception

    So now we have our Rom upgraded, the next step is to prepare a new distro. There are a couple of options for this. One is to use a slave PC to install the linux distro of your choice on, install some additional packages to allow the boot time stuff to kick in. There is one distro in particular CentOS which has a BlueQuartz system which basically is the open source equivalent of the Cobalts current web UI and server config management (along with the server packages themselves). This may be the most ideal option. To get the a linux distro onto your system you can do one of two things (there may be more but these seemed the most appropriate)

    1. Pay $85 AUD and buy Strongbolt, the CD installer for the CentOS + Bluequartz. Strongbolt is a bootable ISO that will install the updated ROM and CentOS over Ethernet.
    2. Install onto a PC then transfer the hard drive across. Cheap, a bit of a muckaround, but doable. If you want Bluequartz, then Nuonce have the distro as a free (and slow download)
    3. Null Modem serial cable< - Does anyone have these anymore?
    4. I’ve seen Gentoo, Fedora, Debian and other distros have Cobalt installation pages dedictated to them.

I’m going with Nuonce, because of the additional packages they have available and the much less stuffing around. Beware that the installer will assimilate itself to any hard drive you have in the PC that you put the CD into. My friend unfortunately found this out the hard way.

Strengthening Archilles Heel

http://kbserver.netgear.com/kb_web_files/n101496.asp

The Netgear WGT634U router has been giving me connection woes of late. I’ve had to hard reboot it a few times before any client machine could connect wirelessly. Given I want to run some permanent services on my desktop, I want to swap it around with my Linksys WRT54G.

I thought I found my answer until I realised that making the WGT634U an access point, would not make it a client.

The ToNot plan I had:

  1. Backup existing router settings.
  2. Reflash the Linksys back to its original firmware (from OpenWRT)
  3. Follow the instructions at the Netgear support page to turn the WGT into an access point. I learnt this was possible for the WGT634U thanks to this support post.
  4. Connect the Linksys to the DSL Modem (via WAN port) and configure to connect to internet. Set it as 192.168.1.1, turn on DHCP. Pick a new SSID to reflect this new networks config.
  5. With the WGT634U having DHCP off and a different SSID to the one above per Netgears instruction
  6. Hope I can still connect – its not going to work. How will the Netgear know to connect to the devices on the linksys’s network? If I set the SSID’s to be the same, then that is relying on wirelessly bridging which is what I’ve already tried. I need the netgear to work in a wireless client which requires OpenWRT/OpenWGT
  7. Also Hope that I can get 108Mbps transfer when my 108Mbps wireless NIC talks to the WGT634U.

An alternate plan comes to mind

  1. Sell the WGT634U

OpenWRT Client Mode HOWNOT

http://wiki.openwrt.org/ClientModeHowto

I’ve got a new place that is much bigger, and a spare WRT54G router, so my natural thought was to use the WRT54G as a wireless client for my desktop which is now out of wired ethernets way. There is a selection of specialist firmware for the WRT54G which allows client mode. I’d been eyeing OpenWRT for a while and thought this was the way to go.

The first thing is to enable boot_wait on the router so you can install the firmware. As you are probably aware by reading a few different sites, the linksys has a hack where you can inject commands via the Diagnostics-> Ping address. Whilst subsequent firmware versions prevent this hack, some clever monkeys devised some javascript to exploit the ping_times field on the latest firmware. Check the forums for more info.

This was done by installing the OpenWRT firmware but I’ve had hours and hours of headaches getting the thing to work.

My problem was that I jumped straight into the web interface and changed many things from their defaults. I was also trying to follow the various how to’s and guides on the internet and so when it actually came time to try and do some connecting my router had some very confusing settings. Reading the nvram settings too was difficult because the old linksys firmwares settings were still there too.

The answer was to erase the nvram, reboot and run the firstboot command (as per the troubleshooting page). I then followed the instructions to configure a Bridged client (disable dhcp by disabling access to the dnsmasq script in etc/init.d, connect to wireless network). After I plugged the desktop into the Lan, it used my internet routers DHCP server to obtain an IP and obviously the gateway had now been set to go via the main router.

That said, the foray into the WRT improved my *nix and networking knowledge ever so slightly (what doesn’t kill you only makes you stronger)

Netgear WGT634U – WPA-PSK & DHCP

Symptom: DHCP does not assign IP’s when router is using WPA-PSK encryption. ‘Limited or no-connectivity’ messages appear after a ~2 min timeout once wireless client initiates connection. This problem is intermittent and more predominant when the router is under heavy load – experienced whilst playing a video over LAN whilst downloading torrents.

Related Symptom: Wireless traffic at a standstill – ie, trying to set IP’s manually without using DHCP results in timeouts. Gateway address (usually 192.168.1.1 appears in ARP table but appears as invalid MAC addy 00-00-00-00-00-00.) Trying to set mac addy to IP of router statically still doesn’t work.

Suspecting:

  • WPA-PSK connections to this router are threatened when router is under heavy load.
  • New connections will fail as DHCP will not work – once you’ve disconnected, its difficult for the card to reconnect.
  • This problem affects a variety of routers. Even the Linksys WRT54G isn’t safe. See this search for more info.

About this setup

Firmware Version: 1.4.1.10

Hardware

  • WGT634U of course
  • DSL-302G w/DHCP in bridge mode connected to the Netgear’s Internet port.
  • All wireless cards below are affected
    • Intel 2100 B wireless mini-pci card
    • Netgear WG511U 108Mbps PCMCIA wireless card
    • Belkin 11Mbps PCI card
  • Lan connections from router to desktop, occasionally to the laptop (these are unaffected)

Operating Systems

  • Win XP Sp2
  • SUSE Linux 10

Known Workarounds

  • Use WEP based encryption and change your keys very frequently.
  • Powercycle all equipment (Netgears wizards / documentation indicate client computers should be rebooted when particular settings change – Why do they say this? What am I missing here that a regular enable/disable, clear ARP won’t fix?)
  • Use wired LAN to avoid encryption.
  • Modded firmware (OpenWGT, others?)

Stuff to Try

  • Initially (to replicate the problem and divide and conquer)
    1. Under WEP encryption, make all wireless clients use static addresses. (no dhcp)
    2. Switch to WPA encryption, clients still not using DCHP
    3. Continue using this sort of connection, operating the router under heavy load
    4. Hibernate PC, Awaken
    5. Should the connection drop and reconnect, check that traffic still runs thru that link
      1. If it doesn’t then the problem is not DHCP but WPA-PSK
      2. If traffic flows then DHCP w/WPA-PSK is the problem (have a feeling its not this one)
  • Other settings to try:
  • Long preamble – this is more to do with the initiating the connection
  • Slower speeds (11Mbps or lower?)
  • Reduce complex traffic as much as possible. Remove unnecessary protocols from the Network Connection
  • Switch on/off Adaptive Rate, Xtended Range
  • Issues about the router overheating due to power supply have been briefly mentioned in some forums (whirlpool, netgear’s support site). One user even mentioned that replacing the PSU with another routers one did the trick – will search for this one on request.
  • Use another device as the DHCP server (and maybe even the PPPoE to reduce load) – this would have to be the 302g moved to the Lan port
  • play with RTS/CTS fragmentation threshold (determines what type of wireless Collision Detection is used)
  • DHCP server on 302g could be interfering with server on WGT634U???