Tomato Shibby's Releases


I will base my opinion here on what differences I have seen in my time of using both. Guys please don't get furious with me if I'm wrong! :D

Tomato:

  • Has better OpenVPN support.
  • A more user-friendly graphical user interface that is faster to use.
  • A wireless survey page for mitigating interference from other channels.
  • A nice looking Bandwidth Monitor that was one of the main features for me when I switched, so you can monitor your stats by YOUR selection.
  • An update notifier that tells you when a new version is available.
  • Integrated Tor and Bittorrent Clients as well as a variety of other expandable tools.
  • Best use I have seen for the USB Port, and in my case I use it for my Master Browser share.
  • Ability to use Dual-Gateways and have both VPN and ISP running at the same time.

DD-WRT:

  • You can get a better selection of Routers to use along with updated Drivers for those devices.
  • Better Wireless Repeater modes even on other subnets.
  • Better built in options like Wifidog for Hotspots.
  • "Pro" Paid Version allows you to do more for better network reliability. Great for a Company but bad for a home user.

If I had to compare the two using a car analogy... I would say Tomato (depending on the flavor) is like a BMW, and DD-WRT is like a Porsche. BMW loves to add more technology to their base designs without much change to the overall "look." Porsche on the other hand loves to stick to the same design even though they have the "tools" from the industry standard to make it look different, or even add more "tech" features. Both are very fast and have their similarities, but it comes down to the Manufacturer's choices on design, and the features that make you choose one over the other.


Objective comparison. And nice analogy :)

Tomato also has long time experienced devs. and users who are not close minded and can see both firmware as alternatives, get to know the differences to fill their view on what a consumer router can do.


DD-WRT Guru
Posted: Sun Dec 04, 2016

My opinion is no on the tomato, unless it is ketchup or a finely chopped salsa. Otherwise, I can't stand the texture.

Toast is good too, but only if you've got some really good jam and maybe a little butter to go along with it.


DD-WRT Guru
Posted: Mon Dec 05, 2016

kernel wise - DD-WRT has the most decent (new) kernels, even if they are still behind....
Future wise - Tomato has good graphic shit and DNSCypt if im not wrong...but DD-WRT has a more versatile use

about the Toastman..., he comes early mornings only on Tuesday's, at Hoxton Market street, never had any better toasts....
 
So I'm going to try to summarize this for posterity's sake:
- Broadcom only provides wireless blobs that are built around the 2.x kernels even with their latest SDK's. Hence Tomato/Asus etc are always going to be stuck with 2.x kernels, unless Broadcom starts handing out the code for their wireless blobs OR someone manages to get documentation around their network architecture/cards and built custom driver code. Does anyone know if it's possible to get a hold of the Broadcom driver reference guide or register document - if so I'll be happy to whip up a driver.
- DD-WRT managest to get it to work with 4.x because BrianSlayer has access to the Broadcom code and manages to recompile it against the 4.x kernels
- All in all it doesn't really make a significant difference to the performance or features upgrading to 4.x kernel, sound like 2.x kernel is great for home uses and Tomato overall is killing it over DD-WRT where it matters.

The only thing missing right now from rocking Tomato is a stable version of MultiWAN which I'm hoping doesn't have a dependency on 3.x or 4.x kernels. Frankly after using DD-WRT and being fedup of it I'm in love with Tomato.

So @RMerlin if ASUS has a newer wireless blob built in the 2.x kernel is it not possible to integrate that into Tomato to make it rock even more?
 
So @RMerlin if ASUS has a newer wireless blob built in the 2.x kernel is it not possible to integrate that into Tomato to make it rock even more?
This has been done several times over the years, and happens on occasion in all the different firmwares. When it happens, it is a HUGE deal given the effects. It's a cat-and-mouse game, because there's nothing that "magically makes things better for everyone". I'll try to explain, with historical references (and you can find all of this on this forum, as well as the older tomatousb.org forum):

I assume you know Toastman's firmwares had two "flavours" for several years: ND ("New Driver") and non-ND. The ND version had a newer Broadcom wireless driver (I can't remember where it was from, but I believe Asus). The results of that were all over the board: some users reported that ND saw big improvements in wireless reliability, throughput, and signal stability. Others reported worse performance/behaviour and were quite vocal about it. And some others (like myself) saw no real change at all. I'll repeat myself for the Nth time about wireless -- everyone's environment, setup, equipment, etc. is completely different. People "tweak" crap under the Advanced menu without even really knowing what they're doing, then simply because clicking Save can result in the wireless driver being reset internally (which can sometimes un-wedge it or rectify some internal issues), suddenly (within 30 seconds) they think that because they changed Herpderp Fruit-of-the-Loom Mode from "Off" to "Wild Stallyns" that their signals are better and their throughput is better, then start saying "tweak this setting and your stuff will magically get better!" (a common one is insisting that boosting Transmit Power is a good thing: in most cases it isn't, it just makes everyone else's wireless around you even worse).

"Fooling around" with wireless drivers is almost a black art. As an engineer I refuse to believe things are "filled with magic smoke and require wizard-like incantations", but we're working with wireless chipset drivers which come as kernel modules in pure binary form -- and even if they came in source form, do you really think someone has the familiarity with 802.11 as a whole, and the time to reverse-engineer, a wireless driver that supports several models of ICs? -- so there is a most definite "we aren't sure what's going to happen from this" reality.

All in all, we're thankful that there are several companies who make consumer routers that are Linux-based (hence under the GPL, thus must release the source code to the kernel -- Broadcom's wireless drivers are not part of the Linux kernel, thus they are not directly subject to release of source per GPL). For example, I for one really appreciate RMerlin's efforts because he tracks Asus's stuff and if there's something big coming down the pipe (or does come down the pipe), he can discuss that with the non-AsusWRT/Merlin F/W maintainers (Shibby, Toastman, etc.) to prepare for, say, a wireless driver change.

Sorry I'm long-winded, but the questions you're asking mandate answers that encompass years of familiarity with the development parts of Tomato and embedded devices in general. I could talk for another 30 minutes about Broadcom and their horrible "must protect our IP at all costs, hire big lawyers too" attitude (which is nothing new, they've been like this since day one of their existence. Kinda reminds me of Rambus, actually), but that's for another time/thread.
 
Appreciate it thanks. I somehow missed out on the Toastman's ND. I would love to try Shibby's ND version (baseline v132) if possible (nothing against Toastman, have contributed to him also but I liked the way I could control the ipv6 DHCP options in Shibby's version, seeing 2 IPv6 addresses, DHCP and Self Assigned was driving me nuts and was a security concern).
 
Thank you so much, that worked, fantastic

I had a few follow up questions:

1) When I checked the NVRAM macmodes, I received the following information:
size: 37827 bytes (27709 left)
wl_macmode=allow
wl0_macmode=allow
wl1_macmode=allow
wl0.1_macmode=disabled
So I see that your command suggestion successfully disabled the MAC filter for wl0.1
My question is what is the "wl" at the beginning of the list?

2) Advanced > Wireless > Save ensures that the command survives a reboot?

3) Any time I Save the MAC filter (like when I add another MAC address), it resets the settings of all the WLANs to whatever the current setting is in the MAC Filter and I lose the command bypass that I entered into Tools > Commands. Should I be entering the code:
nvram set wl0.1_macmode=disabled
nvram commit
into Administration > Scripts > Firewall in order to ensure that it overrides a MAC Filter Save?

Thank you again for your help in advance

1. as I know, wl = WireLess
2. yes
3. very good question. I have never tried it.
 
Broadcom and their horrible "must protect our IP at all costs, hire big lawyers too" attitude (which is nothing new, they've been like this since day one of their existence. Kinda reminds me of Rambus, actually)

Thank you for the excellent post and reminder of the Rambus fiasco. Since Broadcom is the problem here is there a consumer router out there that is more developer friendly? Wouldn't it be nice if we could port Tomato to another platform that would respect us. I would gladly pitch in and buy one for Shibby to play with if such an animal existed.
 
Thank you for the excellent post and reminder of the Rambus fiasco. Since Broadcom is the problem here is there a consumer router out there that is more developer friendly? Wouldn't it be nice if we could port Tomato to another platform that would respect us. I would gladly pitch in and buy one for Shibby to play with if such an animal existed.

You can try the Linksys WRT line. They are supposed to be such, but I can't tell you the current status. You also pay a heavy price for that line. It's way overpriced, IMHO
 
Thank you for the excellent post and reminder of the Rambus fiasco. Since Broadcom is the problem here is there a consumer router out there that is more developer friendly?
Most people who are actual developers are simply building their own and running Linux natively on them (ex. buy a SFF PC, buy a wireless NIC that has good support/reliable drivers on Linux, buy a 4-port NIC card or just use an external switch (ex. D-Link, Netgear, etc.), then start writing up iptables rules/etc. for yourself).

Other possibilities include OPNsense and pfSense, but these are FreeBSD-based not Linux. I can attest to the OPNsense folks being exteremly attentive to stability. I have no idea what wireless experience is like on these, however. Now you can understand why for wireless, some people are saying "screw it" and buying Ubiquiti UniFi AP devices instead (i.e. standalone devices that connect to your network and provide the wireless AP part, letting your router deal with the routing and possibly the switching (if it has an integrated switch) -- and if they're hooked up to a PoE port, they don't even need an AC adapter for power). These are black-box devices, but they handle the wireless part independently, thus letting you use whatever router/etc. you choose and not having to worry about "wireless driver support".

There is probably a Linux "distro" that is akin to OPNsense and pfSense, i.e. a Linux distro that is about providing a web GUI + router/NAT/etc. functionality.

But really if you want the "Tomato mess" (I say that respectfully) on something else, you're gonna have to build it yourself. Shibby has dealt with this happening -- there are a lot of folks in China who are apparently taking Shibby's Tomato code and banging on it to push it into for-sale products (and then not putting the source up online, re: GPL violation). Licensing violations and unprofessional aspects aside, these folks are in fact doing what I just described (building their own).
 
Might want to checkout this review, where DD-WRT is also mentioned:


http://arstechnica.com/gadgets/2016...ild-faces-better-tests-tougher-competition/3/
I had a chance to read this article today and I have to say the reviewer did not have too much fun with DD-WRT.

I wanted to test the x86 build of DD-WRT on the Homebrew, but I discovered that it hasn't had a stable release for eight freaking years. The last stable version wouldn't boot at all, and the newest uncurated beta (the project drops one every few weeks) was so mind-blowingly awful—in terms of both performance and bugs—that I wanted to light the router on fire. Eventually, I gave up on DD-WRT and turned to its successor project, OpenWRT.

I flirted with trying to install a build of DD-WRT on it, but I backed off in disgust when I saw how convoluted the process was going to be. It's not just a quick flash for the EA-2700; there are downgrades and reset modes and sundry unpleasantness that this device just frankly isn't worth putting up with.
Then why even include it? Is this supposed to be the "control" for these tests? Shitty choice at best and you could have done better for $90!

The stock Netgear firmware vs Kong's DD-WRT build makes for a great contrast. Netgear's latest 1.0.3.4_1.1.2 stock firmware build (which didn't differ noticeably from the 1.0.2.46_1.0.97 it shipped with) clearly has much higher peak throughput in the easiest part of the tests. This means it looks good under simple speedtests and smallnetbuilder's rankings. But when you compare the stock firmware's extremely sloppy looking waveforms to the Kong DD-WRT build's clean, predictable, sharp ones, you should definitely be asking yourself if it's worth it.

This sounds positive and makes me wonder if a user should switch. But how would that look on something other than the R8000?

Much like pfSense, DD-WRT also brings a very rich featureset to the table: VLAN tagging, QoS, graphing, and more. Add that to its attractive, responsive interface, and Kong's build is clearly the smarter choice. The only downside is you're depending on some semi-anonymous person named after a movie gorilla to keep up with vulnerabilities, comb the bugs out of your firmware, and resist the urge to sell you out to the NSA. In retrospect, that's probably not any worse than trusting whoever's calling the shots at Netgear.

I think this last one is supposed to be positive?

Though I'm glad there is a comparison of Enterprise vs Homebrew Routers in the article, I get very confused as to why there is no mention of Tomato (R7000 perhaps?) on any of the included tests?

It's like what the hell is the whole point of the article, power consumption and throughput? It just tells everyone what we (hopefully) already knew! Screenshots of actual features being compared would have been nice. I can't wait for the "WiFi tests" article (Sarcasm).
 
Last edited:
AdBlock RFE Draft:

i've been mocking with the 138 builtin adBlock for a few days. i like it. i think it could use some improvements, as stated below.

  1. the default nitely DL is too aggressive. modify to once/twice a week.
  2. ability to modify the schedule thru the UI.
    i am aware of the cron job, (cru -l : adblockJob). a UI would be nice.
  3. capability to filter out duplicates from multiple sources,
    i.e.:
    Code:
    0.0.0.0 abc.com
    127.0.0.1 abc.com
    0.0.0.0 abc.com #some_comment
    127.0.0.1   abc.com #tab-delim
    127.0.0.1 Abc.Com
    127.0.0.1          ABC.com
    0.0.0.0 abc.com^M
    looking at the current code i would add
    • transition to lowercase
    • remove CR
    • remove comments
    • remove trailing white space
    • reduce multiple spaces
    • turn tabs to spaces
    Code:
    -65: mv $WORK1 $WORK2 && cat $WORK2 | sort -u > $WORK1 && rm $WORK2
    +65: mv $WORK1 $WORK2 && cat $WORK2 | sed -e 's/\t/ /g' -e 's/#.*$//g' -e 's/  / /g' -e 's/[ ]*$//g' | tr -d '\r' | tr '[A-Z]' '[a-z]' | grep -v 'localhost$' | sort -u > $WORK1 && rm $WORK2
  4. remove subdomains -- since these lists are generated for use as a hosts file, they list each subdomain individually. this is unnecessary in tomato, since each entry is added as a domain,
    i.e.:
    Code:
    abc.com
    www.abc.com
    ads.abc.com
    tags.abc.com
    tracking.abc.com
    the entire list above can be reduced to 1 entry, abc.com.
    suggested approach:
    Code:
    -65: mv $WORK1 $WORK2 && cat $WORK2 | sed -e 's/\t/ /g' -e 's/#.*$//g' -e 's/  / /g' -e 's/[ ]*$//g' | tr -d '\r' | tr '[A-Z]' '[a-z]' | grep -v 'localhost$' | sort -u > $WORK1 && rm $WORK2
    +65: mv $WORK1 $WORK2 && cat $WORK2 | sed -e 's/\t/ /g' -e 's/#.*$//g' -e 's/  / /g' -e 's/[ ]*$//g' | tr -d '\r' | tr '[A-Z]' '[a-z]' | grep -v 'localhost$' | cut -f 2 -d ' ' | sort -u > $WORK2
    +66: cat $WORK2 | awk -F. '{for (i=NF; i>0; --i) printf "%s%s", (i<NF ? "." : ""), $i; printf "\n"}' | sort \
     | sed -r 'h;:b;$b;N;/^(.*)\n\1\..*$/ {g;bb;};$b;P;D;' \
     | awk -F. '{printf "0.0.0.0 "; for (i=NF; i>0; --i) printf "%s%s", (i<NF ? "." : ""), $i; printf "\n"}' \
     >$WORK1 && rm $WORK2
    NOTE: in my testing, on a RT-N66U, awk is slower than sed. however awk is faster than sed on a synology DS210j NAS.
    the sed approach would be:
    Code:
    -66: cat $WORK2 | awk -F. '{for (i=NF; i>0; --i) printf "%s%s", (i<NF ? "." : ""), $i; printf "\n"}' | sort \
     | sed -r 'h;:b;$b;N;/^(.*)\n\1\..*$/ {g;bb;};$b;P;D;' \
     | awk -F. '{printf "0.0.0.0 "; for (i=NF; i>0; --i) printf "%s%s", (i<NF ? "." : ""), $i; printf "\n"}' \
     >$WORK1 && rm $WORK2
    +66: cat $WORK2 | sed -r 'G;:t;s/(.*)(\.)(.*)(\n)(.*)/\1\4\5\2\3/;tt;s/(.*)\n(\.)(.*)/\3\2\1/' | sort \
     | sed -r 'h;:b;$b;N;/^(.*)\n\1\..*$/ {g;bb;};$b;P;D;' \
     | sed -r 'G;:t;s/(.*)(\.)(.*)(\n)(.*)/\1\4\5\2\3/;tt;s/(.*)\n(\.)(.*)/0\.0\.0\.0 \3\2\1/' \
     >$WORK1 && rm $WORK2
using the above i managed to get 101288 entries down to 75428 by eliminating duplicates, and 36484 entries after removing subdomains.
 
I think this last one is supposed to be positive?

Though I'm glad there is a comparison of Enterprise vs Homebrew Routers in the article, I get very confused as to why there is no mention of Tomato (R7000 perhaps?) on any of the included tests?

It's like what the hell is the whole point of the article, power consumption and throughput? It just tells everyone what we (hopefully) already knew! Screenshots of actual features being compared would have been nice. I can't wait for the "WiFi tests" article (Sarcasm).

Well the writer did not actually take the time to try to findout who kong is. Not anonymous at all.

The interesting info in the article is the fact, that network performance tests shows a significant improvement compared to netgear fw which is still based on 2.6 kernel.

Wifi on dd-wrt is working flawless unlike tomato where you have to apply settings that do not make any sense, e.g. regulation codes.

Regarding R8000 vs other models, I think R8000 build is pretty much the same as the other models, same soc as R7000.

Worst thing with tomato is, that it ships outdated software, that puts the user at risk, e.g. the previously mentioned nginx php software, the normal user won't even know, that enabling these features puts them at risk.

Same thing could be said about the 2.6 kernel, it is not just unsupported it is heavily patched, which could introduce new bugs, but mainstream kernel devs won't even look for bugs here, only the bad guys will.
 
Wifi on dd-wrt is working flawless unlike tomato where you have to apply settings that do not make any sense, e.g. regulation codes.
i would beg to differ about the 'flawless' performance of wifi on dd-wrt. there are so many different combinations of routers, builds types, versions, that any such blanket statement should be suspect. i would submit that both the dd-wrt projects and the tomato projects are increasingly challenging the limits of their amazing but still limited human developer resources!
 
Worst thing with tomato is, that it ships outdated software, that puts the user at risk, e.g. the previously mentioned nginx php software, the normal user won't even know, that enabling these features puts them at risk.
Anything which includes PHP enabled and functional out-of-the-box is subject to this, it isn't just limited to Tomato. I also don't know which Tomato firmwares include this. Shibby? Unsure. But I do know Toastman does not. Just clarifying this, because my point is "not all TomatoUSB firmwares are the same". But nobody should be writing PHP anyway (I say this as someone who does know PHP). ;-)

Same thing could be said about the 2.6 kernel, it is not just unsupported it is heavily patched, which could introduce new bugs, but mainstream kernel devs won't even look for bugs here, only the bad guys will.
You said "Linux 2.6", so I'm going to hold you to your exact words. The Linux 2.6 kernel is still actively maintained as an LTS release and the Linux Foundation's LTSI group is responsible for that (backed by a board consisting of large-name Fortune 500 companies). The releases which are being EOL'd are minor versions, one at a time.

Tomato MIPS uses 2.6.22, Tomato ARM uses 2.6.36. So yes, MIPS's kernel is EOL'd, but Tomato cannot do anything about it because of binary blob wireless drivers from Broadcom. Some patches can be backported, but that requires someone who is extensively familiar with Linux kernel innards (to my knowledge, nobody that maintains TomatoUSB is).

That said, newer is not always better. I'm not saying older is necessarily perfect either, but be careful what you advocate. :)

So while what some of what you say is true (and I agree with some of it!), others parts definitely border on FUD. I would also like to ask you: this is your 3rd forum post since signing up 2 months ago. What do you bring to the table to help bring Tomato more up-to-date kernel-wise? I look forward to your answer.
 
again with adBlock: release/src-rt-6.x.4708/router/others/adblock
  1. BUG:
    Code:
    72: sed -i $WORK1 -e "/$i/d"
    this can whitelist too much, i.e. "abc.com" can whitelist "abc.com.au" or "abc.com.co", etc.
    i suggest:
    Code:
    -72: sed -i $WORK1 -e "/$i/d"
    
    +72: sed -i $WORK1 -e "/$i\$/d"
    this should limit the entry to the domain & subdomains.
  2. Speed enhancement --
    running sed many times (depending on the whitelist) on the blacklist file (which could also be very large) is slow.
    i suggest compiling all the changes (from the whitelist) and then issue sed once on the blacklist.
    Code:
    -71: for i in $WHITELIST; do
    -72:   sed -i $WORK1 -e "/$i/d"
    -73: done
    
    +71: SEDCMD=""
    +72: for i in $WHITELIST; do
    +73:   SEDCMD="$SEDCMD -e '/$w\$/d'"
    +74: done
    +75: eval sed -i $WORK1 $SEDCMD
    i've tested with a whitelist of 99 entries. there is about 5x speed increase.
    NOTE: security issue with eval?
    there's probably a limit to the size of SEDCMD before it chokes. alternatively we could create a SEDCMD file and do -f $SEDCMD, i.e.:
    Code:
    -71: for i in $WHITELIST; do
    -72:   sed -i $WORK1 -e "/$i/d"
    -73: done
    
    +15: SEDCMD='/tmp/sed.cmd'
    +71: echo "" >$SEDCMD
    +72: for i in $WHITELIST; do
    +73:   echo "/$w\$/d" >>$SEDCMD
    +74: done
    +75: sed -i $WORK1 -f $SEDCMD && rm -f $SEDCMD
 
@Rangaistus: I looked at your comments to the code of Adblock, very interesting.

To remove sub-domains, it is a good idea? Example: I want to block system.mondeos.pl but allow mondeos.pl...

Code:
nslookup system.mondeos.pl
Server:  Asus
Address:  192.168.1.1
Name:    system.mondeos.pl
Address:  0.0.0.0

nslookup mondeos.pl
Server:  Asus
Address:  192.168.1.1
Non-authoritative answer:
Name:    mondeos.pl
Address:  88.198.38.113

Also look at: /tmp/etc/dnsmasq.adblock
 
Last edited:
Hello, I've been using tomato-K26USB-1.28.RT-N5x-MIPSR2-XXX-VPN on Asus RT-N10U till version 138. Version 138 tomato-K26USB-1.28.RT-N5x-MIPSR2-138-VPN does not fit anymore, because it's too big. @shibby20 would it be possible to reduce the size, so that it would fit on router with 8MB flash size?
 

Back
Top