I know, some programs already do this, but they require Xwindow and some ugly Gnome/KDE app. What we’re doing here is a minimal setup, using the least memory.

Normally, on a normal Unix system you would use the included device detection mechanism, which is hotplug. But on Ubuntu (at least Gutsy and Hardy), the de-facto/required way is by using udev, which is an event based system, using rules to fire new events/mount/symlink or run programs according to some patterns defined as “rules”.

So, the first thing to do is to identify your device according to USB events. udevinfo is your friend. So, after looking at the output of dmesg, you’ll see your USB device is available on some sd* device.

So run:
udevinfo -a -p /sys/block/sda
(replace sda with you device)

You will get a list of “blocks” representing each layer of drivers. For example:

root@sleek:/etc/udev/rules.d# udevinfo -a -p /sys/block/sda/

looking at parent device '/devices/pci0000:00/00[...]:
KERNELS=="2:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{ioerr_cnt}=="0x0"
ATTRS{iodone_cnt}=="0xcc26b"
ATTRS{iorequest_cnt}=="0xcc26c"
ATTRS{iocounterbits}=="32"
ATTRS{timeout}=="30"
ATTRS{state}=="running"
ATTRS{rev}=="3.AA"
ATTRS{model}=="ST3250310AS "
ATTRS{vendor}=="ATA "

These are in fact attributes that you can use in your rule to filter the devices. So for example,
to run a shell script when a SCSI device is detected which has a size of 1GB, I’ll use the following line:

KERNEL=="sd?1", ATTRS{size}=="1999872", RUN+="/usr/local/bin/recup_usb.sh"

This line is to be put in a new file in /etc/udev/rules.d, named something like 91-backuptousbdrivetrigger.rules. It’s better to put the file at the end of the rules (the “91″), as not to disturb other module loadings.

The content of the recup_usb.sh file can be:

#!/bin/bash

if [ "${ACTION}" = "add" ]; then
rm -rf /tmp/x
mkdir /tmp/x
mount -t vfat /dev/sdc1 /tmp/x
find /tmp/x -name "*jpg" -exec /usr/bin/rsync -avz {} \
/home/foobar/Pictures/Incoming/`date +%Y-%m-%d`/ \;
umount /tmp/x
fi

(yes, I know this code is dirty, I should have used mktemp, but you get the point…)
Don’t forget to chmod +x the shell script and reload the configuration with:

udevcontrol reload_rules

For more detailed information about writing udev rules, take a look at the official documentation, or another’s detailed information about doing the same thing.

We’ll set the wifi interface as a client for a remote access point. We’ll keep the WAN interface with a static ip (here, 192.168.1.1)

Please note, that changing the configuration will make the remote network access as previously used unusable. The only secure access is still through the serial console.

First, edit the file /etc/config/network:

config switch eth0
option vlan0 "0 1 2 3 5*"
option vlan1 "4 5"
[...] # localhost config here
[...]
config interface wan
option ifname "eth0.1"
option proto static
option ipaddr 192.168.1.1
option netmask 255.255.255.0
[...]
config interface lan
option type bridge
option ifname "eth0.0"
option proto dhcp


And then the file /etc/config/wireless:

config wifi-device wifi0
option type atheros
option channel 8
option disabled 0
[...]
config wifi-iface
option device wifi0
option network lan
option mode sta
option ssid YOUR_SSID
option encryption none
option hidden 0


If your access point has some encryption, like WEP, do this instead of the wifi-iface block:
config wifi-iface
option device wifi0
option network lan
option mode sta
option ssid YOUR_SSID
option encryption wep
option key 1234567899
option hidden 0


You can take a look at the different available options on this documentation. If all is well, you should have an ip address on your br-lan interface (your WHGT634U hub port is bridged with the wifi interface).

Next part will be the most interesting :-) I think I’ll try all the different methods to implement an automatic player daemon. Direct methods, and indirect methods, using a share fielsystem like CIFS.

Reference

Jkx@Home’s article explaining another use of WGT634U

Please read the following to get all the details.

I take no responsibility if you damage your router.

This installation procedure has been done with OpenWRT v. 7.06 (stable).

These requirements are not really requirements, but are the tools/material I used to make it work. So with these, you’re sure to make it work, like me :-)

Hardware Requirements

• A PC with a serial port
• A breadboard
• A serial cable that you can unwire
• A network cable
• A USB sound adapter

Software requirements

• A connection to Internet
• A Linux OS (I use Gentoo, but any will be OK)
• A TFTPd server
• A DHCP server
• Screen software

Serial updates

First thing to do is build a serial connexion to the WGT634U to be able to flash it. Read the infos about the serial console on this page. I choose to get a normal serial cable, remove one side of the cable and plug it on my breadboard, which is itself linked to the 3 pins on the NetGear.

Install TFTPd, and set it to get its files from /tftproot (for example). Put the OpenWRT binary file for WGT634U in it (get it from openWRT’s download section).

Run the following command to catch everything from your Linux ttyS0 port:

screen /dev/ttyS0 115200

Put a network cable on the WAN port of your Netgear, and connect it on your network (which should be linked to Internet):

Here, the yellow network cable is plugged in the WAN port (right).

Unplug and replug the power supply cable, and at the same time press Ctrl-C several times.

You should get a CFE> prompt.
Type:

ifconfig eth0 -auto
flash -noheader 192.168.0.44:openwrt-wgt634u-2.6-squashfs.bin flash0.os

This will ask the DHCP server on the network for an ip address to set on the NetGear WAN interface
(you can verify that the link is OK by pinging your TFTPd server: ping 192.168.0.44) and then upload the OpenWRT image to the NetGear.
When done, type reboot.

Wait a few minute, for the flash to be reinitialized, then hit enter to get a console.
Set a password for root (which will activate the SSH daemon): passwd root.
Edit the file /etc/firewall.user and uncomment the two lines that allow SSH (port 22) connections to the WAN interface:

### Open port to WAN
# — This allows port 22 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_wan -p tcp –dport 22 -j ACCEPT
iptables -A input_wan -p tcp –dport 22 -j ACCEPT

Then reboot.
You should now be able to log in remotely without using the serial cable!

Logon and type:

ipkg update
ipkg install kmod-soundcore
ipkg install kmod-usb-core
ipkg install kmod-usb-ohci
ipkg install kmod-usb-audio

Verify that everything is OK by looking into the /dev directory. There should be a /dev/control* and a /dev/pcm* file:

root@OpenWrt:~# ls /dev/pcm* /dev/cont*
/dev/controlC0 /dev/pcmC0D0c /dev/pcmC0D0p

If yes, cool! Otherwise, take a look at the kernel logs (dmesg) for any problem.
Now, your USB soundcard should be activated. But that’s not sufficient to make it work. You’ll have to add some symlinks to make alsa work correctly.
First install alsa utilities:

ipkg install alsa-utils
ipkg install alsa-lib

Then create the symlinks:

mkdir /dev/snd
ln -s /dev/controlC0 /dev/snd/controlC0
ln -s /dev/pcmC0D0c /dev/snd/pcmC0D0c

Now run alsamixer. You should get an ASCII vertical bar that allows you to set the volume:

That’s all for now. You now have a working WGT63U router which can play sound.

Next part will be about configuring Wifi as a client, and installing mpd (http://www.musicpd.org/ Music Player Daemon) and linking it to a server to allow direct play from a remote server!

References

• Search for WGT634U on http://forum.openwrt.org
• Nathan True‘s howto for doing the same thing

Don’t forget to visit the second part!