Disclaimer: We are not responsible for any bricked routers, nor do we encourage other people to flash alternative firmwares on their routers. Use at your own risk!

How to report a bug or problem:

As the first step in troubleshooting any issue, try to reset the router to default settings using "Erase all data in NVRAM memory (thorough)" option on the "Administration -> Configuration" page of the FreshTomato GUI. Do not restore your settings from the backup configuration file - always reconfigure the router manually when troubleshooting the problem!

Check the NVRAM usage on the Administration->Configuration page in the GUI. If the free NVRAM space is very low (or worse - 0%), you're running out of nvram space, and this is the most probable reason for the problem(s). In this case you will have to erase the nvram and reconfigure everything manually - there's no way around it. Keep an eye on the NVRAM usage while you're adding your settings.

Further troubleshooting steps may vary depending on what kind of problem you're trying to solve. Be creative, and try to do as much troubleshooting as you can think of, and collect as many details about the problem itself and your configuration as possible.

If you could not find the solution, and your own troubleshooting did not help, please follow the guidelines below to report the issue:

Always include your router make and model, and the exact version and edition of the firmware you're using - you can get it from the "About" page in the FreshTomato GUI.

Verify that there is a newer version of the firmware, and if so try to install it, reset the router to default settings, and test whether the problem is still there.

If this is a new issue, include the last version/build of the firmware that was still working properly.

Include any relevant configuration details - your wan/lan/wireless/usb/etc settings, WAN connection type, configuration of the clients etc - anything that you believe might be useful. If there are working and non-working configurations, please provide the details about both. If you're in doubt what's relevant - submit at least the output of "sysinfo" and "nvram show" commands (remember to mask out any personal information - passwords, MAC addresses etc). The output could be too big for the forum post - use pastebin.com (preferred) or any free file sharing sites to submit this info.

Describe your problem in details - what exactly you're trying to do, the expected results, the observed behavior, and steps to reproduce.

Describe what exactly you did to try troubleshooting the problem, and your results.

If at all possible, test whether the same problem exists in other firmwares available for your router.

If after the bug report you're asked additional questions, or asked to do more troubleshooting steps, please answer each and every one of them! Even if you don't know the answer, or didn't do some of the steps suggested - mention this in your reply.

Be courteous to developers and other people who are trying to help you, and don't make them to do any guesswork - volunteer the information!

Thank you all for understanding and your cooperation in making this firmware better!

It appears both MIPSR1 and MIPSR2 are supported. Please see https://bitbucket.org/pedro311/freshtomato-mips file README.md (or at the bottom of the page), text starting with "For the following MIPS routers". The RT-N16 is listed, which is MIPSR2. Likewise, WRT54 series consists mainly of MIPSR1, and its listed as well.

README.md should really say "For the following MIPSR1 and MIPSR2 routers".

Well RT-N16 is MIPSR2, so maybe they just haven't built all the firmwares yet? It can take a VERY long time considering all the variances. Just look at Toastman's directories sometimes, esp. the older ND (MIPSR1) and RT (MIPSR2) and RT-N (MIPSR2) dirs -- packed full. Gotta do a complete fresh rebuild for each and every one of those. I wouldn't be surprised if doing all the variances took literally a few days.

Even after flushing the NVRAM, the smallest sized E2000 freshtomato firmware build 'freshtomato-E2000USB-NVRAM60K_RT-N5x-MIPSR2-2018.1.066-beta-VPN.bin' fails to flash up from Shibby's build tomato-E2000-NVRAM60K-1.28.RT-MIPSR2-140-IPv6-VPN.bin with the following message:

The firmware file size difference between the E2000 Shibby build and the smallest two E2000 freshtomato builds shown above is too big!?

I've installed the freshtomato-F7D4302_RT-N5x-MIPSR2-2018.1.066-beta-Mini.bin, using the belkin ofw gui, I suppose I didn't have to as to using the cfe or tomato gui. I won't be able to do any testing as of yet, I'm running Andre's build for netgear r6300v2 as he had done recently for qos and bwl issues, but I should be able to connect it to my network tomorrow as gateway, ap, routing, qos, bwl. I don't have vpn or anything to intense on my network. I for one do like mini builds, i'm pretty sure everyone has their own preference although I would like to see some in circulation. (My thoughts)

I've installed the freshtomato-F7D4302_RT-N5x-MIPSR2-2018.1.066-beta-Mini.bin, using the belkin ofw gui, I suppose I didn't have to as to using the cfe or tomato gui. I won't be able to do any testing as of yet, I'm running Andre's build for netgear r6300v2 as he had done recently for qos and bwl issues, but I should be able to connect it to my network tomorrow as gateway, ap, routing, qos, bwl. I don't have vpn or anything to intense on my network. I for one do like mini builds, i'm pretty sure everyone has their own preference although I would like to see some in circulation. (My thoughts)

Click to expand...

I did some reasonable test but since it's not able to handle my current bandwidth, i was unable to fully do some testing using Qos, however wifi was very responsive using some default settings and for the 2.4, changing transmit pwr as me 28, apsd mode to enable, interference mitigation to wlan auto and noise reduction, i had pretty decent performance after switching channels. 5ghz settings were of the same except for interference mode I used wlan manual. Performance was great for the belkin, no issues on initial setting up and typical web browsing. Unfortunately my belkin doesn't have gigabit ports and more effective cpu, however if users are using bandwidth that is under 75/75 and lower this router would do the job except maybe using vpn with it but I don't have vpn to test it that either.

Even after flushing the NVRAM, the smallest sized E2000 freshtomato firmware build 'freshtomato-E2000USB-NVRAM60K_RT-N5x-MIPSR2-2018.1.066-beta-VPN.bin' fails to flash up from Shibby's build tomato-E2000-NVRAM60K-1.28.RT-MIPSR2-140-IPv6-VPN.bin with the following message:

The firmware file size difference between the E2000 Shibby build and the smallest two E2000 freshtomato builds shown above is too big!?

Click to expand...

You compare different versions: my beta with USB support (branch K26RT-N) and Shibby version without it (branch RT).
Check "K26" sub-folder for that one you need.

Will bcm_nat be included for K26RT-N, remember when shibby introduced it a few yrs back as I'm unsure if had been til now? I have a E3200 to install some of your updates and the question reflects to the K26RT-N, however it isn't a deal breaker, but congratulations on pushing out the MIPS. Happy Sunday to ya, pedro regards txnative

No problems using FreshTomato Firmware 2018.1.066 MIPSR2-beta K26 USB AIO-64K on a RT-N66U.
Thanks Pedro311, Kille72 and other devs involved in the project.

Click to expand...

Do the Bandwidth and IP Traffic graphs work for you? I've tried the freshtomato-RT-N66U_RT-AC6x-2018.1.066-beta-AIO-64K and VPN versions, as well as freshtomato-K26USB_RT-N5x-MIPSR2-2018.1.066-beta-AIO-64K. The graph area is mostly blank, as can be seen in the screenshot. I've tried a number of different browsers, a different computer, and yes, I cleared the browser caches.

Attached Files:

Hi, thank you for trying to build for Belkin F9K1102. Unfortunately, when trying to flash, I get an error "File is too big to fit in MTD". According to wikidevi for Belkin_F9K1102_v1, the proper mtd sizes are:

Hi - thank you for your work on the mips-branch. Flashed an WRT54G v2 and ... its working
Booting after flash or clearing nvram takes a lot longer - thought i bricked it after the initial flash ...
Is it possible that at least some of the builds are named wrong? Tried "freshtomato-K26_RT-MIPSR1-2018.1.066-beta-Mini.zip" (3,8mb) first but it doesnt fit in flash. "freshtomato-K26_RT-MIPSR1-2018.1.066-beta-MiniIPv6.zip" is smaller (3,5mb) and this one worked.

I tried out the 2018.1.066-beta on my Asus RT-N66U and reverted to Shibby 1.28.0000 MIPSR2-140 K26 USB AIO-64K when I found that IPv6 was not working for devices on my network. The router itself got an IPv6 address and could connect to IPv6 services from the shell on the router but all my network devices lost IPv6 connectivity.

I haven't tried building MIPS, only ARM, which does not contain the exact identical versions of software as MIPS. I didn't run into any complications with libogg, but it was ARM and a different version (2018.2; the date matters in reference to what I say below).

That looks like some uncomfortable GNU autotools/libtool problem that needs further investigation. Odds are someone needs to change some configure arguments, add some environment variables to the configure line in router/Makefile, or add some patches to configure.in/configure.ac to make libtool detection happy. It's probably a result of GNU autotools versioning differences. I sound like a broken record talking about how bad the GNU autotools/libtool are about compatibility/etc., but this may be another one of those cases. We FreeBSD people loathe the GNU autotools/libtool for this exact reason.

It looks like commit b61bfd5 (note the date) might be contributing to this, but I can't say for sure. That was from April 20th.

One thing that I do see happening: a configure script is committed to the repo, but router/Makefile is inducing autoreconf to rebuild everything. This is normally good/proper (kudos!), but it doesn't mean that the version of the GNU autotools/libtool on the system match what configure.ac, Makefile.am, or Makefile.in expect -- resulting in breakage. See my above mini-rant, as it's not without merit.

In situations like this, sometimes the stock-from-source configure script provided actually does the right thing, while rebuilding it with one's own autoconf causes problems. In other cases, the opposite is true. So in short, I don't know what the solution is aside from really digging in to configure.ac + Makefile.am + Makefile.in and see what's going on and fix it through a patch.

I looked at the libogg 1.3.3 source code: it does come with a pre-generated configure script. So, you might try hacking router/Makefile to not call autoreconf -fsi and see if that helps. You will need to try this on a fresh repo checkout (since autoconf regenerated the file), so you may need to cd ~/git/freshtomato-mips && git reset --hard && git clean -dxf to "restore" the repo back to what it was originally during the last clone/pull (use git status to verify), then modify router/Makefile and see what happens after that.

Whether or not this is the correct fix, however, is undetermined (i.e. don't just go blindly committing this if it works). It may be the result of Linux distro variance, if not building on Debian 9.x 64-bit, specifically versions or unique patches/quirks applied to autotools/libtool for that distro that others might not have.

I haven't tried building MIPS, only ARM, which does not contain the exact identical versions of software as MIPS. I didn't run into any complications with libogg, but it was ARM and a different version (2018.2; the date matters in reference to what I say below).

That looks like some uncomfortable GNU autotools/libtool problem that needs further investigation. Odds are someone needs to change some configure arguments, add some environment variables to the configure line in router/Makefile, or add some patches to configure.in/configure.ac to make libtool detection happy. It's probably a result of GNU autotools versioning differences. I sound like a broken record talking about how bad the GNU autotools/libtool are about compatibility/etc., but this may be another one of those cases. We FreeBSD people loathe the GNU autotools/libtool for this exact reason.

It looks like commit b61bfd5 (note the date) might be contributing to this, but I can't say for sure. That was from April 20th.

One thing that I do see happening: a configure script is committed to the repo, but router/Makefile is inducing autoreconf to rebuild everything. This is normally good/proper (kudos!), but it doesn't mean that the version of the GNU autotools/libtool on the system match what configure.ac, Makefile.am, or Makefile.in expect -- resulting in breakage. See my above mini-rant, as it's not without merit.

In situations like this, sometimes the stock-from-source configure script provided actually does the right thing, while rebuilding it with one's own autoconf causes problems. In other cases, the opposite is true. So in short, I don't know what the solution is aside from really digging in to configure.ac + Makefile.am + Makefile.in and see what's going on and fix it through a patch.

I looked at the libogg 1.3.3 source code: it does come with a pre-generated configure script. So, you might try hacking router/Makefile to not call autoreconf -fsi and see if that helps. You will need to try this on a fresh repo checkout (since autoconf regenerated the file), so you may need to cd ~/git/freshtomato-mips && git reset --hard && git clean -dxf to "restore" the repo back to what it was originally during the last clone/pull (use git status to verify), then modify router/Makefile and see what happens after that.

Whether or not this is the correct fix, however, is undetermined (i.e. don't just go blindly committing this if it works). It may be the result of Linux distro variance, if not building on Debian 9.x 64-bit, specifically versions or unique patches/quirks applied to autotools/libtool for that distro that others might not have.

Click to expand...

could be the automake version, which do you have looks like automake-1.15 and do you have the earlier version of 1.13 and maybe you have the later version of bison installed also?

I have installed the freshtomato-E3200USB-NVRAM32K_RT-N5x-MIPSR2-2018.1.066-beta-Mega-VPN.bin and see that the lan,wan and wifi macaddr are not the same as linksys unfortunately i didn't copy as what they were something like 00:16:B6. Qos seem to be enabled as i was able to access it and make changes without having to enabling with a check. The
5.110 RC27.20012 wl0: Jan 23 2013 14:32:57 version 5.110.27.20012 is the same as Toastman-vpn version that I have reinstalled, I had cleared nvram before and after the install. Were the wifi drivers supposed to have been KRACK fixed? Either way I'll look for the next beta test build.

I think it's much more likely it's autoconf, not automake. Really have to look closely at the output.

Click to expand...

Autoconf is certainly the one that's throwing the error. But not sure if it's a cause or a symptom. Been trying to determine at what version AM_PROG_LIBTOOL was deprecated for LT_INIT, but it seems to go back quite far.

Tried 1.13 earlier as well. Also tried a few versions of autoconf and friends.. with no luck. Packages are different in both versions and some packages all together compared to what I'm used to in ARM.

Tried 1.13 earlier as well. Also tried a few versions of autoconf and friends.. with no luck. Packages are different in both versions and some packages all together compared to what I'm used to in ARM.

Click to expand...

I was having problems as you were, what distro were you using? I was using debian 8 amd64, but since i had already have debian stretch on my notebook i was able to compile a K26USB_RT-MIPSR2-2018.1-miniVPN.trx for my F7D4302 without any issues 20mins. Jessie for some reason doesn't have a automake-1.15. It was a guessing game while i was on Jessie as I thought it was just something mixed up and make clean or make distclean wasn't catching something or wrong path, or user being tired? Packages seem to be the almost the same as for ARMs, as Koitsu stated it's in the README.md freshtomato-mips.

Welp, after adding the couple of missing packages and fetching the latest repo commits, MIPS has built successfully. Thanks @M_ars for the package info.

I was going to give it a test on my old E3000 that's been stuffed away for quite awhile. However, it appears to be pissed off about the whole replaced and stuffed away thing, as it's power light blinks and connections "refused" from web, ssh, telnet etc.

Welp, after adding the couple of missing packages and fetching the latest repo commits, MIPS has built successfully. Thanks @M_ars for the package info.

I was going to give it a test on my old E3000 that's been stuffed away for quite awhile. However, it appears to be pissed off about the whole replaced and stuffed away thing, as it's power light blinks and connections "refused" from web, ssh, telnet etc.

Welp, after adding the couple of missing packages and fetching the latest repo commits, MIPS has built successfully. Thanks @M_ars for the package info.

I was going to give it a test on my old E3000 that's been stuffed away for quite awhile. However, it appears to be pissed off about the whole replaced and stuffed away thing, as it's power light blinks and connections "refused" from web, ssh, telnet etc.

Click to expand...

Sean.. try plugging in the adapter before you plug it into the E3000. I had a couple of old linksys units that just flashed lights unless you plugged the wall adapter in first.

Sean.. try plugging in the adapter before you plug it into the E3000. I had a couple of old linksys units that just flashed lights unless you plugged the wall adapter in first.

Click to expand...

Thanks for the suggestion, but no change. I had the power toggle switch off, plugged the adapter into the wall, then the barrel jack into the router, then switched it on. Same blinky blinky. I can ping it, so something's alive. Haven't had any luck trying to catch it with a tftp flash at boot though. May have to break out the ol' USB<->Serial adapter and see what can be determined.

Hi, I have a netgear wndr4000. I was running DDWRT r35916, and wanted to see if freshtomato would work. I flashed freshtomato-K26USB_RT-MIPSR2-2018.1.066-beta-VPN.trx, and everything seems to be ok, wifi works. The only thing is under the status, it says for the model that it thinks it's a Netgear WNR3500L/U/v2. What logs do you need to identify the proper model? Thanks.

Hi, I have a netgear wndr4000. I was running DDWRT r35916, and wanted to see if freshtomato would work. I flashed freshtomato-K26USB_RT-MIPSR2-2018.1.066-beta-VPN.trx, and everything seems to be ok, wifi works. The only thing is under the status, it says for the model that it thinks it's a Netgear WNR3500L/U/v2. What logs do you need to identify the proper model? Thanks.

Click to expand...

I only see the WNR3500L/U/v2 and WNR2000 v2 listed in the code. So I'd assume the WNR4000 isn't officially support by Tomato. Or are you asking how to identify the board? If so:

Code:

nvram show | grep board

Will show you the related variables of which identify the specific board used in the router.

I only see the WNR3500L/U/v2 and WNR2000 v2 listed in the code. So I'd assume the WNR4000 isn't officially support by Tomato. Or are you asking how to identify the board? If so:

Code:

nvram show | grep board

Will show you the related variables of which identify the specific board used in the router.

Click to expand...

Thank you. Yes you're correct, it's not officially supported. The wndr4000 is supported with the generic DDWRT mips mega, so I figured I'd try out the generic Tomato and give it a go. I can always tftp back if I get a soft brick. The Tomato mega is actually too big, so I tried the next biggest fw which was the vpn. Anyhow, here are my nvram values.

Thank you. Yes you're correct, it's not officially supported. The wndr4000 is supported with the generic DDWRT mips mega, so I figured I'd try out the generic Tomato and give it a go. I can always tftp back if I get a soft brick. The Tomato mega is actually too big, so I tried the next biggest fw which was the vpn. Anyhow, here are my nvram values.

Trust me I would...
It's just I've tried the default Makefile, the modified Makefile...
Both completed compile, and yet both bricked my RT-N15U...
I'm actually confused why it completed compiling with the default, but still bricked my router...
Any experience like that..?

Thank you for the firmware and bug fix.
2018.1.066-beta RT-N NVRAM64K Max Flashed on RT-N12B1.
With manual configured (other) IPv6 it couldn't get to know the gateway sending ra and create the default routing but worked after those was added by hand.

With the same ta.key,client crt,server.crt,etc,openvpn failed to handshake with the server due to tls-crypt error.(The client daemon was started by command line and GUI of openvpn was untouched.)

I didn't like to redo all my work and flashed back to shibby as nvram was cleaned up after the power was cut suddenly.

Hi guys. I'm trying to port kernel 3.x from dd-wrt to this new fork of Tomato. Succesfully tested kernel through CFE console. But after kernel boot there are errors with nvram, which is /i guess/ not found by rc. Is there any way how to test whole firmware (trx file) right from CFE like vmlinus kernel (boot -addr=xxxx 1.1.1.1:/path/to/kernel)? When I edit & compile 'rc' there must be better way to test it in router than flashing whole firmware.

This RT-N12 is a client in dev br0 rather than the gateway of my network. I set it with static IPv6 address but it needs to get the address of the gateway by RA. It can also works without doubt if I do everything by hand, putting them in the script. Anyway it should do by itself after receiving the RA packets. I am sorry I forget to take a look at iptables before flashing it back. The gateway is always working as required so the other clients in br0 can get IPv6 prefix.

I compiled static Openvpn binary of lastest version by myself and deploys it on shibby firmware where openvpn is always being booted by my script instead of GUI and its configuration is set in file instead of nvram. So are the certificates and keys. After upgrading, I just copy all of them onto FreshTomato.
I don't love set them via GUI since it couldn't make openvpn work properly.For example, the server daemon starts prior to pppoe so that firewall would be reloaded after the server is up.(Firewall restarts as soon as wan is bought up).It is certain all will work just after openvpn server tunnel device gets up again.If sshd_key or passwd or anything about access is changed via GUI,Firewall is reloaded but any openvpn daemon,as long as started by GUI,won't restart. That means any firewall rules set by openvpn up-script would disappear.

Hi guys. I'm trying to port kernel 3.x from dd-wrt to this new fork of Tomato. Succesfully tested kernel through CFE console. But after kernel boot there are errors with nvram, which is /i guess/ not found by rc. Is there any way how to test whole firmware (trx file) right from CFE like vmlinus kernel (boot -addr=xxxx 1.1.1.1:/path/to/kernel)? When I edit & compile 'rc' there must be better way to test it in router than flashing whole firmware.

Click to expand...

I have tried to do this for quite some time on Asus routers and have never gotten it to work. Ever. The interactive CFE has usage syntaxes that don't match reality, and the behaviour also doesn't match reality. Pretty sure I found bugs as well (ex. attempting to load something off the network, the CFE would say it was trying, but packet captures on the physical switch on the other end showed literally NOTHING coming out of the device). I ended up digging through some Broadcom docs to try and figure out what's what, but there were differences there vs. the CFE in Asus as well (maybe it's just a different version vs. the document I was reading).

So unless someone like @RMerlin has some ideas, the answer is: you really do have to flash the things to test them. Time consuming and very wasteful, I know.

The CFE load command is what looks most promising, except it doesn't work. I'll explain:

Code:

SUMMARY
Load an executable file into memory without executing it
USAGE
load [-options] host:filename|dev:filename
This command loads an executable file into memory, but does not
execute it. It can be used for loading data files, overlays or
other programs needed before the 'boot' command is used. By
default, 'load' will load a raw binary at virtual address 0x20000000.
OPTIONS
-elf Load the file as an ELF executable
-srec Load the file as ASCII S-records
-raw Load the file as a raw binary
-z Load compessed file
-loader=* Specify CFE loader name
-tftp Load the file using the TFTP protocol
-fatfs Load the file from a FAT file system
-rawfs Load the file from an unformatted file system
-fs=* Specify CFE file system name
-max=* Specify the maximum number of bytes to load (raw only)
-addr=* Specify the load address (hex) (raw only)

I remember trying to get this to work so that I could potentially load a firmware off the network via TFTP and then boot it with boot (manual equivalent of PXE booting on PCs). But I could not get load to behave sanely. IIRC, the TFTP method did not work: it would claim to be doing network I/O but literally did nothing (no network traffic seen). Yet, the flash command would work just fine. More on that in a moment.

I also tried playing with -z for compression ("compessed" -- nice typo, Broadcom) and that didn't seem to work either in other regards. I think I got some other very strange error, almost implying that the CFE couldn't handle compressed data.

On the flip side, the flash command did work, except that, of course, this downloads a firmware off the network and also flashes it to flash, resulting in excess wear/tear when trying to test firmwares. Ex: flash -noheader 192.168.1.20:firmware.trx flash0 did in fact TFTP transfer the firmware and do what one would expect.

Code:

SUMMARY
Update a flash memory device
USAGE
flash [options] filename [flashdevice]
Copies data from a source file name or device to a flash memory device.
The source device can be a disk file (FAT filesystem), a remote file
(TFTP) or a flash device. The destination device may be a flash or eeprom.
If the destination device is your boot flash (usually flash0), the flash
command will restart the firmware after the flash update is complete
OPTIONS
-noerase Don't erase flash before writing
-offset=* Begin programming at this offset in the flash device
-size=* Size of source device when programming from flash to flash
-ctheader Check header of CyberTAN
-noheader Override header verification, flash binary without checking

What I took away from this experience: the CFE is likely buggy as hell. Broadcom sure releases a lot of junk. For a company that acts like such a jerk about intellectual property and has such a stronghold on the industry, their software sure is "meh".

What I took away from this experience: the CFE is likely buggy as hell. Broadcom sure releases a lot of junk. For a company that acts like such a jerk about intellectual property and has such a stronghold on the industry, their software sure is "meh".

Correct. If there was such a thing, it'd be something written by Broadcom (or potentially the device manufacturer relying on something Broadcom gave them) for that exact purpose. Just because a device contains a particular CPU architecture doesn't mean an emulator for that CPU architecture can magically emulate all the rest of the hardware, not to mention implementation quirks or variances (the device manufacturer (ex. Asus, Netgear, Tenda, Cisco/Linksys, etc.) is responsible for that).

Thanks for interesting infos. I'm digging through kernel boot procedure since yesterday and I think that there can be a way how to test eg. rc binary right from CFE. Kernel supports something like initramfs, which is cpio archive directly attached to the kernel binary. Kernel after boot extracts this attached cpio archive to ramfs/tmpfs and runs /init. More info can you see in kernels Documentation/filesystems/ramfs-rootfs-initramfs.txt.

I'm familiar with initramfs / initrd (it's been used on normal Linux distros for decades). I would be very, very surprised if this worked on embedded routers, given their lack of bootloader (CFE is not quite the same as GRUB).

I would suggest you read up on how the kernel is actually started on a Linux distro using initramfs/initrd vs. an embedded Broadcom router. On the latter, the root filesystem argument is hard-coded (IIRC) to something like /dev/mtdblockXX. Things like GRUB and what you're used to seeing on a standard Linux distro running on a PC are not involved. Take a peek at dmesg | grep -i "command line" sometime on a router vs. a normal Linux distro (and preferably a very old distro -- say from 6-7 years ago. No I'm not kidding). Here's what you'll find on routers:

On Linux distros for PCs, GRUB is used to pass these to the kernel, as well as select a list of kernels (you've probably seen this) (and that list is not "dynamically obtained": every time you make a new kernel on a Linux distro, you have to update the bootloader so that it knows of it, which also includes what LBA it starts at, etc. -- if you forget to update the bootloader, you literally brick your system from booting ). This isn't how it's done on embedded devices.

I would suggest seeing maybe how OpenWRT/LEDE does it or how DD-WRT does it. IIRC, they do it the same way as all the other embedded devices do, but I bet it depends on the router/device too. Here's an example:

It's important to understand that OpenWRT/LEDE does this VERY differently than Tomato. Notice how there's no NVRAM partition?

They use something called u-boot, which looks like it might be what you're wanting. OpenWRT's docs indicate that u-boot can actually be configured to do a TFTP transfer of a firmware on start-up, etc.. No idea if it flashes it or just loads it into memory space (I see no reason why it couldn't do the latter):

Just keep in mind that the NVRAM partition on Tomato routers is important. NVRAM on OpenWRT is avoided/left alone because they (rightfully so) prefer to leave those settings managed by the manufacturer and CFE. A good example of why they do this is is stuff like PCI configuration values used to initialise WiFi chips and so on -- something that Tomato has suffered from dealing with (people's WiFi being extremely bad on some devices turned out to be some missing or badly-set NVRAM variables, IIRC. Been a while...).

I now /a little/ about differences of booting kernel on desktop vs. embedded device. I'm not saying that there is a chance to boot whole firmware from initramfs. There isn't enough initialized memory by CFE for this, I think. From my point of view, when I have kernel with initramfs /which contains libc, libshared, libnvram and rc binary renamed/linked to /init/ kernel should be able to extract it and run. I don't need anything else for now. Only modify and test rc and reading from nvram, without needs of full reflash.

Kernel command line is not important for me at least for now. Initramfs doesn't need anything in cmd line, don't it? Just "hey kernel, you have initramfs support and cpio archive in yours binary, so do the all magic".

About NVRAM problem:
My kernel boots (over LAN by TFTP), takes everything up, mounts squashfs root from flash and runs /sbin/rc, which should init rest. Current problem is, that I don't have initialized /dev/nvram device by kernel /it should be right? at least on Tomato/, it simply doesn't exists. Kernel log says:

So they somehow emulates it? Even if I create this dev before rc calls for any nvram value by libnvram, it didn't work. So there can be some incompatibilities between Tomato and Dd-wrt. I need to dig deeper in it. That's the reason why I'm seeking for any way how to test code after kernel boots without need of flashing fw.

Statement: I now that I'm not skilled enterprise developer and have terrible writting in English. So some of my ideas can be unreal or not very well described.

Edit: I don't want to steal thread so it will be good to start a new one.

Just wanted to report that I tried out freshtomato-RT-AC66U_RT-AC6x-2018.1.066-beta-AIO-64K on my RT-AC66U last night and I had no problems getting it to flash, and then doing a 30/30/30 and then additional reboot without issue. I saw both 2.4 and 5 GHz WiFi in the router interface and I could see them when looking for available networks on my laptop and cell phone, but when I tried to connect to either band the router would reboot. I confirmed the router stayed stable if no wireless connection were attempted, but the moment I tried to connect to WiFi the router would reboot.

I had come from Merlin's firmware (i think 380.69_2 if it matters) and used the router's recovery web interface to flash freshtomato. After redownloading and reflashing and wiping nvram and doing multiple 30/30/30 resets I eventually gave up and went with advancedtomato RT-AC66U_AT-RT-AC6x-3.5-140-AIO-64K and only had to clear nvram from the web interface and reboot once to get everything working.

I'll keep an eye on this project as it seems very promising and I'd like to give it another try in the future.

I checked the changelog at the top of the post and it doesn't note anything about bcm, bcm_nat, NAT acceleration or CTF. Does this mean that FreshTomato will top out at ~120mbits downlink? I really like Tomato, but this would mean I'd cut my 400mbit downlink into a third..

This is a minor point but, upon installation, the usual update text notification informs me that v2018.2 is out, though it doesn't actually seem to be for MIPS, only for ARM. The link also leads to shibby's site, instead of e.g. to this thread.

Running FreshTomato Firmware 2018.1.066 MIPSR2-beta K26AC USB AIO-64K on my RT-N66U and I noticed the extra options that were added in the ARM build for Wireless filter lists is not present in the MIPS build. Could it be added?

Belkin Play Max / N600 HD (F7D4301/F7D8301) v1 the issue since the multiwan builds has caused the port order to be not accurate. With VLAN 201 needing to be tagged for the WAN, the router can not be used on CenturyLink.

Click to expand...

I made a updated version(4/16/2018) of the Advanced-vlan(advanced-vlan.asp.rt_) file for RT branch routers restoring VID Offset, as those routers can't add VIDs over 16 directly.

Exact same issue here when compiling for N66U AIO (r64z target). VPN target (r64e) DOES compile successfully and works fine when flashed. Using Debian 9.4 and carefully set up the environment per the readme.

The errors people are getting saying "configure: error: cannot run test program while cross compiling" in mysql are due to either:

a) botched patches in router/patches/mysql (you will see what is done to patch configure there; this looks like more GNU autotools breakage/idiocy, possibly a better solution is to regenerate configure using autoreconf? We've talked about this before, I don't feel like rehashing it), or,

b) what I've talked about in the past (re: the patch methodology that was implemented by pedro is not reliable). You won't find any working links to my fork working because I deleted it, but the work was simple: stop using define/call and use shell scripts to do the work instead (they were router/patches/apply and router/patches/unapply), guaranteeing 100% reliability.

This type of thing is going to keep coming up over and over and over until the devs learn about the nuances and pains of GNU autotools. They're used everywhere but they're highly susceptible to breakage. Sometimes autoreconf is needed, other times not. It sucks. But the existing patch methodology being so feeble and delicate means that nobody compiling the firmware is sure what broke or where/how.

This feedback is based on comments towards those pushing things forward, and also your comments about contributors (my “meh” code, Pedro’s “crappy job of implementing patching”), potential employment offers (“I’ll only be here a couple of days, don’t get used to my presence”), Broadcom developers (“idiots who don’t know how to code”), etc. etc. etc.

I’m sure I’m not the first, nor will I be the last to tell you this: There are better, more socially acceptable ways of communicating and giving feedback. Your feedback then has a better chance of being discussed/incorporated vs. being ignored because it belittles the work that someone else took the initiative on and spent their personal time and effort to take on.

I just checked your linked to post. Beyond insulting Pedro’s work, given that you said “let’s discuss” I’m not sure why you deleted your repository of your I’m sure optimal patching code... I was scratching my head the first time you left as well, because you made a patch for something then as well, but left and immediately deleted your git repo before anyone could pull it.

In case not clear, I’m saying you need to work on Teamwork, communication, and inter-personal skills.
Positivity breads positivity, and provides you with opportunities that you otherwise wouldn’t get.

There is a way to provide constructive feedback to people. {snip for brevity}

Click to expand...

Okay, you have a problem with my attitude. Thanks for letting me know...?!

I've been part of open-source projects since the early 90s, and I am known within nearly every circle -- as well in my career line -- for being very brash and direct. I do not mince words, I do not beat around the bush, I don't give "lip service"; there's a reason I'm a systems and network engineer and not in customer support. And as an introvert I'm both self-aware, and well-aware of why. I am not the guy you want interacting with customers, I am the engineer you want designing things and being on the hook for fixing problems. This is either a positive or negative trait depending on how you leverage it. It also matters that I was part of the FreeBSD project for almost 2 decades -- a project requiring thick skin when dealing with other devs. What you learn is to distance yourself personally/socially from the thing and instead focus on the goal (the same goal everyone shared).

So when it comes to OSS projects, I couldn't care less about the personalities of contributors -- I care more about the code/thing, and about ensuring past mistakes not be repeated. As such, I believe in holding authors responsible for problems they create. I mentally think of bugs like this: "your bug, your fault, your problem". I treat my own OSS that way as well, and expect end-users to rely on me to fix the bugs that I create (features are an entirely separate subject). If my bug caused them pain/annoyance/etc. then it's my due diligence to fix it, and I actually owe them an apology. The general OSS mentality is that "because end-user has access to the source, they can fix it themselves". This is a mentality that I have strongly disagreed with all my life; I do not expect end-users to have the familiarity with the code, skills, or time to dedicate to fixing bugs. This is why you will never, ever hear me say unto users "send patches" as a rebuttal. Yeah, I have a very different view of OSS than most.

My repository was deleted because the issue was addressed and there was no other purpose of leaving it. I fought the battle to have the patching methodology done with shell scripts, and I lost the battle. kille72/pedro/etc. have every right in the world to do whatever they wish/use whatever methods they wish, I support that fully! Just because they differ from my own doesn't make me right/them wrong or vice-versa! But when I see something that looks an awful lot like something that was supposedly addressed (and in a nebulous way, i.e. I could not find, nor could anyone refer me to, where in GNU make this was actually fixed or where in Debian's distro patches it may have been fixed -- in other words, to me it looked like a strange kludge), I have to shake my head and sigh a bit.

I do not believe in leaving unused stuff laying around; I don't like wasting resources on BitBucket any more than I like wasting my own local disk space. I experienced way too many issues/oddities with their UI that I was pretty turned off by the service in general, but that's entirely subjective. Nothing gets us old timers more riled up than finding old, unmaintained forks/repos of stuff laying around the Internet.

If you have other questions, comments, personal issues with me, etc. I'll be more than happy to discuss them with you in PM.

Any chance of making a driver modification to accommodate the Netgear Fuse (Aircard 779S)? It's a Sierra Wireless card internally, but uses a Netgear USB identifier. Adding a line to qmi_wwan.c (drivers/net/usb/qmi_wwan.c in the kernel source) should allow it to work. In section 3, just above the line "/* 4. Gobi 1000 devices */", adding the following should be all that's needed:

{QMI_FIXED_INTF(0x0846, 0x68d3, 8)}, /* Netgear Aircard 779S */

Unfortunately since my account is new, I can't post a link to the source of this information.

I was trying to make the change myself to test it, but I've been unsuccessful at getting it to actually compile.

... because you made a patch for something then as well, but left and immediately deleted your git repo before anyone could pull it. ...

Click to expand...

I managed to find a local repo copy that still had my fix-patch-methodology branch for ARM. This will not apply cleanly to kille72 (ARM or MIPS) as of this writing, but it should be incredibly easy to port if interested. Attached as a file, as well as a link to a gist so you can view it more easily. Feel free to do with this whatever you wish: https://gist.github.com/koitsu/94c3e48f1debf4ea4b8c124db9518f7b

I want to add that this methodology (which is not of my invention -- doesn't exist in Toastman or Shibby) is quite error-prone (ref#1 and ref#2 for my statement) and can/will break in several edge case scenarios. I've run into this myself both with and without my above methodology -- it's an effect of the "try to figure out if something is pre-patched or not using patch -R" approach, which is fragile (see above references for validation)[1]. One of the most annoying is if you hit Ctrl-C in the middle of a particular phase -- you end up having to fight how router/Makefile is designed, and in 95% of the cases, end up saying "screw it" and clean it up by doing cd ~/base-repo-directory && git reset --hard && git clean -fdxq all because of [2]. We all know this by now, it's the elephant in the room that nobody talks about.

With FreeBSD Ports, build and patch third-party packages regularly: maybe 80% of all ports/packages have custom patches. Third-party software is built within a temporary directory called WRKDIR, which is where the software is extracted into + patched + compiled within. The same directory also contains the source (called WRKSRC) This is unlike Tomato where the approach was "build inside the router/thing directory"[2].

An example would be:

WRKDIR=/some/place/work
WRKSRC=/some/place/work/minupnpd-2.0.36 (extracted tarball dir, also where patches get applied, etc. -- i.e. identical to what would be in router/miniupnpd)

With Ports, to track the "states" of the 7 different "phases" of building third-party software, simple dotfiles within WRKDIR are used. They're internally called "cookies" (nothing to do with web cookies) and are created after a successful phase (e.g. $? == 0). These work marvellously with make. How all these "cookies" work internally and how they're used by make is kind of hairy (don't miss line 5379 too).

The general 7-stage phases go like this: extract, patch, configure, build, stage, install, (optional) package. The targets that use them (also see here, section TARGETS for other magical targets):

make extract -- extracts the source tarball
make configure -- do configure and/or autoreconf, etc.
make install -- install the software system-wide
make build -- does the make/compile itself
make patch -- for applying patches
make stage -- used for generating a file list (plist) of what got generated (list of files that the package manager itself will be aware of)
make package -- for making an actual FreeBSD package (think .deb but different)
make clean -- removes WRKDIR

I'm not saying "hey, someone port FreeBSD ports framework to TomatoUSB!" -- that would never happen (although Linux Gentoo's Portage is heavily based on it). However, the above CONCEPTS are NOT FreeBSD-specific; they're well-established as good form when building third-party software, cross-compiled or not, and work quite well with general make constructs/methodology.

Finally, I want to make clear one point: none of this (bad design of how to build/maintain third-party stuff in TomatoUSB) is really the fault of any one person. Original Tomato (WRT54G days) was very small and the software simple/easy, all maintained by one guy (Jon Zarate) -- seriously, go back and look at src/router from those days! As more routers were RTM and more users wanted more features, lots of stuff got dropped into the router/ directory and the Makefile hacked on by lots and lots of people. TMK, nobody along the way ever stopped + said "hold up, this is not good design for long-term use, we need to revamp this"; the closest was Toastman saying "No, I am not adding {feature,program} XYZ because {list of reasons}". His focus was on trying to keep a good/stable/tolerably-sized firmware focused on the RT-N16, with a secondary focus of trying to keep the software and the repo "tolerably sized". Things became even more complicated when commercial companies started taking bits/pieces of Tomato and changing it (sometimes for the better, sometimes not), while introducing routers with new hardware features (USB comes to mind). So today, we now have something big and messy. Again: no one person can be blamed for it, it's just a result of people hacking on more and more, and not so much rearchitecting. This is one area where OpenWRT/LEDE got right with their packaging + modular GUI approach (not that their GUI is amazing, but I'm talking about the underlying design).

Anyway, that's all from me for now.

[1] -- Possibly git has something that can handle this better. It DOES have its own native patch format; see git format-patch and git diff. So maybe it could be used for applying and detection instead of classic patch? I haven't looked into it so there's a good chance I could be barking up the wrong tree.

[2] -- This is very dangerous and always has been. It's bitten the project repeatedly -- not just kille72, but every fork, including original Tomato -- because the resulting compile/work directory is the same directory as what gets committed in git! So people commit all sorts of stuff and have to clean it out periodically (devs here certainly have seen me tell Shibby, Toastman, and others when the repo contains a bunch of junk that it shouldn't -- those devfs or udev (I think?) infinite-looping symlinks were a cute one) and then try to "wrangle it" using .gitignore -- which doesn't scale/work long term when upgrading software (ex. program v1.1's build files might not be the same as program v1.0's).

It's not just about "leftovers" either, it's also about things like autoreconf rebuilding configure, automake rebuilding Makefile, etc.. which can have dire effects (as said before: sometimes the originals in the source tarball work correctly, while other times they must be rebuilt with autoreconf/automake else they misbehave. Every third-party program is different, because the GNU autotools are notoriously broken and awful and vary in behaviour between even minor version numbers! ). You don't want to commit any of this stuff into the git repo, you want to keep the repo as "true/pure" as possible. pedro knows this for sure and he deserves two thumbs up for trying to keep it that way!

At the same time, the existence of a $WRKDIR/.patch_done can tell make definitively "yes the source within $WRKSRC has patches applied". No longer do you have to "try" a reverse patch; you just "make clean" (rm -fr $WRKDIR) and bam, problem solved. For populating WRKSRC, consider cp -R or rsync -aH.

I haven't checked this forum for a while as i switched to openWRT on my main router...
It's really awesome that u guys did a fork for MIPS based devices. I'll try this firmware with my old RT-N66 asap <3

Just a question, are vlan's and ebtables working with the latest beta ?
I would love to set up a Tomato Guest AP with my old RT-N66U so i would need working vlan's and ebtables to isolate the clients...

I wanna write a new status report and say that everything now works as expected. I gave it another try to reflash/reset configuration and it seemed to have to have fixed my problems. I'm using my Asus AC66U as an AP, so DHCP/DNS etc is turned off. It has a couple of vlans tagged and it works perfectly. No problem with 2,4 or 5ghz either.