These directions are written for the Backfire 10.03.1 release.
Previous releases of OpenWRT supported the WRT54GL’s wireless interface only via Broadcom’s proprietary driver for Linux 2.4, so it was necessary to use the brcm-2.4 build of OpenWRT. As of the Backfire release, the WRT54GL’s wireless is supported by the mac80211 driver, so it’s possible to use the brcm47xx build of OpenWRT, based on Linux 2.6, instead.
Upload the .trx file to /tmp on the router and run: mtd -r write openwrt-brcm47xx-squashfs.trx linux
After the firmware update and reboot, the router is operating in its default out-of-the-box configuration: there’s a DHCP server running on the LAN ports, handing out IP addresses in the 192.168.1.0/24 range, and the wireless is disabled for safety. The WAN port will try to get an IP address via DHCP.
For the next stage of the configuration, you’ll need a computer connected to the router’s LAN port. Connect something to one of the four LAN ports and let it get an IP address. Make sure the address you get begins with 192.168.1; if it doesn’t, either your router hasn’t been reflashed, or you’re connected to something other than the router.
The router’s IP address is 192.168.1.1. It has a Telnet server running, which you’ll use to log in and get a shell on the router. No password is needed to log into the telnet server; the router is unsecured at this point, because you haven’t chosen a password yet.
Since Telnet isn’t very useful these days (it’s been obsoleted by SSH), I don’t install Telnet software on my PCs, and I don’t want to have to install a Telnet client temporarily just for the purpose of configuring this router. Therefore, I use the Netcat tool for connecting to the router’s Telnet server: nc 192.168.1.1 23 will give you a shell on the router. (Since Netcat doesn’t use the Telnet protocol, this method of connecting lacks many of the niceties you’d have with Telnet, such as the ability to use the up/down arrow keys to scroll through your command history, but that’s OK since we only need to run a few simple commands on the router anyway.)
The “Kamikaze” series of OpenWRT releases have all their configuration settings stored in a collection of files in /etc/config. You can edit these files directly if you like, but the preferred way to manage the router’s configuration is with the uci tool, which provides a simple front-end interface to the files in /etc/config.
Run uci show to get a list of all the configuration properties that are currently defined. You’ll see that they’re hierarchial, with names like network.lan.type and wireless.wl0.disabled. You can use a command like uci show network.lan to look at just a particular subset of the configuration, rather than the whole thing.
To change the value of a configuration propery, or define a new property, use uci set. To delete an existing property, use uci del. There are some other uci subcommands as well; run uci with no arguments for more information.
The changes you make with uci are kept only in memory initially. The command uci commit updates the files in /etc/config from the in-memory configuration, so that they won’t be forgotten when the router reboots.
OpenWRT’s default configuration defines two logical network interfaces: the “LAN” interface and the “WAN” interface, which are configured by the uci sections network.lan and network.wan respectively. The LAN interface is meant for connecting to “your” network, and the WAN interface is meant for connecting to an external network, such as an Internet connection provided by your ISP.
By default, the WAN interface uses DHCP to get an IP address from the external network, and routes traffic from the LAN using IP Masquerading (commonly referred to as “NAT”, but masquerading is actually just one particular type of NAT). This is appropriate for using the WRT54GL as a router, but since we want to use it simply as a wireless access point for a LAN, we don’t want it doing any routing. Therefore, we need to disable the WAN interface.
The network.wan.proto configuration property controls how the WAN interface is assigned an IP address. The default value of dhcp means to get an IP address from the external network via DHCP. Changing this property to none will disable the WAN interface: it will not be configured with an IP address, and no routing will be done.
Run uci set network.wan.proto=none to disable the WAN interface.
By default, OpenWRT expects to be acting as the DHCP server for the LAN: the LAN interface is configured with a static IP address of 192.168.1.1, and it hands out addresses in the 192.168.1.x range to other computers on the LAN. Since we want to use this access point on a network that already has a DHCP server, we need to configure OpenWRT to act as a DHCP client rather than as a DHCP server: that is, to get its IP address by requesting it from the DHCP server rather than using a fixed address of 192.168.1.1, and to refrain from handing out DHCP leases of its own.
The network.lan.proto configuration property controls how the LAN interface is assigned an IP address. The default value of static means to use a predefined address. The static address is controlled by the network.lan.ipaddr and network.lan.netmask configuration properties, which are set to 192.168.1.1 and 255.255.255.0 respectively. Changing the network.lan.proto property to dhcp will cause the LAN interface to obtain an IP address via DHCP rather than using the statically-configured one.
The dhcp.lan group of configuration properties controls the DHCP server for the LAN interface. The dhcp.lan.start, dhcp.lan.limit, and dhcp.lan.leasetime properties control the range of addresses handed out by the DHCP server. We need to disable this DHCP server, which is done by setting a new property, dhcp.lan.ignore, to 1.
(Note that the dhcp.lan.interface property is set to lan, which is the reason why the dhcp.lan group controls the DHCP server on the LAN interface, network.lan. There’s also a dhcp.wan group which controls the DHCP server on the WAN interface — that is, dhcp.wan.interface is set to wan — and it’s disabled by default.)
Run uci set network.lan.proto=dhcp to enable the DHCP client on the LAN interface, and then run uci del network.lan.ipaddr and uci del network.lan.netmask to remove the static IP configuration. (Alternatively, you can set these to appropriate values for your network, and they'll be used as a fallback if the DHCP client fails, e.g. if the LAN’s DHCP server is not responding.)
Run uci set dhcp.lan.ignore=1 to disable the DHCP server on the LAN interface, and then run uci del dhcp.lan.start, uci del dhcp.lan.limit, and uci del dhcp.lan.leasetime to remove the DHCP server's address configuration.
(Note, The dhcp.@dnsmasq[0] group of configuration properties holds the settings for the dnsmasq daemon that provides both DHCP and DNS service on the LAN interface. Since we’ve turned on dhcp.lan.ignore, dnsmasq won't provide DHCP service, but it still provides DNS service. Other devices on your network will probably never use this, since they get their DNS configuration from the router's DHCP server in the same way that OpenWRT now does, but it's needed for OpenWRT itself to be able to resolve hostnames, so don’t remove the dhcp.@dnsmasq[0] settings.)
Like any Linux-based computer, your OpenWRT router has a hostname, controlled by the system.@system[0].hostname configuration property. The default is “OpenWRT”, but you can change it to anything you like. If your network provides DNS service based on hostnames given in DHCP requests, this setting will control your access point’s name in DNS.
Run uci set system.@system[0].hostname=MyNewHostname to change the router’s hostname. This is optional.
Normally, the router’s LAN interface corresponds to the four Ethernet ports labeled 1–4 on the back of the WRT54GL (the “LAN ports”) together with the wireless, and the WAN interface corresponds to the Ethernet port labeled “Internet” on the back of the WRT54GL (the “WAN port”). Since the WAN interface is disabled, the WAN port on the back of the router is useless. It’s possible to configure it to act as another LAN port instead, so that it doesn’t go to waste. This is optional.
The WRT54GL contains a six-port switch. Five of the ports on the switch are wired to the Ethernet jacks on the back of the unit — the four LAN ones and the single WAN one — and the sixth is wired to the computer inside the unit. This single switch is able to act as two separate logical switches through the use of 802.1q VLANs: the switch is configured so that the four LAN ports are part of VLAN 0 and the WAN port is part of VLAN 1, so traffic cannot cross between the two. The internal computer has access to both VLAN 0 and VLAN 1, so it can talk to both the LAN and the WAN even though it has only a single connection to the switch.
The network.eth0_0 group of configuration properties controls the eth0.0 interface attached to VLAN 0, and the network.eth0_1 group controls the eth0.1 interface attached to VLAN 1. The default value of network.eth0_0.ports is 0 1 2 3 5, which means that switch ports 0–3 (the LAN ports on the back) and 5 (the internal computer) are asscociated with eth0.0. The default value of network.eth0_1.ports is 4 5, which means that switch ports 4 (the WAN port on the back) and 5 (the internal computer) are asscociated with eth0.1. By changing these values to 0 1 2 3 4 5 and 5 respectively, we can associate switch port 4 with eth0:0 instead of eth0:1, effectively turning the WRT54GL’s “WAN port” into another LAN port.
(Note that eth0 represents the internal computer's physical connection to the switch, and the Linux VLAN support creates eth0.0 and eth0.1 representing the two virtual network connections being carried over the single physical connection. These are bound to the LAN and WAN configurations by the network.lan.ifname and network.wan.ifname configuration properties, which are set to eth0.0 and eth0.1 respectively.)
Run uci set network.eth0_0.ports="0 1 2 3 4 5" and uci set network.eth0_1.ports=5 to reconfigure the switch.
The wireless.wl0 and wireless.@wifi-iface[0] configuration groups contain the configuration properties for the WRT54GL’s built-in wireless networking. The defaults will work, though they’re insecure, but at the very least you need to enable the wireless, since it’s disabled by default (precisely because the default configuration is insecure).
The details of wireless configuration are no different when using OpenWRT as an access point rather than as a router, so documenting it here would be redundant. See the OpenWRT documentation for information on wireless configuration. Just make sure that at some point you run uci set wireless.wl0.disabled=0 to actually enable the wireless.
I strongly recommend using WPA encryption rather than WEP, which is known to be insecure. Ideally, you should use WPA2 if all your wireless devices support it.
If you backed up your hostkeys in /etc/dropbear earlier, now is the time to restore them. If you have the telnet client installed locally, you can probably do this by running telnet 192.168.1.1 "tar xv" < wrt-etc-dropbear.tar, but I haven’t tested this. To do it using only netcat: first run nc -l -p 11235 -q0 < wrt-etc-dropbear.tar locally, then nc 192.168.1.1 23 to log into the router, and run nc 192.168.1.230 11235 | tar xv there. This will overwrite the host keys in /etc/dropbear (which were generated automatically during the initial bootup) with the ones you saved from your previous installation.
Next, nc 192.168.1.1 23 to get a shell on the router if you haven't done so already, and run passwd to change the password. Beware that if you’re using netcat for this, the password you type will not be hidden, so don’t do this if anyone is watching over your shoulder.