Contents

The GUI relies heavily on JavaScript to generate the content and XMLHTTP (AJAX) to update it. Be careful if you need to use this from an older/minimal browser since it was not designed to downgrade gracefully. This has been tested only on Firefox v1/2/3, Opera v9 and IE v6/7.

Do all upgrades through a wired LAN cable (i.e. NOT wirelessly). (Although it's possible to upgrade the firmware wirelessly, the transmission may be corrupted by a running microwave oven or ringing cell phone, which will render your router useless, so just don't do it.)

The GUI username is "admin" or "root" (username is required), ssh and telnet username is always "root", and the default password is "admin".

By default, the SES/AOSS button is programmed to start a password-less telnet daemon at port 233 if held for 20+ seconds. If you run into a problem of not being able to login, you can use this to view ("nvram get http_passwd") or reset ("nvram set http_passwd=newpassword") the password. You can disable this behavior in Admin/Buttons. Remember to reboot the router after retrieving your password to close the backdoor.

If you're upgrading from DD-WRT v23 SP2+, be aware that you may get locked-out because of a change in DD-WRT's use of the nvram password key. You have a few options:

Push the reset button to reset all the configuration after installing Tomato.

Use the SES/AOSS button as described above.

Log in with telnet* and type "nvram get http_passwd" while running DD-WRT and write down the result - this will be your password after loading Tomato. (*the telnet login name is always 'root' even if you have changed the user name in the DD-WRT web interface).

If you still have problems with Tomato after upgrading from DD-WRT (WPA2 not working, wireless broadcast failing, settings not being remembered, other) do a complete wipe of the NVRAM by going to Administration->Configuration->Restore Default Configuration->Erase all data in NVRAM memory (thorough). Then as an extra step reinstall (upgrade) to the Tomato firmware. This should solve all issues when upgrading from DD-WRT

G\code.bin is for WRT54G v1-4 and WRT54GL v1, GS\code.bin is for WRT54GS v1-3, GSv4\code.bin is for WRT54GS v4, and TRX\code.trx is for the WHR-G54S/ WHR-HP-G54S. If you're just upgrading an existing Tomato firmware from the GUI, any of these will work.

Unarchive the 7z package you downloaded. It's compressed using 7-Zip - tools to open this can be found at www.7-zip.org.

Open the Linksys GUI in your browser. The default URL is http://192.168.1.1/. The default credentials are username: {blank}, password: admin

Click the Administration tab, then Firmware Upgrade.

Select and upload the correct firmware for your router.

Wait for about 2 minutes while the firmware is uploaded & flashed.

Log in to the router, and reset factory defaults (under Administration/Configuration/Restore Default Configuration, select the Erase all data in NVRAM Memory (thorough) option and click OK. Router will restart again, and the factory default login is "root" with a password of "admin". If you have a password set with the old Linksys firmware, try using that password before a manual reset if you encounter any problems logging into Tomato GUI.

As noted above, the USB port is not supported by the standard Tomato firmware. There are alternative variations that add this support; see the forum posting "Tomato 1.xx ND USB + FTP/Samba Mod" for the list of features.

Downloaded and unpack the desired Tomato variation from mediafire.com.

The following is for an initial install on a Buffalo router. If you're already using a third-party firmware or just upgrading a Tomato firmware, try uploading any of the .bin files from the GUI.

Plug your computer directly to the router's LAN port. This will not work over a wireless connection.

Set your computer's ethernet card settings to: IP=192.168.11.2, mask=255.255.255.0, gateway=192.168.11.1 (Gateway and DNS settings are optional and not needed to flash Tomato). In Windows, you can set this by going to Control Panel, Network Connections, right-click your ethernet card, click properties, then TCP/IP.

Plug in your router and quickly enter this in a DOS window. "tftp -i 192.168.11.1 put tomato.trx" It will return Timeout if it failed or Transferred if it was successful.

Make sure you are unplugging/replugging the router's power cable (not ethernet cable). There's about a quick 3-5 second window when router is booting up where you can send a install a new firmware. If you miss that and the old firmware boots, you'll get a continuous "ping ... tftp ... ping ... tftp". Unplug, wait a few seconds and try again. Might be tricky to get the timing right...

After waiting for at least 2 minutes after the initial flash, with the power still on, push the reset button for one full minute to reset the configuration. Release the reset button and allow the unit to boot up before trying to access it.

Your router is now at the address of 192.168.1.1 which you can access by manually changing the computer back to 192.168.1.2, subnet 255.255.255.0, Gateway 192.168.1.1 and DNS 192.168.1.1, or simply set your computer back to DHCP (Obtain Automatically in the TCP/IP properties).

The tftp -i 192.168.11.1 put code.trx process involves the manual hit and miss timing of running a ping loop and hitting enter at just the right time during the power up sequence. The provided batch file eliminates this hectic method of flashing and has rendered it obsolete. Use the Tomato batch file that is included with the Tomato firmware to flash all compatible Buffalo routers. If you get timeout errors copy the tftp.exe file from Windows/System32/ into the same directory as the .bat and .trx files so the system can find tftp.exe faster.

First, obtain the password for the router: In the web interface, go to Administration -> Commands. Type "nvram get http_passwd" into the text box and click "Run Commands". When the page reloads, it will show the password below. Make note of this password for later use.

Alternatively, you can obtain the password via telnet. Assuming your router can be found at 192.168.1.1, you'd type "telnet 192.168.1.1" at a command prompt to login to the router. Once logged in, type "nvram get http_passwd" and write down the result.

Download the Tomato firmware and extract it. In the "trx" subfolder, rename the file code.trx to code.bin. (DD-WRT does not recognize the .trx file extension as firmware.)

Update the firmware via the DD-WRT web interface. The Tomato firmware is now installed.

Access the Tomato web interface. Use the username "root" and the complete password provided by the "nvram get http_passwd" response above.

In the second window, cd to the directory in which your firmware is located. Then execute the following:

tftp

binary

rexmt 1

trace

connect 192.168.11.1 Even though the router is still powered down, tftp doesn't actually "connect" when you execute the connect command. Instead, it merely stores the address away until needed.

Still in the second terminal window, type the following but do not execute yet:

put tomato.trx

Plug the router back in. The moment you see pings coming across in the first terminal window, execute the put code.trx command you prepared in the second terminal window. If you see a successful transfer, leave the router alone for at least 2 minutes, then unplug the power, wait 10 seconds and plug it back in.

Reset your computer's ethernet card settings back to use DHCP. You can also manually enter the following settings: IP=192.168.1.2, mask=255.255.255.0, gateway=192.168.1.1.

To login to the router, just go to http://192.168.1.1/ in your web browser. Login name is root, password is admin.

According to the author, it is not necessary to reset the configuration if you are upgrading from a previous version of Tomato Firmware. If you are upgrading from another firmware, however, a reset is recommended (Tomato's FAQ). Log in to the router, and reset factory defaults (under Administration/Configuration/Restore Default Configuration, select the Erase all data in NVRAM (thorough) option and click OK. The router will restart. The factory default login is "admin" with a password of "admin".

However, unpredictable behavior of the router is nevertheless often experienced, and can usually be cured by an NVRAM erase and reconfiguration. NVRAM can also become corrupted in use by brownouts, etc. causing the same unpredictable behavior.

In some cases, you may need to reboot the router manually before the changes go into effect. If the changes involve switching wireless settings, you may need to reboot both ends. (Hasn't been known to happen with 1.07 or later firmware)

Not all wireless modes / security combinations work. For example, WEP, Client and WDS will not work in WPA2.

Graphs/SVG may not work with all browsers. Firefox: Use 1.5 or higher. Internet Explorer: Use Adobe SVG. Opera: Use 9.0 or higher. Safari: Use 3.0 or higher.

Certain wireless clients cause the router to crash or reboot on while trying to associate. The "ND" drivers are an attempt to rectify this, but when used, Intel 2200B/G wireless clients cannot associate. The following script corrects the problem with the ND drivers - just run them once from the command line, once committed to NVRAM it doesn't need doing again.

nvram set wl_reg_mode=off

nvram commit

[More recent versions of tomato such as TomatoUSB have a wl_reg_mode checkbox in the wireless setup menu].

Tomato implements traffic shaping by user-settable rules that divide all connections into classes and allocate bandwidth to each class.

Normal QoS classification and access restriction checking is performed on packets traveling out to the Internet (outbound), i.e. the source is from your computer and the destination is outside on the Internet. This is the more important kind, because you can thus influence the behavior of packet queues in your router and DSL modem, avoid buffer overruns and let important packets jump the queue.

You can additionally restrict inbound traffic.

Although there is an option to limit the download speed, it's often not recommended since what the router is really doing is dropping packets, which means they may need to be re-sent again over a slow Internet link. Some people erroneously believe that since you have no power over incoming traffic queues in routers out on the Internet, there is not much you can do to improve their behavior. However, this is a misconception, by understanding how TCP works it is most certainly possible to use QOS to manipulate and influence the incoming traffic. For more help on using QOS, visit the various forums.

These work by matching known patterns in packets. Some protocols produce reliable uniquely identifiable signatures, but some do not.

A change in the protocol's design can sometimes break these.

Some L7/IPP2P patterns may depend on which direction the data is going. For example, an HTTP request from a browser is different from an HTTP response from a server.

Custom L7 patterns can be stored in /etc/l7-extra/ (you need to create the directory). It's up to you to actually populate it before the firewall starts. This can be tricky if you're using external storage, so consider just using JFFS2 or even simple "echo" statements in the startup script. To learn more about L7 patterns, go to l7-filter.sf.net.

When testing changes to the QoS rules, restart the application on your computer to make sure it's connection is re-classified under the new rule. NOTE - You can now enable "reset classification when making changes" instead.

KB transferred match:

This is the OUTGOING (to-WAN) data transferred in kilobytes. Consider the amount an approximate value since it doesn't take into account protocol overhead and uses the 1024-based definition instead of the 1000-based definition used more commonly in networking.

Entering an upper limit of 1GB (1,048,576KB) or more is considered unlimited and will match anything above 1GB.

IPP2P may not work properly with this since IPP2P doesn't keep track of its state.

Sticky rules: IPP2P/L7 are "sticky" in that once they match, no other rules are processed. IP/MAC/port-only matches can also be sticky if there are no IPP2P/L7/KB matches above them. When coupled with a KB transferred match with an upper limit, they are not considered sticky. What this all means is you should watch out for rules like the following: "#1: L7 ABC & 1024KB+, #2: L7 ABC", the #1 rule may not match at all since #2 will lock-on if it sees L7 ABC within 0-1024KB. To get around this particular case: "#1: L7 ABC & 0-1024KB, #2: L7 ABC & 1024KB+."

Precedence: The rules are checked in the same order as they appear in the GUI, from top to bottom. The first rule that matches sets the class. If you disable "strict ordering", rules (no longer applicable) with IPP2P, L7 and KB matches are grouped in one set and are checked first, the rest in another. In the latest versions of Tomato there is no checkbox to turn off "strict ordering".

If you're concerned about performance: IPP2P and especially L7 are slower than simple IP, MAC or port matches.

Recommendations (incomplete, because some settings are undocumented and their effect is not known):

The following recommendations assume that you have some traffic that is critical and cannot tolerate lag, such as online gaming, and at the same time some other traffic that saturates your outgoing (upload) channel and interferes unfavorably with the critical traffic. For example, every time one user uploads a file, another user experiences intolerable lag in an online game.

Open the QoS, Basic Settings page.

Enable QoS.

You can prioritize ACK packets for absolute best performance. Be aware that if this is checked, then P2P traffic (which is mostly ACKS) will be prioritized, which will wreck your QOS settings. Effectively, you have placed most P2P in the highest class!

Activate "Reset class when changing settings", because this helps you to test the effect of your settings changes. It has no effect when you do not change any settings, so usually this can remain enabled.

The "Default class" is the one into which all connections go that are not caught by any of your rules. Use a setting that requires the least number of rules. If you don't know, try "Medium".

It is best to remove the rule for P2P, set your default class to e.g. lowest. In this way anything that is not specifically addressed by a rule will bypass the rules and end up in the default class. This is the best way to handle P2P.

Max Bandwidth is important, because it can avoid queues and the consequent lag in the DSL modem. Set it to a little less than the known and measured maximum throughput of your outgoing DSL channel. For example, if you have a 16000/1000 ADSL line, which you have measured to actually provide 1000 Kbit/s (125 KByte/s) outgoing, set it to 900 or less. Then tune this setting by saturating the outgoing channel (run a long file upload to a fast server or similar) and at the same time running ping tests and observing the turnaround times. If the setting is too high, you will observe too many unacceptably long turnaround times. Reduce the Max Bandwidth setting until you are happy with the results. You may have to set it to as much as 33% under the actually achievable maximum data rate to achieve uniformly low ping times.

The settings for the 10 classes from Highest to E have the following meaning.

The left figure determines the guaranteed bandwidth (data throughput), which is distributed fairly to all connections in the class.

If the 10 figures in the left column add up to more than 100%, the router still works well, but it is difficult to predict the bandwidth distribution, so this is not recommended. On the other hand, you can have the figures add up to less than 100% without any problems, if you want to guarantee only low throughputs. Don't worry, the router will still allocate all remaining bandwidth as well.

The router determines the bandwidth for each class as follows.

Each channel is allocated its guaranteed bandwidth (according to the left percentage figure).

The router determines how much of the allocated bandwidth each channel actually uses and from that determines the remaining, unallocated bandwidth.

After doing this for all channels, the remaining bandwidth, if any, is given to the class Highest.

The router again determines how much bandwidth is actually used in the Highest class and how much still remains unused.

This remaining bandwidth, if any, is given to the next lower class, High, and so on down through the classes, until all available bandwidth is allocated. All lower classes, for which no extra bandwidth remained, keep only their guaranteed bandwidth.

The router regularly, in short intervals, repeats this procedure and reallocates the bandwidth according to changing demands.

This means, by the way, that the guaranteed bandwidth for the class Highest has no effect, as long as the total of the left column stays below 100%, as the Highest class is anyway getting all of the remaining bandwidth it can use. You can actually set it to None, as long as you make sure the remaining figures add up to less than 100%, so the Highest class effectively gets some guaranteed bandwidth (100% minus the total of the left column).

If you don't know which guaranteed bandwidths to set, simply distribute the 100% evenly. A good start is to set each of the first 5 classes to 20%, set Classes A to E to None and use only the first 5.

Note that the name of the 5th class, Lowest, is actually wrong and misleading, as the classes A to E are all lower in priority than the "Lowest" class. In fact, the lowest class is E. Often, using all classes will help to provide you with more information as to what is going on via the pie charts and details.

The right figure is an absolute bandwidth limit. Under no circumstances do the connections in this class get more data throughput than this. Unless you have a reason for absolute throttling of particular classes, leave this setting at 100% for all classes. You may use this to limit a class such as P2P, to prevent congestion, if it is taking an unreasonably large amount of bandwidth.

The Incoming settings in early versions of Tomato were rather different. The Maximum bandwidth setting was not an overall limit. It was just a figure used for calculating the class percentages. There were only limits on individual classes. You should use these carefully to prevent congestion on your incoming link. Note that limits work by dropping packets, forcing the TCP retransmission timers at the far end to back off, thus stabilizing the connections. Hence UDP can't be "limited". Be aware that because there is no overall limit, it is possible for the sum of the individual class limits to exceed 100%, so causing congestion. Therefore, it is often necessary to set incoming limits rather lower than we would like, making a tradeoff in throughput for low latency and better stability.

A better QOS Ingress system was first introduced in Toastman Tomato and has since been adopted by others. The incoming QOS operates in a similar manner to the outgoing QOS. Initial "reserved" class bandwidths and maximum class bandwidths are honoured. Individual class limits are now applied correctly. This firmware also has the ability to use your own names for the individual classes. A comprehensive set of QOS rules are included as examples for you to examine and tailor to your own requirements.

The tomato firmware runs Dnsmasq 2.55, "a lightweight, easy to configure DNS forwarder and DHCP server." Most of the configuration is supported by the tomato web interface. However, there may be situations where special configuration is required. The Dnsmasq command syntax applies to the configuration file - just remove the two dashes at the front. To add additional lines to the tomato dnsmasq.conf file, use the Advanced -> DHCP / DNS page of the tomato configuration, in the Dnsmasq Custom configuration section.

There are some examples of using this technique in the Menu Reference / Advanced section of this manual under the DHCP / DNS section as well as Tomato Firmware as DNS Server. An interesting use of Dnsmasq Customer configuration allows support of a device that is configured via DHCP but needs to point to a unique gateway device such as a VPN appliance. The instructions for accomplishing this are described in [Dnsmasq-discuss] Setting different default gateway by mac address. In my case, I wanted to assign a static IP as well. Rather than doing this through the tomato web interface, I added the following lines to the Dnsmasq Custom configuration. The first line defines the alternate gateway (the VPN appliance) while the second line associates the MAC address with the alternate gateway and the static IP.

The client router is the router which does not have an internet connection.

The host router is the router which does have the internet connection and is going to share it with other routers.

To make troubleshooting easier, you can set client router's SSID to something different. Later you can set it to the same as the host router's SSID or leave it different.

Also, it is a good idea to turn off any encryption while setting up WDS repeating as it is known that some encryption methods prevent WDS from working correctly. You can re-enable it after you have things working properly.

Using WDS to extend your network will reduce throughput, as each unit has to first receive the data and then resend it over the wireless link. Each added unit in the chain makes matters worse. For best throughput always wire extra AP's with CAT5 cable.

For the client router, on the Basic -> Network page, in the LAN section:

set the Router IP Address to a static IP in the range of the host router (e.g. if your host router's IP is 192.168.1.1, set your client router's IP to 192.168.1.2).

uncheck the DHCP Server to disable it (you can only have one DHCP server per network).

For both the client router and the host router, on the Basic -> Network page, in the Wireless section:

set the Channel to the same channel on both routers

set the host router's Wireless Mode to Access Point + WDS

set the client router's Wireless Mode to WDS

set the WDS to Link With...

on the host router, add the client router's Wireless MAC address to the first MAC Address field

on the client router, add the host router's Wireless MAC address to the first MAC Address field

The above example sets up the client as a WDS repeater, but does not enable Wireless access on the client. To enable the client to serve as a WDS repeater and accept Wireless connections, set the client router's Wireless Mode to Access Point + WDS.

The Tomato FAQ on WDS documents an example with IP and Mac address samples for clarity.

WRT54 Script Generator (download): A little application that generates scripts for traffic shaping. This script generator's main purpose is to limit the bandwidth of users that are connected to WRT (for example, to share the connection in a fair way). The script shapes traffic on the LAN and the WLAN. QoS shapes outgoing traffic on the WAN (vlan1), so if you try to shape traffic on vlan1 you will destroy actual QoS.

Tomato is extremely efficient and will dynamically unload modules, stop services and shutdown processes if certain features are no longer enabled. The following features, once disabled, will result in fewer running processes. Less running processes results in more free memory, less CPU load and faster boot times. In general, it is worth your time to disable unused features. For example, just enable HTTP or HTTPS web access, it is not necessary to have both enabled.

Of course, Tomato runs well with the entire gamut of functionality enabled.

after many hours of searching and reading I found this, and it works. Connected wired to the belkin now and it is wirelessly linked to my buffalo running tomato which connects to my Cable Modem . Now I can ditch a long ugly CAT5 cable and can connect 4 wired devices and have improved signal strength for my wireless devices.

Some NVRAM settings may not be compatible with other firmwares. It is ALWAYS recommended to erase NVRAM and reconfigure from scratch after flashing to or from this firmware. Failure to do so will often result in erratic behavior and instability.

You can enter a custom DDNS URL like the following: http://www.mycustomdns.com/update.cgi?username=scooby&password=spooky&ip=@IP. The "@IP" keyword is automatically replaced with the current IP address. Check with your DDNS provider for the exact format to use.

The BusyBoxcrond included in Tomato is a little different from the Vixie crond found in HyperWRT, DD-WRT, etc. To make it easier and safer to schedule a job, use the helper script called cru instead of manually changing the config file.