Discussion in 'Tomato Firmware' started by shibby20, Feb 26, 2011.
I think you wanted the MIPSR1 build not the MIPSR2
Ah, I understand now.
Is there any easy way to unbrick it?
I think you maybe needed MIPS1, not MIPS2; tomato-K26-1.28.RT-MIPSR1-140-Mini.zip
PFSense on a nano box (for constant updates) for front end and routers/switches behind it along with a RADIUS server on a another nano
I've historically ran Toastman builds. I recently (past month) switched to kille72 (based on Shibby). This is on an RT-AC56U.
I'll most likely be switching to a Ubiquiti EdgeRouter 6P (model ER-6P) and running their native firmware alongside a Ubiquiti UAP-AC-LITE solely for 2.4GHz and 5GHz wireless (which I already own/use since wireless on my RT-AC56U is horrible and unstable; had to disable both interfaces). I've said this in the past -- and even tried it (I wasn't impressed with the MikroTek router I bought, returned it) -- so I probably sound like a broken record to some.
But one thing is for certain: by switching to a completely separate AP that provides wireless, I have a lot more firmware choices (ex. OpenWRT/LEDE), or other hardware/router choices (see above), since I'm no longer "locked down" by Broadcom binary blob wireless drivers. And while I'm definitely not a big fan of the UAP-AC-LITE's Java+MongoDB-based UniFi software, I rarely have to launch it (the AP is insanely stable, even despite the high amounts of 2.4GHz interference where I live). I'd also like having a router that offers a 24V PoE port since I could power the UAC-AC-LITE directly via an Ethernet cable rather than a PoE injector + wall wart. Having other firmware options also means I could run something with a recent Linux kernel, not 2.6.xx. I suppose I could run OpenWRT/LEDE (found bugs and wasn't particularly impressed with its GUI, but CLI and overall architecture was excellent), or AsusWRT/Merlin (I really can't stand Asus's GUI, feels like it's designed for gamer kids).
Anyway, everyone's needs are different. I feel like TomatoUSB has taken a pretty severe plunge for the worse with the introduction of MultiWAN, which made an absolute mess of many things + introduced way too many bugs, but worse, made it impossible for Toastman to backport the [non-MultiWAN-related] changes into his firmware. There's little recourse; kille72 and pedro's work is the only stuff that's going on right now, and I'm not so sure I like the direction that's going either. Things are kind of in a state where literally starting over makes more sense. The original Tomato project was awesome back in the WRT54G/54GL days, but it's become filled with too much junk and not enough good development (hacking yes, development no).
could not have said it better i was also running Toastman and i have switch to wrt (kong) now but would like to and update of Toastman or something like that. MultiWAN is not worth all the bugs and problems.Untill Tomato make a complete turm around i will hive to stay with WRT.
Really two options. Roll your sleeves up or as I’ve said before, don’t let the door...
Slapping MultiWAN on top of the old Tomato code base was a recipe for disaster. Asus also went down the same route with their Dual WAN support, and it's also highly unreliable even after 4 years of development.
MultiWAN support is something that would have required to be considered during the initial design time. Retrofitting it causes too many issues.
I recently switched to pfSense running in a Qotom Q355G4. My plan included flashing my 3 routers to DDWRT or Asuswrt-Merlin to use them as AP. I tried yesterday both firmwares in my AC68U just to find out that both DDWRT and Asuswrt-Merlin won't allow me to change the country it broadcasts. I need the AP to broadcast the correct country information otherwise my MacBookPro finds out a Spotify cast device that broadcasts "China", sets itself to "China" and misbehaves.
I am now considering the Ubiquiti UAP-AC lineup, still studying them and already missing Tomato.
Does anybody know if Shibby's builds are vulnerable to VPNFilter?
I have yet to see an adequate description of how to test a firmware for vulnerability to VPNFilter, so the only ones at this point who likely know are either security researchers or the malware authors. Its known to afflict routers running on busybox with MIPS CPUs, but may depend on versions that haven't been patched by the OEM firmwares in years. At this point I don't think there's enough information published to test. You're welcome to read through the current writeup and confirm or deny my analysis:
ASUS pushed at least a couple new firmwares today containing in the release notes "Fixed CVE-2018-8877, CVE-2018-8878, CVE-2018-8879" which as of right now aren't showing on official CVE sites. These may correlate to VPNFilter, we'll have to wait and see.
Oddly the firmware check on the router alerted me to the new version faster than ASUS updated their website, although I was able to download it from their site by modifying the link to the old firmware with the new version number (e.g. changed 8228.zip to 8291.zip).
Two of them are minor information leaks that require access to the webui, and the third one is a webui-related security issue that I fixed a few weeks ago in my own firmware. That's all I can say for now.
The update server is totally separate from their support site, so it's always a matter of which one they update first (plus, their support site takes time to propagate throughout all their regional servers).
I retired Tomato (Shibby) as my primary gateway / firewall about a year ago (Netgear R7000). I'm using a somewhat old PC, set up as a PFSense box at the moment, which is still much more powerful than Tomato was.
I have 4 AP's connected to the PFsense box (wired), all broadcasting the same SSID to provide optimal wireless coverage throughout my house. 3 of them are running FreshTomato, and one running OpenWrt-LEDE (because it doesn't support Tomato). They are all configured very simply to only act as dumb AP's, with PFsense doing all the NAT, firewalling, etc.
R7000 lost password. I just reloaded a R7000 from stock to 138. All running fine. Set it up as an access point only behind a pfsense box. All working great, but I forgot the admin password. Actually dont remember even setting one up after I flashed to 138.
Tried the Wifi on/off for 25 sec on port 223, no joy. Did a 30/30/30 and still can't get in.
Fixed it - just used the default Netgear admin/password combo. Next time I'll follow the directions.....
Funny - I could not get the wifi on/off port 233 access to work. It would connect, but now prompt.
To follow up on the security question is there a firmware based on tomato that patches KRACK vuln and dnsmasq vulns? I believe I asked this 8 months ago and nobody had an answer then. I would like to get some version of Tomato on my router that is not susceptible to these vulnerabilities. Thanks
The last release of Shibby was v140, which is from March 2017. No commits have been done since then.
Let's start with the dnsmasq CVE concern.
Those CVEs -- CVE-2017-14491 CVE-2017-14492 CVE-2017-14493 CVE-2017-14494 CVE-2017-14495 CVE-2017-14496 -- are from 8 months ago (roughly October 2017). Thus, you know the answer: the fixes are not available in native Shibby firmwares (i.e. firmwares released by Shibby). However...
Did you review the dnsmasq commit history to see if they had been addressed? Did you Google information about those CVEs, to find information like this, which clearly shows dnsmasq 2.78 or newer fixes them? Did you then review other forks of Shibby, such as FreshTomato-ARM (previously known as Tomato-ARM by kille72; it got renamed), and do some simple digging to find out that it uses dnsmasq 2.80test2, hence those CVEs are fixed in said firmware? But wait, there's more...
In both your post here and the one you linked, you didn't list what model of router you're running, so if you're using MIPS you may end up having to consider FreshTomato-MIPS from pedro311 (kille72 and him work together on both projects) which is using dnsmasq 2.79 thus immune.
As for KRACK: see my first line, and this Bitbucket Issue. You can consider other firmwares -- see above paragraphs for some -- which in those threads discuss the KRACK concern, and potential wireless driver updates from Broadcom. The FreshTomato-ARM thread, and the older the Tomato-ARM by kille72 thread has several posts in it about KRACK. Within the latter, you will find this post which should answer your question directly about ARM. As for MIPS: vendors are no longer caring too much about older MIPS routers -- Broadcom basically isn't caring, so no driver updates in a lot of cases -- and so you may be SOL there. If so, I'd suggest disabling the wireless interfaces on your router + buying a Ubiquiti UAC-AP-LITE and using it to provide WiFi capability while attached to your existing router.
Oh, it seems I did the work for you, in about 20 minutes... sorry about that.
The short of it: it's good you're concerned about security issues, but when it comes to Tomato, you really need to follow what goes on in the community regularly (re: firmwares) to get an idea of what all is going on. The situation is not particularly good right now, as there's only two forks (see aforementioned paragraphs) actively being maintained.
KRACK is a client-side vulnerability. If you run your router in AP/router mode, then the things that require patching are all of your clients, not your router.
Routers require patching only when running in STA mode (for instance, as a repeater).
Thanks so much. I have WRT54GL, WRT54GS and Buffalo WHR-G54S. I will ask in the FreshTomato-MIPS thread if it is vulnerable to any known CVEs.