Cyberwizzard.nl

Welcome to my world

Thomson TG787v and PXE boot

If you have a Thomson TG787v modem, like we have from KPN Business in the Netherlands, you might want to add an PXE server to your network to quickly install computers without the hassle of running around with CDs or thumb drives.

I will not explain how to set up the PXE environment itself (which is in fact a TFTP service) but I will stick to the modification of the modem/router. This modification can NOT be done using the webbased configuration panel.

We will log in using telnet, create option templates for the DHCP server, install those option templates and finally add them to the active pool so they will actually be in use.

If you think thats rather a lot of work to install option 66 (TFTP server address) and option 67 (Bootfile name) into your modem, please complain to Thomson and insist they make it a) more intuitive; b) improve their documentation; c) implement these things in their webbased configuration; d) all of the above.

  • Log in on the CLI using telnet at your router, port 23 and enter your credentials
    Note: with the unlocked versions, your login will be the username from the webbased configuration and no password. Try "Administrator".
  • Install the new template for the PXE server address:
    dhcp server option tmpladd name=tftp_server_name optionid=66
  • Install the new template for the PXE bootfile name:
    dhcp server option tmpladd name=bootfile optionid=67
  • Instantiate the templates:
    dhcp server option instadd name=tftp_server_name tmplname=tftp_server_name value=(addr)192.168.1.2
    dhcp server option instadd name=bootfile tmplname=bootfile value=(ascii)pxelinux.0

    Note: The file name can be configured to whatever you need.
  • List all DHCP server pools: "dhcp server pool list"
  • Optionally, add the option to the desired pool:
    dhcp server pool optadd name=LAN_private instname=tftp_server_name
    dhcp server pool optadd name=LAN_private instname=bootfile

It seems that the template instantiation is added by default to the "LAN_private" pool.

Clearing GPT from harddisk without destroying MBR

For some reason, my attempts to use GPT with Windows 7 ran aground and I ended up with a working Master Boot Record (MBR) and an empty GPT. While Windows 7 was quite happy with this, the Ubuntu installer detected the GPT and attempts to use it - which effectively prevents me from installing it unless I wipe the entire hard drive for Ubuntu.
In this little article I will clear the GPT from the disk so only the MBR remains. This is an advanced technique which WILL destroy your partition layout and thus your data when it fails. Make very very sure you understand each step and have backups.
Start by making a backup of your MBR, which is 512 bytes long at the start of the disk: sudo dd if=/dev/sda of=disk_mbr.raw bs=512 count=1 I made a backup of the MBR and the GPT as well, just in case (GPT is 512 bytes for the header followed by 16kB of content, total with MBR is 17kB): sudo dd if=/dev/sda of=disk_mbr_gpt.raw bs=1024 count=17 The GPT is present at the start and end of the disk. Lets start by erasing the GPT from the start: sudo dd if=/dev/zero of=/dev/sda bs=512 seek=1 count=33 Now find the end of your disk, use 'fdisk /dev/sda' and note the number of bytes on the disk. In my case it is: 240,057,409,536 bytes, since I want to use kilobytes with dd, lets convert it to kB: 234,431,064 kB. We need to erase the last 16.5 kB, but 16kB will suffice (as the header is in the last 512 bytes).
So substract 16 from the drive size to generate the GPT offset for the end of the disk and zero-fill it to the end: sudo dd if=/dev/zero of=/dev/sda seek=234431048 bs=1024 count=17 All done! Now fdisk will no longer complain the drive has a GPT table and the Ubuntu installer will only find the MBR and happily install using that.

Force HTC Hero 1.5 to update

Since it took me hours to find this answer, I decided to put it up clear and simple: this is how you 'force' your stock HTC Hero to check for updates.

First off, this is for the original HTC Hero. So not the Sprint or CDMA version, but the GSM version (with the chin). Most sites tell you to use the "Check for updates" option. The original HTC Hero firmware does not have this option.

Instead, you need to install the first (of three) updates to get the updater. The original update mechanism checks every two weeks for an update. If you need it to check right away, you can move the clock 2 weeks forward or use enter this number: *#*#682#*#*. If it worked, the number will disappear from the dialer and almost instantly a popup will tell you that an update is available.

After this update, force the phone to check for future updates by doing:

  1. From the Home screen, press MENU, and then tap Settings.
  2. Scroll down the screen, and then tap About phone > System software updates.
  3. On the System software updates screen, tap Check now.

Gentoo KVM virtual machine support plus networking

The Gentoo Wiki article about KVM uses the less flexible networking setup with dedicated TAP devices like 'tap0'. While this setup works fine, other distributions use the bridge device in a different way. By creating a virtual bridge and forcing the host system to connect through this bridge, virtual machines can simply connect to the bridge device and 'plug in'. No need to manually create TAP devices. In this guide we will set up host and guest networking using the virtual bridge device and DHCP for wired ethernet.

For this to work, you will need most of the tools from the wiki article as well as a couple more (I like the management GUI from virt-manager to manage VMs without a text console). Install the following tools:

  1. app-emulation/qemu-kvm - QEMU + Kernel-based Virtual Machine userland tools
  2. net-misc/bridge-utils - Virtual network bridging
  3. app-emulation/virt-manager - libvirt management GUI
  4. app-emulation/libvirt - Toolkit to manipulate virtual machines, supporting virtualisation frameworks like KVM and Xen

Install all the tools and modify the kernel to support the bridge devices. Note that tunnel support is omitted (unlike in the original wiki article).

[ * ] Virtualization ---> --- Virtualization <m> Kernel-based Virtual Machine (KVM) support < > KVM for Intel processors support < > KVM for AMD processors support Networking support ---> Networking options ---> <*> 802.1d Ethernet Bridging <*> 802.1Q VLAN Support

Build the kernel, the modules and install both. Do not forget to reboot.

Next up, lets configure the network on the host machine. Disable NetworkManager as it will not understand the bridge device and break networking altogether in an attempt to activate things they usually are.

We will connect the network as shown below. The interface 'eth0' is now a passthrough for the virtual network bridge - note that the eth0 device has no IP address. The new 'br0' device is a new bridge. This is the new networking interface for the host PC - it gets an IP address and is the designated end point for communication. Other virtual NICs connect to this bridge.

HOST +---------------+ LAN ---+--- eth0 | | ^ | KVM GUEST1 | | | +--------------+ | +-----+ | | | | |vnet0+----+---+---- nic0 | | |vnet1+----+-+ |192.168.100.2 | KVM GUEST2 | +-----+ | | +--------------+ +--------------+ | br0 | | | | |192.168.100.1 | +--------------------+---- nic0 | +---------------+ |192.168.100.3 | +--------------+

In order to automatically configure the network, edit '/etc/conf.d/net' and insert the following:

# Disable all configuration on eth0 config_eth0=("null") # Use eth0 to connect the virtual bridge bridge_br0="eth0" # Statically configure br0 config_br0=("192.168.100.1 netmask 255.255.255.0") routes_br0=("default via 192.168.100.254") dns_servers_br0="192.168.100.254" # Uncomment the next line and comment the lines above to use DHCP #config_br0=("dhcp")

Now we need to symlink '/etc/init.d/net.lo' to '/etc/init.d/net.br0'. We can now stop 'net.eth0' if you still had it running and start 'br0' instead. Note that the Gentoo networking scripts create the bridge interface 'br0' and bring everything up (including eth0, but without assigning an IP).

The Gentoo scripts do this under water (in case you want to manually configure things):

# Create the br0 device and connect eth0 to it brctl addbr br0 brctl addif br0 eth0

If you want to make this networking setup permanent, remember to remove 'eth0' from the default runlevel and add 'br0' instead.

Now start the service 'libvirt' and run 'virt-manager' to start managing Virtual Machines. If everything worked as planned, creating new VMs will automatically (read: libvirt creates these) result in new virtual NICs for the virtual network. Good luck!

Upgrading LIRC to ir-core and imon

While the title may sound a tad cryptic, that matched my first impression about the new infrared remote subsystem used in Ubuntu 10.10 and kernel 2.6.36+ based distributions. In Linux 2.6.36, a new sub-system is introduced for remote controls. This subsystem is a partial replacement for lirc as it features complete IR drivers for numerous devices.

In reality, the glass is only half full as some IR receivers (and transmitters) deal with raw data. Writing universal drivers for such devices can be bothersome or even impossible, for example when dealing with universal receivers. As such, LIRC is not completely written off as it can be used to do userspace IR processing as it used to. The exact details are unknown to me as I have an SoundGraph iMon receiver (device ID 0038 - LCD), which does not deliver raw sensory input but rather complete scancodes.

When I upgraded from Ubuntu 10.04 running lirc 0.8.6 to Ubuntu 10.10 and lirc 0.8.7, the entire IR subsystem died on me. To my surprise, while the remote was dead, the LCD screen was working fine. Further inspection showed that the 'lirc_imon' driver was not loaded at all.

With the move to the new input layer driver for supported IR devices in the kernel, the new 'imon' driver (version 0.8 at the time of writing) no longer provides a 'lirc0' device. As such, lircd will fail when attempting to claim it and loading 'lirc_imon' (provided you still have it) will not work as the device is already claimed by the 'imon' driver.

The fastest way to get up and running again is as follows. The 'imon' receiver will now be a HID input device. I got the impression it would send keystrokes to a graphical application but I didn't get that working. Instead, we will use 'lircd' again using a special driver called 'devinput'. This driver reads the key strokes from the input layer device and converts them into LIRC events. All your LIRC capable programs will then use lirc like they used to - we only need to use the new button names.

To find the iMon receiver in the list of input devices, lets create a udev rule to symlink to the device. This way we will not have to rely on obscure device names like 'input1'. Make sure the device name matches whatever hardware you have. I inserted this rule in a file called '/etc/udev/rules.d/99-imon.rules':

KERNEL=="event*", SYSFS{name}=="iMON Remote (15c2:0038)", NAME="input/%k", SYMLINK="input/imon_remote", MODE="0666"

Lets begin by stopping lirc if you still have it running. Next, reconfigure LIRC to use the devinput driver - when it asks which device you have DOT NOT SELECT THE SOUNDGRAPH IMON but 'Linux input layer (/dev/input/eventX)'. In the next screen select 'None' as you probably do not use a transmitter.

/etc/init.d/lirc stop
sudo dpkg-reconfigure lirc
> Linux input layer (/dev/input/eventX)
> None
/etc/init.d/lirc start

In case you are not using Ubuntu linux, I will explain the key parts of the LIRC configuration. The '/etc/lirc/lircd.conf' file now has this part in it:

#Configuration for the Linux input layer (/dev/input/eventX) remote:
include "/usr/share/lirc/remotes/devinput/lircd.conf.devinput"

The 'lirc.conf.devinput' file is a standard (generated) file with key codes as provided with LIRC. There is no need to manually set up a file with button scan codes as the new ir-core kernel subsystem will generate standard codes.

The file called '/etc/lirc/hardware.conf' has something like this in it:

REMOTE="Linux input layer (/dev/input/eventX)"
REMOTE_MODULES=""
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="/dev/input/imon_remote"
REMOTE_LIRCD_CONF="devinput/lircd.conf.devinput"
REMOTE_LIRCD_ARGS=""

All that remains is to use the new buttons in your LIRC capable program. For example, this is a part of my configuration of XBMC (Lircmap.xml) for use with the SoundGraph iMon receiver:

<lircmap>
        <remote device="devinput">
                <hash>KEY_EJECTCD</hash>
                <play>KEY_PLAY</play>
                <pause>KEY_PAUSE</pause>
                <stop>KEY_STOP</stop>
                <forward>KEY_FASTFORWARD</forward>
                <reverse>KEY_REWIND</reverse>
                <skipplus>KEY_NEXT</skipplus>
                <skipminus>KEY_PREVIOUS</skipminus>
                <record>KEY_RECORD</record>...