Technical explorer

Today we bought a new network switch for work. It’s a managed switch and provides a few different ways you can configure it, including telnet, SSH and a web interface. It’s a Cisco/Linksys SRW2024, which is part of Cisco’s small business networking equipment offering.

I’m configuring it to have two VLANs; one for regular IP traffic and the other for our iSCSI network. I managed to lock myself out of the web interface by assigning all the ports to one of the two VLANs I’d created, and not leaving any ports attached to the default VLAN. This default VLAN had the management IP is attached to it.

Thankfully my new Acer Aspire X1800 desktop (which by the way, for $398 is a totally awesome Ubuntu desktop) has a COM port, so I connected up the serial cable and used screen to bring up a console connection:

screen /dev/ttyS0 38400

With this I could log in, then access the lcli command to give me a more meaningful console.

srw2024# configure
srw2024(config)# interface ethernet g24
srw2024(config-if)# switchport access vlan 1
srw2024(config-if)# exit
srw2024(config)# exit
srw2024# show vlan

Vlan       Name                   Ports                Type     Authorization 
---- ----------------- --------------------------- ------------ ------------- 
 1           1                 g24,ch(1-8)            other       Required    
 2         DATA               g(1-7,13-20)          permanent     Required    
 3         ISCSI              g(9-12,21-23)         permanent     Required    


With that I had successfully removed the port from the ISCSI VLAN and replaced it into the default VLAN, making the web management console available.

I’ve never played around with Cisco gear before, but I suspect that this is similar to how IOS works.

I was happy that, even without any IOS experience, I was able to dig about inside the switch and get it back to being usable again. Now to try and attach g24 to multiple VLANs.

What did I do today?

As any programmer will tell you, when you hit “the zone” it can be hard to track exactly what it is that you’re achieving. It’s not uncommon to sit down for a six hour session and at the end of it have a poor memory of what you were doing at the beginning.

This is a real problem if you make a living off charging for your time, as the natural result (for honest people) is to under charge by under accounting for your time.

Using source control can be a good initial reminder, so long as your commits are meaningful and descriptive. I use the following command to give me a basic idea about what I’ve done today (since midnight):

It results in output similar to this:

e6de125 Added progress controller and basic views
bce08e1 Added stylesheets including 960 grid layout
b034acc Implemented initial 960 grid layout
2576762 Added AASM gem dependency

How to fix wireless packet loss on a June 2009 MacBook Pro

We use a DrayTek Vigor 2008 wireless ADSL 2 router at both The Frontier Group office and Berwick Manor. I was surprised and disappointed to see that at home my wireless network was performing especially poorly, with up to 40% packet loss and significant drop outs.

I investigated a few avenues, but because the MacBook Pro is so damn new there’s nothing I could find online to help me out. Coupled with the fact that things work fine at the office and you had one confused little gangster.

The first stop was to check out my old MacBook Pro, which is now Magdalena’s new MacBook Pro. Her wireless worked just fine and dandy, but at least that meant I could point the finger to my unibody badboy with confidence.

I upgraded the DrayTek’s firmware because the version I was using was from mid-2006. There have been numerous patches since then which claim to help with wireless connectivity. Magdalena’s laptop is almost 3 years old, so it was about the same age as the firmware – it made sense that it might play nicer, whilst mine was expecting something else.

The new firmware flashed fine but it did nothing to help my Mac. I fiddled around with the various wireless security options but even having no security didn’t change anything, and I was still dropping more packets than I could afford.

I did have success by locking the DrayTek to 802.11B only, instead of the B/G combo. I know, I know… the standard allows for a much slower throughput, but that’s not super important to me. I want nice, fast pings on my wireless network at home. When I transfer large files I jack into the wired network anyway, so it’s not going to be a limitation I can’t live with.

I went from this:

64 bytes from icmp_seq=17 ttl=255 time=42.394 ms
64 bytes from icmp_seq=18 ttl=255 time=44.301 ms
64 bytes from icmp_seq=19 ttl=255 time=9.830 ms
--- ping statistics ---
20 packets transmitted, 14 packets received, 30% packet loss

… to this:

64 bytes from icmp_seq=454 ttl=255 time=4.426 ms
64 bytes from icmp_seq=455 ttl=255 time=4.422 ms
64 bytes from icmp_seq=456 ttl=255 time=3.667 ms
--- ping statistics ---
457 packets transmitted, 457 packets received, 0% packet loss

Clean up time

It was time to clean up.

mlambie@stormshadow:~/Desktop$ mkdir Clutter
mlambie@stormshadow:~/Desktop$ mv * Clutter/
mv: rename Clutter to Clutter/Clutter: Invalid argument
mlambie@stormshadow:~/Desktop$ ls -l
total 0
drwxr-xr-x  44 mlambie  staff  1496 21 Apr 14:51 Clutter
mlambie@stormshadow:~/Desktop$ ruby -e '5.times { puts "yay!" }'