Tomato compared with DD-WRT -- my experiences

After having used DD-WRT for more than one year, I recently
switched to Tomato. I hope this summary of my experiences
is useful for other readers of this forum.
Note that it is to be regarded in the following technical context:
2 computers connected to the router: one through Ethernet, the
other one through WLAN. Internet via DSL (2 Mbit/s, PPPoE).
No P2P, no VoIP.

First impression -- the web interface

The Tomato GUI is clear and almost self-explanatory, while the
DD-WRT GUI is partially confusing and hard to understand --
despite the help texts. Unfortunately, the Tomato GUI is
available in English only. This is not a problem for me, but
it may be a bit of a problem when recommending Tomato to others.
Also, Tomato is lacking a status overview page that is displayed
already without a password; this is a nice feature of DD-WRT's.

Logging

This was the primary reason for me to change. First, the DD-WRT
syslog does not indicate when a PPPoE connection is started or
ended. This is a crucial deficiency when you have even the slightest
problems with your DSL connection. In Tomato all I had to do was
to enter

logger 'WAN is up.'

as my custom WAN-up script; the end of a PPPoE connection is logged
already by default.
(To make things clear: With the optional RP-PPPoE driver DD-WRT
would provide still much more useful PPPoE-related information in
the log file; however, this driver is broken. Dito the new PPPoE
driver in the latest DD-WRT v23 SP3 beta release.)

Furthermore, DD-WRT has by default no means to browse or analyze
the log file immediately in the web GUI. I suggested several times
to introduce this ability, but the makers(s) of DD-WRT did not
regard it as something desirable.

QoS

In a single-user environment such as mine, without P2P or VoIP,
the only aspect of QoS that is needed is to prioritize outgoing
ACK packages. I think this is a very common situation, so I was
always disappointed that the feature is not available in DD-WRT.
Well, the respective forum told me to write a QoS script of
my own... (Btw, also the AVM (FritzBox) routers, which dominate
the German market, provide this feature.) I was very happy to
see it implemented in Tomato!
As to the other aspects of QoS, I have no first-hand experiences.

Bandwidth usage statistics

No such feature in the stable DD-WRT, unless you send the data to
an extra PC which needs to be permanently online! (Only the future
v23 SP3 is promising a solution.)

Custom scripts

Under DD-WRT I was using shell scripts of my own for the following
purposes:

I was happy to notice that all of this can be done with Tomato, too.
It was even possible adopt my scripts for #1 and #3 without any
change! Also, I was surprised to see that there are APIs to control
the Cisco LEDs and to make use of the SES button -- something that
is lacking from DD-WRT, even though it was repeatedly requested.

Modes of operation

Whether gateway or router mode, AP, client, client-bridge or WDS --
everything I knew from DD-WRT is available with Tomato, too.
Again, I'd like to point out that the respective web interface is much
more ergonomic, IMO.

Summary

Tomato is, in my opinion, perfectly tailored for home or SOHO use.
As long as you can do with its capabilites, you will be happier than
with the current DD-WRT.

I was happy to notice that all of this can be done with Tomato, too.
It was even possible adopt my scripts for #1 and #3 without any
change! Also, I was surprised to see that there are APIs to control
the Cisco LEDs and to make use use the SES button -- something that
is lacking from DD-WRT, even though it was repeatedly requested.

3)
I set the WAN connection to "keep alive" and added the following
line to the startup script:

cru a reconnect "00 02 * * * killall -hup pppoecd"

Thus, cron stops the PPPoE driver every day at 2:00. Due to the
"keep alive" setting, however, a new connection is established
immediately.
(Background: My ISPs uses to cut any connection after 24 hrs,
and I want this to occur at a "harmless" time of the day, where it
doesn't hurt me much.)

To my experience, this is dangerous. When there is already
a PPPoE connection, "service wan restart" may cause the
new one to be established already before the "old" connection"
is properly terminated. In consequence, a new logical ppp
interface is created. (Yes, this did happen in fact!)

On the other hand , I see no problem with "killall -hup pppoecd".
Under DD-WRT, too, it has proven to do the job. Note, however,
that the process name "pppoecd" holds only for PPPoE (as opposed
to PPTP) and only for the current implementation.

i have to agree with Odin-60. At the beginning i used the "service wan restart" command and sometimes there was a new logical interface created. Since i use the command "killall -hup pppoecd" everything is OK now and works without a problem.