Discussion in 'Tomato Firmware' started by kthaddock, Feb 28, 2014.
Can't wait, thanks so much!
I'm looking forward to that too.
I also noticed that jumbo frames are not working on my Netgear R7000 Shibby 120 AIO
Is the QOS going to be inbound AND outbound?
Outbound only for now. IMQ used to inbound qos is not compatible witk arm kernel version.
I can live with outbound only for now. After all, that is all we had for the longest time.
I am encouraged by your use of 'for now'. It sounds like it is on the list of things to fix.
Is the bandwidth monitoring going to be functional soon as well? Or is that IMQ dependent as well?
Thank you for all the hard work. It is very appreciated.
What addressed/fixed the ping issue?
Since some of you are going back and forth between Netgear, Shibby's and DD-WRT, what are the steps to go from DD-WRT to Shibby's Tomato variant?
Easy, you just have to deal with the password issue:
"If you're upgrading from the DD-WRT firmware, telnet into the router *before* upgrading and
type "nvram get http_passwd". The result will be your password in Tomato. This is necessary
because of a change in DD-WRT's way of using the standard http_passwd variable."
So, if you're on dd-wrt, get your password from the dd-wrt CLI, then just flash tomato firmware. I believe that the user name that the password goes with when you get to tomato is "root". If "root" doesn't work, "admin" will *smile*.
Don't forget to do a thorough nvram erase after flashing and logging into tomato, and a reboot after that.
There is a good router 802.11n very powerfull and suficient for my wifi needs from Asus RT-N18U which I intend to buy soon. Is there any chance to run Tomato firmware on it? It has an ARM Cortex-A9 800MHz procesor, 128MB Flash and 256MB RAM. USB 3.0 and 2.0 ports and performs at 900mbps on pppoe wired WAN to LAN.
This was the only thing which kept me from finally installing Tomato onto the R7000. Using now Kongs DDWRT build but Im not entirely happy with it. Tomato was always my favorite Firmware.
Can not wait seeing v121 being released!
Search is your friend.
Thanks I don't know how I missed it. Seems to me the best buy.
For Victek: I've been using your version of tomato firmware for a few days now, and have been enjoying the fact that it just works, no problems. I was wondering, though, why it gave the CPU Clock as ~1600MHz. So I did this on a telnet window:
root@unknown:/tmp/home/root# nvram get clkfreq
This shows that this version of tomato is running the router slower than it's ratings of 1000,800. I will raise this to 1000,800 with this:
nvram set clkfreq=1000,800
Also curious if you're working on your next tomato version for the R7000? I'm hoping that you are!
Thanks very much.
Edit: I see that someone else posted about this earlier, sorry to repeat. Don't see how to delete this post, though.
Apparently dd-wrt uses kernel 3.10.25 for the R7000.
Shibby's build 2.6.36 as far as I can see.
Is it worthy looking into updating the tomato kernel too?
Just a thought...
Not possible. Firmware is stuck with whatever kernel the driver blob has been built for, aka 2.6.36. DD-WRT has driver source, tomato does not.
I think you're talking about RT-AC56, correct? then the CPU speed is correct. Version 1.3g for R7000 and other ARM routers it's available.
Sorry, apparently I didn't mention that I have an R7000...so I changed the CPU,memory clock pair from 800,533 to 1000,800 and everything's great.
Thanks, enjoying Victek tomato RAF a whole lot!
Thanks for the great release guys! I'm on Victek 1.3g for my R7000. Pings seem very stable. I can't seem to configure web monitoring. Regardless of what I do it is always empty - is this a known issue? My R7000 CPU shows fine (1000,800) in telnet (but it does show 1998 MHz in GUI). PS: Is there a telnet command summary someplace?
The basic command set is Linux shell, of course. You'll find the Linux man pages online. The additional commands like "wl" and "nvram" can be found documented online as well.
Thedak about web monitor look on page 57
Hey shibby, do you know when you'll release build 121 with the ping fix? My router has been pretty stable until today, and I've had to reboot 3 times to bring my ping back down to "normal".
Just bought me a R7000! First thing I did was flash me some shibby on there. Just curious on what others are setting there wireless transmit power, its defaulting to 42mW. I'm getting pretty bad wifi signal, can't even get on wifi on my patio, and orientated the antenna's properly.
Should I bump up the mW to around 70-80? Just curious what others have successfully done.
Wondering if the weak wireless is the issue of setting the wireless region (setting is in Advanced wireless settings) to US? I'm in the US, and noticed that until I set the wireless region US, my wireless was pretty weak. As a result of setting the region to US, the strength increased noticeably, up to normal for the R7000.
Also, I've been setting tx power to "0", which I think triggers the default maximum. "42" may also do that (it is the answer to the Ultimate Question of Life, The Universe, and Everything after all *smile*). But I could be wrong about that *smile*.
Edit: Yes, with tx power set to "0", I see the maximum wireless power being used by the router:
root@unknown:/tmp/home/root# wl -i eth2 txpwr1
TxPower is 127 qdbm, 31.75 dbm, 1496 mW Override is Off
root@unknown:/tmp/home/root# wl -i eth3 txpwr1
TxPower is 127 qdbm, 31.75 dbm, 1496 mW Override is Off
Is it not possible to copy the driver used by DD-WRT?
Out of curiosity, which build are you running? I've stuck back on shibby 118 because I saw various reports of woe on 119 and 120, and am patiently awaiting 121. So far, my throughput and wireless (with the original non-US regions selected) has been much improved over my e2500 + tomato-shibby setup. So I haven't felt pressure to take the incrementals until there's some positive reported results on subsequent builds. I'm just finding it difficult to keep track of what build(s) people are actually reporting their results about.
Victek v1.3g today *smile*. Victek v1.3f yesterday and for some days before that. Just found Victek update yesterday. I've found Victek's tomato a little easier to stabilize the ping time, so have stuck there.
Will try Shibby v121 when it comes along, of course *smile*. Be nice not to have to wrestle with ping times for an hour or two after flashing!
Anyone know if you can restore saved settings successfully on Victek v1.3g?
i wuold like to use your build for my new Linksys EA6300V1.
should i do it or wait till is ported for my device?
Does that mean we're not getting a Tomato FW for the R6300v2? Would installing DD-WRT for R6300v2 first (the .chk file) then upgrading to tomato using bin bypass the header problem? Sorry for my ignorance... just really had hopes to use Shibby's tomato on my R6300v2
that means i broke my R6300v2 unit. IMO it has CFE broken. I am able flash ofw or dd-wrt but only via serial cable. I am even not able to upgrade OFW via GUI because variable board_id disapear from NVRAM. Even when i add this to nvram and commit changes then after reboot is gone.
Won't the CFE let you do a "burnboardid U12H240T00_NETGEAR"? Maybe I have it wrong?
please read changelog first!
@thedak - thanks for advise. I will check.
what is the AIO version?
All-In-One - all available features in image.
Thank you Shibby!
I hope BW tracking gets implemented soon.
Do the same install instructions for 120 also apply for 121 for R7000, if we're on netgear firmware?
Okay, v121 took about 30 minutes of rebooting (with CTF on, since I don't know what else to do) to stabilize the ping times. Better than the last time I tried Shibby when I spent about 2 hours and just gave up, but disappointing, sorry to have to say that.
I don't know if ping times would ever have stabilized with CTF off. I'll try that another time *smile*.
Update: Now that the ping times have normalized, v121 has run really well for the past hours, fast and stable so far. IPv6 is also working well. Couldn't ask for more at the moment, thanks!
Am using Tomato on my e3000 router. No issues.
Bought ac68r. While Tomato Arm was getting built, installed Asus Marlin built now on latest)
when I am trying to flash the router with Tomato ARM, latest version, via Asus Restoring software, the process fails. in between. The firmware appears to get loaded into the router, but does not get anywhere beyond that. I then have to restore the marlin/asus firmware again.
I tried original Asus firmware as well... Same results.
Not sure what else can I try to get Tomato installed.
Also, the firmware size of Marlin, and Asus are @28MB, while Tomato is @13MB.
Not sure which BW tracking you're talking about, but I see real-time bandwidth tracking working! Can't tell if anything else is working yet *smile*.
Well, it's not logging...
Nice build Shibby! Been running since early this morning. Did a few reboots and enabled CTF and pings seem very stable, throughput stable, and web logging works fine. Haven't had any issues so far.... Really appreciate it (Netgear R7000)
For some reason on R7000 build 121 shibby I cannot get my 2.4Ghz band rate higher than 72 and my 5Ghz band higher than 300. I have both set to United States, with a tx power of 0. I am using WPA2 Personal/AES on both bands and Channel width of 20 and 40 lower/upper showed no change on the 2.4 ghz. On the 5Ghz I have it set to 80 upper. I have disabled WMM on both which helped, (originally my 2.4 ghz was dropping to a rate of 5 and wouldn't go above 24 before this). Any Ideas? My e900 i just replaced this with was running at full 300 on 2.4ghz using the same settings I implemented on the R7000. Not sure what to try next :/
Strictly speaking, you shouldn't expect more than 54Mbps if you have WMM disabled...don't know how you're getting 72Mbps on 2.4GHz. with WMM disabled. I would enable WMM, and then look elsewhere. The rest of what you're saying sounds fine. Did you do a thorough nvram clear when you started working with v121? You're supposed to do that if you're coming from Netgear stock or dd-wrt. If you're using a previous version of Shibby's, I'd still do a reset to factory defaults, since the version of wireless drivers was changed and the defaults required by that may also have changed.
Yes Nvram was cleared, as I came over from DD-wrt. I flashed back to stock, reset buttoned, then flashed initial build. Then I couldn't access the router till I manually set ipv4 settings of my nic to IP 192.168.1.2 subnet 255.255.255.0 with gateway 192.168.1.1. after that I could access tomato interface and flashed 118 full , then cleared nvram then flashed 121 and cleared it again. I just enabled WMM again on both and let it sit a little and now im seeing a 144 rate on 2.4ghz and 300 on the 5ghz. Not sure im gonna be able to accomplish better than that without running stock firmware ..... which isn't an option because I love tomato.
You know, you can flash directly from dd-wrt to tomato, that's what I did this morning. You just need to get the encrypted form of your router's password out of the dd-wrt firmware using the CLI, then you can flash tomato directly and log in with the encrypted dd-wrt password as your initial password, and user "root". Then do a nvram thorough wipe, and your password will be the usual "admin" at that point *smile*.
You can get your encrypted password from dd-wrt this way:
nvram get http_passwd
It's really easier than flashing from dd-wrt back to Netgear stock, and then to tomato from there. But you end up at the same place *smile*.
What about flashing directly to dd-wrt from tomato? I don't know if I can deal with this unstable ping. I love tomato WAY more than DD-wrt, but the ping being all over the place is actually causing an issue with teamspeak.
I flashed directly from Tomato to DD WRT today, I did a nvram erase on tomato before flashing to DD WRT, and once you are flashed to DD WRT. It always ask you to set a username, and password. So you are good password wise.
I'm going to stay with tomato and see how long the ping times stay down. Right at the moment, my wireless ping times are mostly 1, some 2ms, 3ms at the most, and wired ping times are <1ms. As long as they stay in that range, I'll stick with it, since I like the performance and the web admin interface. We'll see.
my ping has been stable. I have had 0ms wired and <1ms via wifi. ive checked a few times but im not having the problem some people are having Thank you shibby
Nice work Shibby. This is a nice progression of fixing things. The power of the R7000 is incredible compared to the 3500Lv1 that it is replacing.
It is one step closer to being an equal replacement for the MIPS versions.
I had not used your firmware till I purchased the R7000. I was a Toastman (and still am on the primary router)user for quite a while and always found his build well suited to me needs. Yours has some interesting features. The web server for one gives me a few interesting ideas.
I do have a question for you;
Do you have SNMP support? I see on your web page that it was added to your version but I can not find it. Is it still in the AIO? or is it not working on the ARM builds yet?
Another question: With all the Flash that is available in the ARM routers, are you planning on adding anything additional to the firmware? Where the older routers the kernel and programs had to be trimmed down as much as possible in order fit in the limited flash this is not as big a problem now. I am just curious if you had any ideas or plans.
This is the weird part. When I first started using it, pings were fine. I did something in the web interface and upon reboot after that it started acting very unstable. A dozen reboots never fixed it. So I'm not sure what's up. I left it going all night and I was going to flash dd-wrt this morning. Before I did that, I wanted to see IPv6 working... So when I got it working based on what someone else had mentioned in a thread, I rebooted to make sure that config worked past a reboot, and now my pings are back to normal. I know it had nothing to do with what I saved in the config, unless there was a stuck nvram setting and doing a save reset them all, who knows. I don't know how it works internally yet... I'm going to stick with this because I like it much better than dd-wrt, so as long as I can keep it at a good stable ping, I'll be fine.
What did you do to get IPV6 working?
Here's the two lines I put in my firewall script that make IPv6 work for me:
echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/forwarding
ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i vlan2 -d ff02::1:ff00:0/104 -j DROP
This is for Comcast. The second line gets rid of the "neighbour table overflow"'s that I see from Comcast. You only need it if you get those messages filling up your log *smile*.
All I ended up having to do is put this in the Firewall script:
echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/forwarding
I strayed for a bit and tried DD-WRT, the lack of native IPv6 support makes me sad. Going to try out shibbys build now since I have to flash back anyway.
They (dd-wrt developers) are working on IPv6 support, but aren't there yet. I agree, that's the primary reason why I'm using tomato at this point.
I just don't get the ping issue. Pings to the router over either wireless or wired clients is not the issue. It is pings when pinging "out there" somewhere that are the problem. The symptom that is seen is stalls and lags when surfing the web. Pings within the network should be completed in no time. As you are reporting. What are the pings when you ping yahoo or google, etc.?
Unstable or long ping times to the router will most certainly affect you connection to servers on the internet. A 300ms ping to the router from a wired client will mean you are adding 300ms to a ping to yahoo or google. So yea, pings to the router a part of the issue here. And its not pings that at the worry, the ping issue tells you that it's adding latency to your network connections in general.
IF the pings to the router from clients was long that would be part of the issue. They aren't. It is pings from the router to the great wide web that are long, unstable, etc.
Its been confirmed in other threads that they are long.
I used Shibby and can assure you the pings from clients to the router as fast as DD-WRT. It is from the router out. Rebooting a few times gets the pings from clients to the router stabilized. And I'd like to know if the router out are stable and quick as well with 121.
As long as the ping times are stable between my computer and router, the ping times that I see to google.com, yahoo.com, etc. are low and stable (v121), and the speedtest results that I get are comparable to dd-wrt results. When the ping times between my computer and the router are all over the place, so are the pings to the outside, and this also shows up in the speedtest results.
Just looked (ping -t) and ping times to the outside world are quite stable. I don't know why you're seeing longer or random ping times to the outside world when your ping times from your computers to the router are stable.
What are they to the outside world?
And while I certainly can be mistaken CTF has nothing to do with clients to the router. It has to do with WAN traffic through the router. Which would impact pings through the router to "out there" some where.
Ping time to google is about 17ms, yahoo is about 94ms, my ISP (comcast) is about 43ms. These are about par for the course from my place. Little variance between ping times to the same place a couple ms. up, a couple of ms down, not random like the ping times between my computer and the router before I get that one stablized.
I don't know what CTF has to do with it, either. Shouldn't have to have CTF on to have stable pings. Be nice to understand what's going on there *smile*.
You are probably experiencing something different than other people then. If your pings are stable to the router, then it is something between you and what you are pinging... I've had those kinds of issues before and most likely it has nothing to do with your router and the reboots you do. A perfect example of that is two nights in a row, I had connections start to act up and drop. Teamspeak was not stable at all and even trying to load google was spotty.. I did a pathping to a few different sites and every single time a hop on Comcast's network in chicago was dropping at least 50% of the packets and the ones that were not dropped had very high latency. This was happening every single night between 9pm and 10pm eastern.. I finally took quite a few screen shots and posted on their forum and within a couple days it stopped happening.
Next time you see the issue, you should try to use pathping and see what you find out with that. Here are some good instructions and a description.
"Be nice to understand what's going on there"
Yep. And without some kind of information/insight I'm not going to jump back and forth between DD-WRT and Shibby. There is some kind of issue with pings. For it to be resolved means it had to be identified and addressed. Just asking for some information on what was the cause and what was the fix.
"Little variance between ping times"
The ping fluctuation for "out there" shows up when pinging the same site for several pings. Not when pinging different sites for a few pings.
@shibby20, I still can't make my ipv6 working...
After many researches, I found that the main problem is that brouting is not compiled properly in the past releases.
I found it... here
I got exactly the same problem but don't know ho to compile and if arm sources are available...
Thank you for your help
Is there any ETA to support Ralink/Mediatek ARM processors as well in the future? I'm sure you guys are aware of Padavan's fw ; I realize that Tomato is Broadcom mainly however with the migration to ARM I'm wondering whether the internals (such as moving to Ralink) could be easily ported over.
First off, I made sure that the ping times that I tested were run more than 30 times each. That's what I meant by "ping -t" being used. The times I gave were the "average" times, and as I said, little variance over the full test.
Tried pingtest.net just for yucks, not an extensive test and does require java. I've installed and removed java just to run that test. For packet loss, ping time, and jitter, the test gave my connection an "A" all 3 times that I ran it. Probably doesn't mean much, but not bad as a quick test.
I'm not saying that tomatoARM is perfect and complete, it took me at least 30 minutes of rebooting to stabilize the ping times between my computer and router, which was not fun. And there's missing functionality. But the core functionality that I use is there. And it has been up about 2 days now, which isn't long term, but it is a start.
Thanks for the additional information. With Netgear's and DD-WRT there is no rebooting to normalize client to router pings. Not saying which is right or wrong, not looking for perfect. There is something different with Shibby's and this ping thing is a symptom. The lagging and stalling during web access that I experienced is consistent, the dots connect, with the symptom and the ping issue.
When discussed previously the comment was made Shibby had figured out what was causing it. Apparently that is not the case.
I would actually prefer a tomato variant because it is easier to setup several things. But as a higher priority I prefer stable pings and no stalls/lags.
I'll be sticking with DD-WRT for awhile.
Found that PPTP VPN is no longer working. It would be useful if anyone else can confirm this (Shibby v121).
Also I am curious when the LED's will be solved including an option to turn them off, and if there is a plan to include temperature display within the web interface.
im not sure why people are bringing up known issues repeatedly (ie. led lights, ping times etc.) firmware for arm has only been out for a little over a month, and should be considered beta and not what you would consider a "daily driver" ... if you need a smooth hassle free network look elsewhere right now. Tomato is close but not there yet. The people dedicating their free time to provide people with optimal software like tomato have lives, and are doing this for near nothing in donations. I for one am excited at the transformation 121 has brought to arm platform but I never expected it to be perfect.
I think people are being way too demanding. Bringing up constructive feedback is ok, but bashing the firmware and stating "im going back to dd-wrt or netgear firmware blablabla"... we could all do without that. You know what your getting into when you install an alternate firmware from oem and especially for a new architecture. I am keeping tabs on this thread but I feel like its a broken record and is frustrating me, let alone the VERY FEW people who are actually working hard in their free time to bring a free open sourced operable firmware to you, the public.
Before stating the obvious, read through the thread and notice the problems have been reported multiple times and shibby has chimed in and answered most of the questions or responded to most of the problems already and is well aware of them. Its sad how unappreciative some of you are. Its clear half of you haven't read any of the last few pages of this thread because the same questions and concerns are coming up repeatedly. If its constructive and will help the project move forward than please do chime in on your findings, otherwise just don't say anything at all. I'll end my rant here.
I'm with you 2000%. Been on 121 since it came out and although there may be some minor issues, the firmware functions flawlessly for standard and advanced usage and it is infinitely more flexible than OFW and definitely easier to use than DD-WRT. Folks shouldn't complain - they are lucky to have Shibby and others donating their time to produce something so remarkable - thank you!!!!!
You mean to say we shouldn't report on going issues because it bothers the both of you?
The very point of this forum is we bang on the firmware and report our findings.
Not really ...... It means we need to report issues and be critical but appreciative.
You guy's need to relax a bit, if you can't deal with people posting about bugs. Then you need to take a step back. As mention above, these threads are for reporting bugs, and so what if the same bug is reported every firmware release. We are here to let the Dev's like Shibby, Vic's, and Roadkill know about issue's we are seeing within the ARM build's.
Btw I wouldn't say the current ARM build's are better then what's available from Netgear/DD WRT right now. As to me, and alot of others, steady router ping times are very important. So I think it's best for everyone to report there finding's, and I will continue doing so myself. As I have told the Tomato ARM Dev's more then a couple times, how much I appreciate the time and effort they are putting into the ARM build's.
I've seen very few unappreciative, disrespectful, or rude posts. Folks are taking the time to flash Tomato and tweak and reboot in hopes of it working for them. Mentioning another firmware is working better for them is not an insult to Tomato or the devs.
Sure it would be nice if new users reviewed the threads a little more, but honestly I'd rather see a problem over-reported than not enough. It's the only way to know if an issue is isolated and what is impacting the most users.
Shibby thought he may have fixed the ping issue, that (apparently) is not the case. He needs the feedback on the ping issue and any other issue.
As for the truly inappropriate posts, some of that is going to happen no matter what, I'm sure Shibby and Victek are tough enough to handle it.
Just managed to fix PPTP VPN issue by resetting router config (found it as a solution on older TomatoUSB versions) and reconfigured all the settings (saving config / restore config is still not working).
I wanted to say that I check this forum every day since I found it (it was the reason I bought R7000).
Regarding "the features" I have asked:
- LED's - this is because Victek implemented it for R7000 in his release
- CPU temperature - because the command "cat /proc/dmu/temperature" displays it from putty and because my router, when I bought it, had the heatsink disconnected from the CPU and I had a temp of 80 (this was displayed in ddwrt) until I fixed it by disassembling.
@ak907 - TomatoUSB for ARM much older than a month and my opinion is that it's way beyond Beta (it's more usable than ddwrt and netgear firmware)
Also I would like to thank again the developers that made this possible and I really hope my comments are not disrespectful for them. I would like to see more posts with issues/fixes/ideas for tomatousb than long debates about "freedom of speech" and "stating the obvious"
It would be cool, if we had a list of the known issues working (not resolved, but being worked), known issues parked (not resolved, not being worked), resolved issues (usually covered in change log), recurrent issues (thought to be resolved, but back like a zombie), future features working (being worked), and wish list (future feature, not being worked). Of course for Victek and Shibby firmwares. The features I would like to know about are: Ping issue, Save/restore, wireless performance. This might solve people having the same issues.
Is this the current status?
S/R: Not Working
Ping: Possibly resolved, not 100% stable
Wireless: On par with Stock
IPV6: Firewall Script required
Wireless: Below stock (still very good)
Thank you to all that are working on this firmware, thank you to all of those that test, and report back their findings.
Firewall script is needed for Victek as well
I don't find the ping stablized when I first configure a version for either Victek or Shibby. And if I have to reboot the router with either one, whether the ping will stay stable or not is a crapshoot. Not complaining, mind you *smile*, I'm using Shibby v121 now and it's working well, but that's what I see here.
I also see the wireless strength with Shibby as slightly lower than dd-wrt or stock firmware, but the throughput is as good, so it doesn't matter.
Nice update, thanks.
Could I just remind users to please adhere to the forum rules.
How is it going with 121 now that you are a few days in?
Still fine. I have to go away for 3 weeks in a few days, though, and we'll have people at the house taking care of things that will be using the WiFi. Since I'll be largely inaccessible, I have to figure out what's the most reliable firmware to use while we're gone, guest network is important also. I've added a guest network to v121, and no problems with that. However, I'm contemplating going to the Netgear stock debug firmware that was working fine for me recently while I'm gone, since I'm just looking for reliability then. When I get back from that trip, then, would go back to the latest version of tomato.
Thanks for asking, by the way *smile*.
Thanks. I'm having a hard time giving it a go this time around since Kong's DD-WRT working so well. I might not be able to resist the curiosity factor though.
Yeah, that's a lot of what gets me to try new releases *smile*, I'm curious about how it'll work for me, once I hear a few "it seems to work"'s coming from other people.
Not sure what's going on with dd-wrt for the R7000 now that the main thread has been closed...haven't seen anything from Kong on plans for the future, and the IPv6 thread seems to have died midstream, so I'm wondering if Kong's still working with the R7000, or if he's switched to focusing on newer products, or what. He has started forum threads for special releases for his versions, like 24500M where there was a shift in build environment. Anyways, been looking for news, nothing that I can find. Other than people asking questions, being answered by everyone except Kong *smile*.
The thread was closed by the forum moderator due to it getting too long is all. Kong and Brainslayer are redoing some aspect of the core of 24500 as it has "issues" which were the cause of random reboots. Whatever it was has been identified and is being addressed. CTF is also being ironed out and implemented. AND a new driver is due any day now from Broadcom so I think they are waiting for it.
DD-WRT for the R7000 is alive and well.
I went back to the release just before 24500 but haven't bothered to update my signature lines.
I applied Shibby 121 last evening, after reading initial feedback here. So far it seems to be behaving at least as well as 118. A few thoughts/questions:
To save myself time upgrading, I did not wipe NVRAM. Is it OK to "restore" config through web UI after? Or does that just restore the NVRAM image? If so and that's not advised, any way to get it to dump out config commands that could be executed in ssh session after wipe (such as Download NVRAM dump in Debugging)? At least then I could limit what gets reconfigured to just the stuff I need without worrying about newer defaults for new drivers being overwritten.
I've altered WiFi region to US and transmit power to 0. I generally notice similar reception as before, but in some spots where I was previously able to /maintain/ connections, they seem a little more dicey now. I suppose I could try manual transmit power settings, but wanted to confirm that using US region is safe/desired now.
I notice many comments about bandwidth monitoring and QoS working now. I'm not seeing this, but I do still have CTF enabled. Previously, I understood this was important to get better throughput... at the cost of tomato not being able to observe traffic. Is CTF really essential still? I'll test some with it tonight, but curious about others' experience with this.
CTF is essential if you have a very fast very broadband internet connection. Emphasis on essential. For the average internet connection I'd say essential is not applicable. Nice? Sure. Test faster for throughput? Yep. Essential? Not really for the typical internet connection. I'm on Cox cable and I'm nowhere near needing CTF so as to benefit from my kind of connectivity.
I believe that the change log says that the wireless drivers were updated, I think that's what "ET driver updated" means. Because of that I'd reset to factory defaults, and re-enter my configuration settings manually.
I don't believe that restoring saved configuration works, but even if it did, if some modules that may require different defaults settings have been changed, then you can't rely on an old saved settings file from a previous firmware version. You've mentioned that, but I'm not aware of a way to get around the problem at the moment. You could probably script restoring just your important settings that are common to all firmware versions via telnet, but I haven't done that myself yet with tomato.
Doing the reset to factory defaults and re-entering your configuration settings manually may fix your wireless outages, that remains to be seen. But yes, I'd leave the locale set to US and the tx power setting at "0" when you do the reset and so on until you see where you stand.
I am the opposite! I would try DD-WRT out for a while if IPv6 worked.
Hello, I'm a first time post in here, if any problems with my post, pls tell me.
I'm using RT-AC56U
Few hours ago I tired to update Tomato firmware from 120 to 121. There is no problem when updating.
And because some settings may cause some problems, so I erased NVRAM while updating.
After update, I set my WAN and LAN setting up (not using backup, just manual.). And router still fine.
BUT after about 5 minutes, all PCs can't connect to Internet.
I tried to log in tomato web configuration, but I can't log in, too.
I tried reboot AC56U, still got a same problem.
So I changed PC's IP to the same network (i.e 192.168.1.5x). Now I can log in into web setting but still can't get any Internet.
Maybe the DHCP got some problems and it crashed on AC56U.
After downgrade back to v.120, everything turns back to normal again.
Is anyone got a same problem when updated to v.121 with AC56U?
And also, because tomato not have 802.11ac yet (as I saw on 5GHz settings).
Will it support 802.11ac in the future?
I never set wireless-AC directly, but did set 80MHz channel width, which is wireless-AC. There's no other use for an 80MHz channel width. So yes, it is there and working. I get 867Mbps connect speed, wireless-AC.
Thanks for ur reply.
But according to this pic while I set 5GHz to 80MHz:
Is it normal?
I've been on 121 since the day it came out:
AC works, get 866 connectivity as well setting the width to 80
Restore defaults doesn't seem to work. Save config, erased NVRAM, restored config (a few times), nothing happened
Web log / search log - works intermittently
Pings/speed - excellent
Overall stability - excellent
I bit the bullet and went ahead and switched to 121 from dd-wrt. Wireless connectivity about the same. Don't see any different from client end. Certainly easier to setup reserved dhcp addresses.
Question about radio signal strength. With DD-WRT setting to 71 allows the driver to dynamically adjust the radio amp. I'm not sure if "hardware default setting" is the same. With Shibby's does setting the radio strength to 0 do the same as with DD-WRT and setting it to 71?
DD-WRT has more options in terms of which combination of wireless you want to use, B+G, N+G, N only, etc. But that is not really a big deal.
I don't do VPN nor IPV6.
Pings are fine. No issues for about 24 hours but that is too soon to judge stability. NO reboots however. But I didn't have them with Netgear's nor DD-WRT. Some do. I do not.
I don't see any "AC" option in the 5 ghz channel. Just A and N no matter which frequencies I select, 20/40/80.
It would be nice to have a G and N only option for 2.4ghz. I know some folks still need "B" but if we don't, would be nice to shut it off.
That is controlled by your client. It shows the connection from the client as well as the connection speed.
Well Channel width show maximun connecting speed/frequency and rate show connection speed from client.
See this youtube to obtain 80Mhz Channel width: