Thursday 26 February 2015

Inexpensive WAN Emulation with Linux

Quite frequently, when designing a WAN or evaluating a new networked application, it is interesting to try out the „user experience“ rather than believing the manufacturer‘s marketing flyers.
Commercial, closed source WAN emulators, even as pure software solutions are still in the range of approx. 5000€

As we had problems getting a commercial Software package installed under XP (because of - among others - license key issues) we used NETEM under Linux.
That worked flawlessly using Knoppix on a standard PC with two network cards.
Netem does not provide bandwidth management. This can be added easily - see the LARTC Howto or the example below.

In the following example the WAN Emulator is used as a bridge, i.e. without Layer 3 routing.

Simulating layer 2 ethernet connections has gained relevance since I did my tests in late 2006: Telco providers, eg. Colt, now offer national and international ethernet connections. These can be simulated realistically with the method described here.

Script to enable WAN emulation under Knoppix:

brctl addbr goldengate
brctl addif goldengate eth0
brctl addif goldengate eth1
ip link set up dev goldengate
ip link set up dev eth0
ip link set up dev eth1
ip link show
brctl showmacs goldengate

tc qdisc add dev eth0 root handle 1:0 netem delay 27ms
tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 1000kbit buffer 16000 limit 30000

tc qdisc add dev eth1 root handle 2:0 netem delay 27ms
tc qdisc add dev eth1 parent 2:1 handle 20: tbf rate 1000kbit buffer 16000 limit 30000

tc -s qdisc ls dev eth0
tc -s qdisc ls dev eth1


tc qdisc del dev eth0 root handle 1:0

tc qdisc del dev eth1 root handle 2:0

tc -s qdisc ls dev eth0
tc -s qdisc ls dev eth1

In the 13/08 edition of the German c‘t magazine, an article about WANEM was published. While it‘s focus is apparently on routed links, the GUI it comes with mightbe interesting to try.

How to recover data from a NT4 volume set

How to recover data from a NT4 volume set
recently the boot disk of a NT4 server at work failed. The system reported missing files and wouldn't come up properly.
A colleaugue of mine tried a NT4 repair install from the original NT4 SP1 CD.
That fixed the operating system, but as we had no emergency repair floppy, the config details were lost.
The box had three scsi drives, with the first one DISK0 (having two NTFS partitions) as the boot drive. NT4's hard disk manager only found two disks with unknown partitions.
As I had no idea what we were up against, I booted a Knoppix CD and looked at the file system types, which were:

0x87 on DISK1 and 0x86 on DISK2.

Information on fs-type 87 and 86 on the web were a bit shaky, but it seemed like these two disks might have been part of volume set. Mounting any of the drives in Knoppix didn't work, even when explicitly telling mount to use NTFS.
One of our developers confirmed that the server had „a big e-drive“. That sounded like our volume set.
Someone found an old NT4 Server resource kit in the basement while searching for a NT4 server cd. This came really handy:
With the „ftedit“ program from the resource kit, I could see that the server didn't have any information about the volume set. The manual in the resource kit said that these details are stored in:


I then discovered a SYSTEM._ file in the WINNT/REPAIR directory which I expanded to a file on a floppy disk. Opening that file on an other machine with a freeware „offline registry viewer“ (MiTeC Registry File Viewer), I exported the DISKS key to a .reg file and imported that key back into the nt4 server.
After a reboot the disk manager showed the two drives (DISK1 DISK2) as a volume set.
The same could have been achieved with ftedit manually. Ftedit only manipulates the registry. It doesn't touch the disks as such. So the risk is relatively low.
A drive letter „E“ was attached to the volume, but the file system type still read „unknown“ in the disk admin tool.
I then installed Service Pack 6a, because I thought NT4SP1 couldn't recognize the partition type. Although it didn't fix the problem, it is certainly a good idea to do so.
After some more research (read: goooooooogling), I found the last missing clue here:

The ftdisk service in the device manager had to be set to start with the system.
Even starting it manually from the control panel immediately brought back the missing E-drive.
Obviously the fresh OS-install had not started that service as no fancy disk configs were made from that installation.

Lesson learned: create emergency repair disks for all remaining NT4 servers (rdisk)

Restore original firmware on an ASUS WL-500GP

I had a Asus WL500GP sitting on a shelf for quite some time. That box had been abused under OperWRT as Samba File Server, Asterisk Server, Web Server, mail server, Zork server, etc.
But all was hopelessly out of date. So I decided to first restore it to is's original condition. To achieve that I had to employ a mix of various techniques described on the Interwebs. The Asus Firmware Restoration Tool did not work for me and I was briefly worried that I had bricked this neat little device. Fortunately it is pretty tough.

Here is what I did:

Restore original ASUS firmware on WL500GP:

-Turn off Windows Firewall
-Set PC to static IP (or whatever can't get in the way)
-plug PC directly into lan port 1 (probably not really necessary, but it cuts out all the noise from the rest of my network when using Wireshark)
-Unplug power from router
-Start Wireshark on PC
-Keep black restore Button (not the EZSetup!) pressed while plugging power back in

-Look out for gratitious ARP packets:
2577    1838.485014    AsustekC_e4:XX:XX    Broadcast    ARP    Gratuitous ARP for (Request)

I have no idea where that .49 address comes from but now we have the target address.

Please note that contrary to other information on the web, my router has neither issued DHCP to the PC nor reacted to the ASUS Firmware Restoration tool. That is why I had the PC set to a static IP.

-Now TFTP the firmware image to the router

 Directory of C:\Firmware\Asus\FW_WL500gP_1977

21.10.2008  22:00    <DIR>          .
21.10.2008  22:00    <DIR>          ..
14.05.2008  12:00         7'237'632 WL500gp_1.9.7.7_TW.trx
               1 File(s)      7'237'632 bytes
               2 Dir(s)  237'154'689'024 bytes free

C:\Firmware\Asus\FW_WL500gP_1977>tftp -i put WL500gp_1.9.7.7_TW.trx
Transfer successful: 7237632 bytes in 15 seconds, 482508 bytes/s

-I then had to wait for a while (approx 5 minutes) and the router came back. - With address
That was the one I had stored in NV.

-Don't forget to turn your PC's firewall back on and set the IP assignment to DHCP.

After inspecting what use the original firmware does for the router, I decided to upgrade to OpenWRT Kamikaze.