Discussion in 'Tomato Firmware' started by Victek, Dec 28, 2012.
any plans for a rt-n66u version ?
Sure, building with some extras
9014-v1.3c running well on an e3000 - I'll try to stress it a bit today and see how it performs. Victek, an E900 build when you get the time please.
*** my mistake -- I was testing on my e4200 -- the e3000 has not been tested/flashed yet
Boy oh boy am I behind. It's time for me to upgrade. I'm currently on shinny v110 on my n66u. I am in need of an upgrade for heart bleed fix and better wireless. 5ghz requires a restart lately at least everyday.
If wireless performance is my main driver is Victek the way to go?
Been a long time since I've been around here!
I sent a PM to you for testing this version since I don't have unit to test.. well.. yes but died. Please feedback and then I'll put visible in the download area.
@ladysman ... pls wait for feedback, if OK you can try.
@dc361, sure, I'll do.
I just flashed "tomato-RT-N66-1.28.9014MIPSR2-RAF-v1.3c" it seems to be running well so far ..
But I noticed that I have a 32 kb NVRAM with this build on my rt-n66 ..
Thanks for the support and I just wanted to give my feedback.
Thank you, it's what I was wondering can occur, I'll adjust settings for next compilation. Anybody else can confirm it?
tomato-RT-N66-1.28.9014MPISR2-RAF-v1.3c is running well here. I can confirm that NVRAM is only 32KB
Thanks, can you live with it or do you need fix version?
I can confirm the 32KB NVRAM too. I didn't notice the problem until I put in my settings (more Static DHCP, port forwarding, Open VPN server) that causes it running out of NVRAM and everything go crazy. I reset back to default and have to wait for the new build.
Here is my NVRAM usage
NVRAM Size / Free 32.00 KB / 6668 (20.35%)
This RT-N66U is only routing packets and the setup is very basic. No wireless just a router.
32KB works for me in this situation but you may need input from someone who is using many more features.
Hi, my fully configured router also needs more than 32KB of NVRAM
Total / Free NVRAM: 64.00 KB / 27.82 KB (43.46%)
Does this NVRAM Size issue effect the E4200 as well? Or just the N66? I have not flashed to the new version just yet for my E4200.
I'd prefer 64KB NVRAM on my RT-N66U, but I'd be able to just squeak by with 32KB. I'm currently running Shibby's tomato-K26USB-1.28.RT-N5x-MIPSR2-117-AIO-64K, but I'd like to compare to Victek's (and Toastman's) versions when I have time.
What hardware version do you have on your e3000 ? 9014-v1.3c sent my (ver. 1) unit into a continuous boot-loop. I had to tftp back to stock firmware to get it back.
@Victek My EA6500 is getting hungry for Tomato(s) ;-)
I have not tried it but the E4200v1 uses a 60KB NVRAM and has always been that way. When the RT-N66U first came out Asus used a 32KB NVRAM which worked with there firmware but made it difficult for third parties. A 64KB flash chip always came with it so ASUS upgraded there software to address all the 64KB NVRAM. Its unique to the RT-N66U.
Only Rt-N66, you can check nvram in Status Menu.. no problem.
I sent a test version to one beta tester to confirm it's solved .. wait few minutes.. he will confirm.
About E3000, pls erase nvram always, it works stable in my test unit. I think shibby released on version for EA6500... you can test.
As soon it will be tested by the beta tester it will be public release.. no problem.
Just tested "tomato-RT-N66-1.28.9014MIPSR2-RAF-v1.3c_1.trx" and now I have 64 NVRAM ..
thanks Victek ..
Thanks... I'll make it visible in the download page.
I can confirm that the new version is now 64KB NVRAM
My mistake -- I was testing on the E4200 and had the 3000 lined up to test this evening. Looks like I may want to delay that. Thanks
Yeah, I have an E3000 which is a converted WRT610, and based on the above, I'll also wait for a second brave sole to report back before blowing up the router and getting an earful...
Just installed a few minutes ago! Went smooth. Cleared NVRAM (thorough) first. The flash itself took about 2 minutes. Got kinda worried since usually it only takes a minute. But, I understand big changes from last version. I also made sure to check the little box that says clear NVRAM after flash.
OK I have an E4200 as my main router...flashed 1.3c and so far am having no problems. I also have an ASUS RT-AC66R that I primarily use as an access point...flashed 1.3c and could never get the 5GHz channel to show despite trying Shibby's fix at least 5 times. Reverted to ASUSWRT-Merlin 374.41. Finally, I have a WRT1600AC as a repeater bridge (just waiting for the first true opensource firmware).
Vic, went ahead and loaded the latest _1 version mention above. I'll report back if I have wireless issues.
For reference, I think i win for the oldest version used. It's dated 9/2012...lol
Been solid but i've had 5ghz wireless issues as of the last couple of months.
Another release coming? I just flashed to c.
Release 9014-v1.3d (wip started April 23,2014)
_ SQlite: Updated to version 184.108.40.206
@Victek , and e3000 owners..
Ok, so I stayed up late so as not to interrupt the family, and tried upgrading my E3000 (converted from WRT610) from 1.2x to 1.3c. And thank God I did wait for everyone to be asleep!
Through reset BEFORE flash, reboot. Flash using "reset defaults"
After successful flash, the router entered the aforementioned reboot loop!
A few things (some strange to me) that I observed:
1) The only way to kick it out of the reboot loop was to flash via TFTP a mini dd-wrt build I had on my PC. Believe it or not however, after the restart (following the "mini" flash), and waiting a minute, TOMATO v1.3c comes up (and not dd-wrt)... WTF?
2) With 1.3c "booted", I reflashed (from web page) 1.3c again, and it entered into the reboot cycle again! (flash dd-wrt to bring it back)
3) I'm 99% sure of this step, but it's late and I wasn't taking notes... With 1.3c loaded, I did a "Thorough NVRAM Clean" and reboot cycles again! Same "dd-wrt" flash to bring it back...
At this point, I have 1.3c on the router, so I'll leave it on for the day tomorrow to see if it stays up / how it behaves... But I wouldn't recommend this build (1.3c) for E3000 users out there.
I'm not quite sure if an NVRAM value is missing after initial flash/thorough clean, or if the boot is somehow broken, but my dd-wrt flash brings it back (and why Tomato loads afterwards and not dd-wrt)...
EDIT TO ADD: Once it's up, restarting the router results in a noal reboot. Seems it's only the initial flash/reset that's bad.
im trying to add a vlan on my ac5u/fw-1.3b like say vlan 3 and add port 4 on that vlan, bridging to br1 is greyed out or disabled, router displays a reboot dialog box to complete the process and clicked ok, now the problem is after rebooting i cannot access the router, everything seems dead, i have to nvram reset the router to be able to access it again. it happened to me multiple times already.
please disregard this issue, it was my mistake plugging wrong cable on the vlan port
I flashed 1.3c N53 on my Asus rt-n53u A1.
I had since then a couple of kernel panicks, I assume, which caused a reboot, after which the 5Ghz USB interface never came up, so I hage to perform a new "clean" reboot to have both wifis up and running.
This is the same issue i kept getting with shibby builds.
I will put a logging interface on the serial output to be sure what actually happens.
BTW, is there any known method to redirect all logs to the serial tty output, so i'll have all the logs in one place?
Edit: Ok I think I figured out how to redirect the log to the serial, I'll just add the custom log path on the web ui to the ttys0 or ttys1, which ever is actually reachable at the board pcb.
Thanks for the detailed explanation, the origin of the strange behavior it's in the new wireless drivers, I know it may happen but these driver solved disconnect issues with this model, so, please once flashed do a new reset in the unit and it should work normally and better than before.
I know long nights waiting family to be asleep to do tests .... and avoid riots of claims LOL!
Victek - I am not sure but could you check minidlna in your build? Shiby did some changes in his latest build.
I flashed your new build on my all devices thank you
OK i found my 80-85Mbit WALL... gues what.... the ISP who said ALL OK ...now say that my Modem Parameters are not ok *angry*
Hopefully they could fix it.
Next test hopefully with 100/10Mbit
Further to my post of yesterday...
I did do the "nvram erase" through the terminal. Also during the boot (s), the router was complaining that some drivers (wifi ?) were "Proprietary" and that they had "tainted the kernel".
I don't know if that helps.
Is there going to be a version Ε2000?
Good communication from your ISP, they recognized something is wrong, congrats and let's see next Tomato hit when modem issue will be fixed.
Tomato (unfortunately) use Propietary drivers because we can't access source code from manufacturers, that's all we can do till now.
@Spyros , sure, I'll do in coming days before trash all versions with Heartbleed bug out in the download area.
Just to add to @pena1348's note (and re-point my own), I also on my E3000 performed a reset of the NVRAM both before (with 1.2x still loaded, reset, reboot) and "during" flash of 1.3c - as part of the upgrade.
The part that also is 'surprising' is that AFTER getting out of the reboot-loop and 1.3c GUI came up, I did a "Through NVRAM Reset" at which point the router again entered the reboot-loop.
I absolutely don't question @Victek or @koitsu , however if the post 1.3c flash (meaning once it's up) "thorough NVRAM reset" causes a reboot loop, there's going to be a lot of "normal" users freaking out...
@pena1348 it seems like you're also now finally on 1.3c. Have you tried (with 1.3c GUI loaded) performing a "thorough NVRAM rest" in the admin GUI page? Curious if you'll experience the reboot-loop again after doing that...
It will be interesting to verify this point... if E3000 refuses the new wireless driver (I'll be pity) rollback to the old driver again... all models I tested (6 models) are fine and no issues with this driver.
OK forget about my ramblings from earlier today. I decided to give my E3000 another try. I got back to the same boot loop again, but instead of powering off in the middle of it; I broke the boot with a Control-C; got a CFE> prompt and then cycled power. After that it came up clean. Thanks Vic.
Been running Tomato RAF Firmware v1.28.9014 MIPSR2-RAF-v1.3c_1 K26 USB on my RT-N66U for just over 15 hours now and I'm quite happy with it. Seems stable and responsive. No issues. I think I'll stick with this fw for a while.
@pena1348 now that you're in 1.3c, can you try a "Thorough NVRAM Reset" and let us know if it causes the reboot-loop?
@Edrikk - Thanks for taking on the chin for us. I am a bit luckier in that my e3000 is a 'test' router so I could experience the update and ensuing events in the light of day with a good cup of coffee.
Updated from e3000 9013v1.2x to 9014v1.3c after resetting to defaults (thorough) and then selecting the reset to defaults checkbox.
After the update completed, the device entered a reboot loop as noted by watching all the LEDs cycle then settle then cycle etc. I tried SSH'ing to the router and telnet with no luck. I tried a multi-second reset button press, power down and reboot with no luck.
I also had a dd-wrt e3000 mini build so I set my ip to static (192.168.1.5/24 with a gateway of 192.168.1.1) and proceeded to tftp the image. The tftp reported success, so I let the router sit for 15 minutes with just the power and lan port light blinking. I power cycled the router and away it went into the reboot loop.
The next step was to try factory firmware, but I discovered that Linksys is only providing their ciscoconnect executable for the E3000 so I downloaded that and gave it a try. Bingo! As soon as the program started to show progress on the status bar I noticed the wifi light pop on -- I then was able to access the router via a web browser and found that it was running the 9014v1.3c software. I stopped the ciscoconnect software and power cycled the router and was delighted when it went through a normal boot.
I configured a few things, checked a number of the menus and then decided that a thorough nvram erase might be in order. I selected the proper option from the ADMINISTRATION->Configuration page and clicked save. A minute later I noticed the router starting to reboot-cycle.
I repeated the cisco connect 'fix' and when I was able to connect to the router again, I started a telnet session and performed an nvram erase from the command prompt. This seemed to work fine as I have since reconfigured the router and power cycled a few times to test.
@dc361 great stuff! You basically confirmed all my findings...
1) After a successful flash of dd-wrt/linksys from tftp, for whatever reason 1.3c (surprise) boots (successfully at that).
2) After things are up and solid, a "thorough nvram erase" from GUI throws the unit back into the reboot cycle.
My initial thought would be on "thorough reset" kills an nvram variable that's critical, but then, why does a dd-wrt/linksys flash cause the booting to be successful? (And why is the flash "not really" taken, and Tomato 1.3c shows up)?
Unless there are two different issues here... Possibly somewhat related..
This sounds bad and should be pulled? Many with not to much technical skill will think its bricked. And I would imagine would be pretty upset. If Victek did not see this with his test unit. Something to do with different hardware revisions?
My test E3000 is a 'true' e3000 with no version (therefore V1) after the model name on the label. I have one that I converted from a wrt-610v2 but it is not easily accessed.
@Edrikk - only difference here was that flashing dd-wrt e3000 mini (dd-wrt.v24-23919_NEWD-2_K2.6_mini-e3000) did not recover the unit. I had to use the ciscoconnect program.
@Victek -- now that we are 'warmed up' .. how about that E900 build ?
I'm using a wrt610v2 converted to an E3000 which for all intents and purposes is identical to an E3000 v1.
No (reboot) issues here running FW version tomato-E4200USB-NVRAM60K-1.28.9014MIPSR2-RAF-v1.3c
I was able to reproduce the E3000 rebooting issue on a spare E3000 (no version) router.
This is with the tomato-E3000USB-NVRAM60K-1.28.9014MIPSR2-RAF-v1.3c.bin
During the update, I checked the "After flashing, erase all data in NVRAM memory" box.
After the update, the router went into a reboot loop and wouldn't come up.
After several power cycles, it did successfully boot. It seemed to help to ping the router during the boot, but that could have been a coincidence. This was somewhat repeatable -- most power-ons would result in a boot loop, but sometimes it would successfully boot, particularly if I was pinging during the boot.
After it booted, I telneted to the router and did an "nvram erase ; nvram commit" and it seems to be working normally now.
After that, I used the GUI thorough reset option, and it went back to the reboot loop.
This supports the theory that the GUI erase is writing some garbage to nvram.
FWIW, I've already updated several RT-N66U with 1.3c_1 and RT-N16 with 1.3c with no issues.
That's a good definition, I'll rollback wireless drivers to old version only for this model.. pity. These drivers are the same used in E4200,RT-N16,RT-N66,E3200 ... pity.
@dc361, E900 will be cooked this weekend .. my doubt is.. new wireless driver or not? , we'll test before with latest and let's see.
Out of curiosity Victek, if it's the drivers, why would ONLY "thorough nvram erase" cause the issue? And based on the last post from @ntest7 doing it from the shell prompt was ok, but from GUI it causes the behavior...
For me, it's been rock solid once it got up...
Just asking in case the root cause is there, and it's something there that can 'save' the new drivers for E3000...
There is a difference between soft reset (gui) and hard reset, the first restores all values by the firmware into nvram table while the second wipes completely the nvram partition and creates a new one. This is the reason why sometimes 'nvram erase" is used when we merged cross firmwares (openwrt,dd-wrt,asus,tomato...).
I would go along with Edrikk. I looked back at my logs and the kernel taint issue had nothing to do with the wireless drivers. IMO leave the new wireless drivers and look somewhere else. My E3000 has been solid after it booted properly.
... source code is exactly the same for all models.. only wl driver changed.
1.3c_1 runs fine for 2 days on rt-n66u ... but does nothing special .. only routing one subnet
did u read the fpu softfloat thing ?!
can u make a "soft float" version (exept kernel and broadcoms binary blob)? ...... it would be interesting if and how much it performs better
Great! I have an e900 with the top cover off and a serial port so should be ready for any issues.
Perhaps we should find a 'suggested path' for the upgrade because the e3000 is running very well here with the new firmware.
Updated two E3000 with 1.3c leaving "After flashing, erase all data in NVRAM" unchecked. After flashing one was reset by telnet and the other one oldfashioned by 30/30/30. Both came up as they were supposed to and keep behaving perfectly well.
Many tks + kind rgds
Hey Vic ! On an unrelated note... How about sending this thread out to pasture and starting a new one ?
Maybe ----> Tomato RAF 1.28.9014
I'm wondering if a build with the old wireless driver would still cause the boot loop? (given that as you mention there has been a lot of code unification with all the ARM activity)... It could really be that one of those doesn't sit well with the E3000.
Again, I'm speaking anecdotally, but given that based on findings from @plgvie, @dc361, etc:
1) GUI "NVRAM Thorough Erase" seems to cause reboot loop - you've noted this method restores values
2) Shell reset or 30-30-30 does not - you've noted this flow wipes completely and creates a new partition
wouldn't it makes one to believe that there is a bug in the first flow which maybe only the E3000 doesn't like? If I were a betting man, I'd bet that the new drivers aren't the issue. If I had a a free bet, I'd guess that the same reboot behavior will also be seen if the old drivers are put back (without reverting any other code), and GUI 'thorough' reset it used...
I tested one year ago floatting point (suggested by @tvlz ) as a kind of experiment (based also in OpenWRT old test and since dd-wrt changed kernel to soft-float too), didn't notice tangible improvement (in some modules yes, like encoding mediaserver) and reverted back again. The main problem is the bad perfomance of MIPS FPU emulation.... My concern was based on longterm device stability... but apparently everything was working fine. Definitively soft float will be a big help in dual core cpu's ...
I did same on previous years, 9011, 9012, 9013 and some of the answers are repeated year after year... then I prefer to stick on this thread or may be change it by Tomato RAF Releases ?? .. I'll ask internally about.... done, thanks @roadkill .. light-speed decisions in li.org ...
We'll try, I'm preparing it for you to test ....
Not a problem, I'm part of the ARM dev team and as such I have good communication with Victek so a simple change is easy
Sent from my iPhone using Tapatalk
@roadkill - if you have the ability, maybe you can also change "Tomato RAF with included BitTorrent Client - beta testing" to Shibby's Releases. The current title is misleading since it is not RAF.
Hardly waiting for RT-AC66U - Version
I sent to one beta tester.... didn't get reply yet .. do you want to test? sent me PM with your e.mail address and I'll send the test version ...
I'll do in this way for the models I can't test ...
@Goggy , confirmed, works as expected, available in the download area, you can see it's v1.3d ... some changes have been done as it's wip ... pcre updated to release 8.35, php-fastcgi working and php test page. Enjoy!
@Victec: downloaded, installed - happy
@Victec: your latest release includes the fix discussed here:
Hope the rt-n66u testing is going alright, itching to install an update.
yes .. for both combinations mips n and mips-arm ac routers is the same.
#define WLIFU_MAX_NO_BRIDGE 4
#define WLIFU_MAX_NO_BRIDGE 4
#define WLIFU_MAX_NO_WAN 2
@gffmac .. I sent to beta tester before release .. it works fine apparently.
Thanks will try the tomato-RT-N66-1.28.9014MIPSR2-RAF-v1.3c_1.trx version later on my rtn66u.
If you will use web server and php intensively wait for next release....
Nice! , I'd like to know how you did that?
If I remember correctly you said that before you could build the whole firmware - not just a few modules, the tomato toolchain had to be recompiled with -msoft-float.
Did that ever happen, maybe I just forgot the results?
a. Refining modules options for builds ...
b. Done for some modules and as said improvements was good.
Release v1.3d available.. I'll build next models based in this version, changelog can be seen in the know 'Readme before .... txt' but... as usual... pcre updated to 8.35, php-cgi with fastcgi extensions....
Vic - any chance we'll see ipset support added?
@Victek Another happy RT-AC66U user !
We, roadkill and myself are looking and doing firsts steps to another solution ... better.
I'll ask Shibby about it as he is the owner..
More info please?
Is there going to be an E2000 version with new drivers? I can test tonight if beta testers needed.
I assume NFTables.
yes, cooking but you have to test private, I'll send you the link to download and try before posting as public release.
@dc361 , I send you the link to test E900 version ...same, before it goes public release.
@jerrm ... it's a most robust and logical solution .. not?
just want to chime in.. 1.3d on E6500 here. Sirq stayed the same when torrent downloading @ 11MB/s, it's 93-98, however, the router seems to be more reponsive during that (eg browsing still works somewhat)
We have hands tied with MIPS platform and propietary Broadcom drivers... it's more responsive due to better CPU (BCM4706 at 600MHz) ... but not for a fireworks demo... What version did you flashed?
Thanks for the comment.
Is it worth updating from C to D version? Will that be it for a while or is E coming soon as well? Also if its advised to upgrade with these changes in new release. Should we still do NVRAM (thorough) erase before and after flash?
Any notes about 1.3d for E3000 other than what's in change log?
If not I'd rather not do an NVRAM reset to avoid the reboot loop...
erase nvram is not needed ... nvram values remains same, only affects to code and modules.
Answered .. when nvram erase will be needed I'll notice. Thanks
Well looks like I need to read better next time. Sorry it was already in the log notes. I have actually never updated with a live internet connection. It is wired btw the pc doing the upgrade for the router. I guess it is safe? Anyone ever run into a problem before doing it that way?
Section 1. How to install or Upgrade.
1.a) Update from previous Tomato RAF beta (1.1d or 1.1e or 1.1f-g-h-i...).
_ Do the update when your device is iddle or few Internet traffic is going throught, it may extend the Flashing time and give you some warnings (Timeout).
_ Stop (Unmount) and unplug any USB device you may have.
_ Use the Administration/Upgrade option in your router menu an then upload the file you downloaded.
Went ahead with the update using a live internet connection. It went just fine and updated. I learned a couple new things. You can do it with a live connection. And you don't have to erase NVRAM (thorough) every time when upgrading to c, d, e etc for example it seems. I would erase NVRAM every single time. Doh!
Correct. You only need to erase if you are changing from one flavour to another. If you are staying within an existing flavour then you don't need to erase at all. The only thing that is worth emphasizing is that the through erase should be done after the flash has succeeded and rebooted. Prior doesn't really matter.
And when the developer marked in the new update 'Tick erase NVRAM when flashing'
Victek, I'm not sure if anyone really knows authoritatively an answer but one thing I noticed years ago about NVRAM variables is that there is both wl and wl0 a lot of the time. Various firmwares might set only 1 but not both. One thing I always wondered to myself is, does the Broadcom driver directly read the nvram variables and get confused by the two being different? Or it is smart enough to only pay attention to 1 and the other doesn't matter?
It's defined in the initialization when the firmware reads the model from the router CFE and then assign the correct mapping for devices according to the values we wrote in the 'sniffer' daemon, switch map, interfaces; vlan, eth1, eth2, usb, led gpio, buttons ....
We need to say to the wireless driver the devices we found and according to it the driver will be initiated for each interface.
1.3d works great so far on my E4200
Has it also the fix for the openvpn 2.3.2 connection problem? Because i can connect with openvpn 2.2.2 but not with 2.3.2.
1.3d working great on rt-n66u, just curious I'm sure there was mention of a feature to backup/restore config to dropbox, cant see it anywhere.. maybe I dreamt it
i flashed the new build for E2000 and i ended having the same build you gave me to test yesterday with USB menu (no USB on E2000) and no space for JFFS. Anyway my e2k is very happy with the new drivers and sends it's greetings.
Question: is there any way to use Dropbox or Google's Drive as CIFS so i can have there my adblocking scripts or use as a save location for bandwidth monitoring etc etc ?
edit: Flashing e2k build worked without problem, thorough erase from GUI works fine without reboot loop.
No, you don't , wip.
Yes I posted the same version to homogenize builds, since E2000 have an internal USB ... may be we you can try some DIY to use, not?
About last question, wip.
@Desolator , try it.
Even if i manage to solder the usb port and punch a hole in the router i don't have a USB HDD
I'll try it next week or so, I report back here.
I have the AC66 as well, go to advance settings set the country code to EU, Save reboot, you will then see both 2.4 and 5g , go back to advance settings and set you own country code.