so if i add missing configuration option and set the same chain like this:
"upnp_nat_postrouting_chain=upnp\n"

should works. What do you think?

Click to expand...

Not sure it's a good idea. You will get redundant entries that will only slow down packet processing as each packet will have to be checked against that rule. Best to add them them to a separate chain, and simply not jump to that chain at all. It will be more efficient performance-wise.

It works for the two other chains because both chains are in different tables (filter and nat).

I did a clean install (clearing my nvram) of v133 this morning, but after re-configuring the router my clients couldn't access the Internet. I'm using the RT-Nxx IPv6-VPN build on a RT-N10p router. My clients can obtain and IP address and ping the router, but cannot browse further past that. From the CLI on the router itself, I am able to ping out of the gateway.

It seems to be related to QoS somehow. If I disable QoS on the router, everything on my LAN can see out. But as soon as I enable QoS, nothing on the LAN is able to get past the router. Any thoughts?

In my opinion it should not be called multi wan if its meant for normal single wan aswell it should just be 134 creates confusion already asked if i want single wan to use 132 or 133 multiwan got no answer

in deed i released v134 for ARM few minutes ago. Version for Mipsel`s routers should be ready for few days. Please be patience.

As always please read changelog first.

Best Regards

Click to expand...

shibby20

Will there be a version for 134 TENDA W1800R ?, We have not seen the version 133 for our router.
udpxy udp-to-http doesn't function, it is visible that a router the multicaste tries to reproduce streams, but right there falls off and jumps on the following stream, whether it is possible to make correction for tenda?

Did some testing. Issue I reported is not because of dnsmasq. It is a dropbear bug. Just tried v134 with dropbear from v132 (2015.67 vs v2015.71) and it works. So either we wait for dropbear fix or Shibby can make new version with older dropbear version.

I use google dns servers 8.8.8.8 and 8.8.4.4
I put them into network->basic and saved. It works fine, no issue. However when I wanna use dns from my provider, I deleted google dns entries and set dns to auto, click to save. In overview google dns are still shown, it should not be, right?

ASUS RT-AC68U running v134 VPN (w/ NVRAM full erase) - I have a USB3 ext4 drive plugged in my USB3 port, yet the LED light only shows USB 2.0. Sticking it in the 2.0 port will also make the LED show up as 2.0.

Dear sirs,
could you please tell me how to flash Shibby's Tomato over Advanced Tomato 132 on R7000?
Thank you in advance!

Click to expand...

You can just flash it from the web admin GUI, no initial image, just flash it on top of Advanced Tomato. If you're flashing the same version (Shibby v132), you most likely don't even need to reset to factory defaults. If you're flashing v134, then I'd just flash it, reset to factory defaults, and re-enter my configuration.

ASUS RT-AC68U running v134 VPN (w/ NVRAM full erase) - I have a USB3 ext4 drive plugged in my USB3 port, yet the LED light only shows USB 2.0. Sticking it in the 2.0 port will also make the LED show up as 2.0.

I believe all we need to do is to update wanuptime.c to look for /var/lib/misc/wan_time and recompile the firmware.

Click to expand...

I was taking a look at this (rather, asp_link_uptime) in the source to understand how status-data.jsx retrieves it, and it does seem to retrieve from /tmp/var/lib/misc/wan_time from what I could tell. Can't cat it though, sadly.

I think I'm going to have to retrieve the information from status-data.jsx in the meantime, because a couple of my scripts rely on it.

Have noticed some new odd behaviour on v6 with v134. Seems to be related to DNS.

Previously http://test-ipv6.com/ would return 10/10, however now it's often returning 9/10, saying that the DNS server doesn't have v6 access. This seems to result in sites which were previously happily moving traffic over v6 defaulting back to v4.

Setting the DNS servers on my clients manually resolves it. Not sure what could be causing it. DNSMASQ has the same config as before. Does anyone have any ideas on what could be causing this?

Edit: Seems this is due to the router defaulting to using the PPP assigned DNS servers instead of the manually assigned ones. My ISP's primary v4 DNS server doesn't seem to be returning v6 results as reliably as expected.

@shibby20 I'm trying to use another SSL certificate using instructions from the TomatoUSB website titled "Use SSL certificate for WAN admin"

Following those instructions doesn't work, the router will continue to use the self-signed certificate it generated after restarting httpd. I'm sorry if this has been asked before, I tried doing a search of the forums and didn't come up with anything useful. Is there a possibility of adding a web interface to upload certificates and keys to? Is there any way to do this without downgrading to 132?

I was taking a look at this (rather, asp_link_uptime) in the source to understand how status-data.jsx retrieves it, and it does seem to retrieve from /tmp/var/lib/misc/wan_time from what I could tell. Can't cat it though, sadly.

I think I'm going to have to retrieve the information from status-data.jsx in the meantime, because a couple of my scripts rely on it.

Looks like Tomato helper code has been broken for a long time - probably from the beginning. In incorrectly calculates the lease duration time when it reloads the lease information from file. Sometimes it results in a lease which is not going to expire for years , and sometimes - with the already expired lease.
Attached is the patch to fix this:

i use Comodo DV SSL on Tomato. Just added to init script after mount USB drive).

Remember to add ca.crt into router.domain.crt file

Best Regards.

Click to expand...

After I restart httpd the /etc/cert.pem and /etc/key.pem are reset to self-signed certificates and browsers will display warnings when trying to connect.

Edit: I was including the intermediate certificate in the /etc/cert.pem file. According to another post here that probably went past the max length of the https_crt_file variable. I had no issues installing the certificate without including the intermediate (on both a v132 and a v133 router). To get around the browser warnings I installed the intermediate authority in the windows intermediate cert authorities store. Kinda unfortunate since best practices are to pass along intermediate certificates with the server certificate, but it still works.

It appears that the VPN Client Routing section is not working. If I set only one IP to pass through the VPN (my laptop) it still passes everything through. I verified this by running traceroute from different devices and comparing the route with the VPN on and off.

Has anyone else noticed this? I flashed the NVRAM after upgrading and re-entered all my settings from before.

Edit: I got it to function correctly once I rebooted the router a couple of times.

@shibby20
I installed version 134 on my R8000. IPv6 appears to have some issues. The router gets an address but no devices can use the address. This may be an old bug cropping back up where a spurious default route is added for the WAN interface (usually vlan2), where all IPv6 packets going out the default route effectively go to /dev/null. I'll report back if anything else crops up.

Would break Connection Uptime under WAN in the GUI, and uptime is a separate command from wanuptime. In any case, it still returns a segmentation fault.

As an unrelated issue, I seem to have a number of my scripts losing their permissions and reverting from Unix line endings, to Windows line endings. On top of this, my init script is not being called despite having called it from Admin > Scripts > Init.

I've had to roll back as v134 is more trouble than it's worth - hopefully @shibby20 releases v135 compiled with the old toolchain (and any other fixes deemed appropriate).

The man dedicates his free time to this though, so I'm willing to be patient

Would break Connection Uptime under WAN in the GUI, and uptime is a separate command from wanuptime. In any case, it still returns a segmentation fault.

As an unrelated issue, I seem to have a number of my scripts losing their permissions and reverting from Unix line endings, to Windows line endings. On top of this, my init script is not being called despite having called it from Admin > Scripts > Init.

I've had to roll back as v134 is more trouble than it's worth - hopefully @shibby20 releases v135 compiled with the old toolchain (and any other fixes deemed appropriate).

The man dedicates his free time to this though, so I'm willing to be patient

Click to expand...

Yeah correct it segfaults. I overlooked this and probably was sleep deprived

I will try recompiling the firmware and let you know if it worked.

I always had problems with init scripts. I gave up on them and run stuff when I mount my flash drive. Much more reliable, across both of my units (WNR3500Lv2 and R7000).

1) I got rid of that check_wanup() thingy (this caused the segfaults) and corrected the file name. This was the quickest approach to fix the binary. However I don't have multiple WAN's so I have no idea how this behaves with multiple WAN's. Testing is needed by whoever has two or more WAN's.

Attached Files:

I installed version 134 on my R8000. IPv6 appears to have some issues. The router gets an address but no devices can use the address. This may be an old bug cropping back up where a spurious default route is added for the WAN interface (usually vlan2), where all IPv6 packets going out the default route effectively go to /dev/null. I'll report back if anything else crops up.

Click to expand...

Uncheck the "Request PD Only" box, it's only needed for PPPoE (DSL,Fiber?) connections, to get the
default route they need for IPv6

I added very crappy error handling to a failed sysinfo(2) call. I need to know what the expected behaviour is if this fails -- do we just return a non-zero exit code, or do we actually need to print out a value to stdout?

What you did in your example with wantime_file serves no direct purpose compared to a hard-coded string (all you did was move a hard-coded pathname into a 128-byte buffer allocated on the stack in a variable, zeroed it, then copied the pathname into the buffer, then referenced said variable).

I'm not really sure what all the hubbub is about in the fix, though, unless the path was completely wrong and that's truly the full fix.

One thing that caught my attention was switching variable uptime from a time_t to a long. On 32-bit Linux architectures, the time_t typedef is a long (signed 32-bit number, i.e. suffers from epoch rollover/year 2038 bug (nothing we can do about it)). The situation becomes more complex on 64-bit archs (because time_t there usually is a long long, i.e. 64-bit number), and detecting "how to handle" time_t in several ways is difficult. This is why the time_t typedef was created in the first place.

The sysinfo struct member uptime as per the sysinfo(2) syscall is declared as a long, but the variable uptime (in the program) was declared as a time_t.

We should really keep uptime as a time_t, as odds are what writes that file in the first place writes out a time_t -- you therefore want to make sure you read it back in as a 64-bit number. The math portion, si.uptime - uptime, should still work. If it emits warnings, a force-cast of si.uptime to a time_t should suffice, e.g. (time_t) si.uptime - uptime. Someone may want to review the sysinfo struct on the 64-bit Linux kernel source used to determine what the uptime struct member actually is there (it's very possibly still a long -- not sure! If it's still a long, then okay, no worries -- a long on a 64-bit arch is a signed 32-bit number).

If you plan on doing something with the buffer or filename dynamically at run-time, then you have reason to use a variable for it. In that case, you'd actually want this:

Same question applies to a failed calloc() call in this example -- what exactly do we want to do in that situation? (That'd be pretty awful though -- a system that can't allocate ~1-4KBytes of RAM (depending on arch/platform) probably has other problems going on).

C coding tips:

1. Path and filename length limits are defined as PATH_MAX and FILENAME_MAX. However, using these is tricky. "To keep it simple", just use PATH_MAX. This is also known as MAXPATHLEN on the BSDs, though both work.

2. Still referring to the same issue of path and filename lengths: do not allocate this buffer on the stack. Instead, dynamically allocate it (and later free it) using calloc() (i.e. var = calloc(1, PATH_MAX); then later free(var)). This takes care of i) possible stack exhaustion, ii) the need for the memset(), and iii) complies with general guidelines per GNU libc (though we do not use glibc on Tomato, we use uClibc, but the premise stands -- large-ish buffers should not be allocated on the stack); once you read those warnings about PATH_MAX not being enforced by some functions (oh well) and how buffers using FILENAME_MAX should be dynamically allocated, you'll understand the justification.

3. Do not use sprintf() to populate the contents of a buffer in this manner -- sprintf() is insecure and dangerous (though in this usage context it's safe, but there's literally no need for use of it). Consider strcpy(), or the better strlcpy(). If %-expandos must be used, consider snprintf() and learn about the dangers (be very very careful what you accept as input!).

4. Make sure to try building your code with -Wall to ween out any potential problems. If you encounter type mismatches, don't just force-cast to squelch the warning -- figure out what the problem is and fix it properly.

Hey Guys, I have a question where I didn't find the Answer yet. I got a Asus DSL-AC68U Router and wanted to know if I can use the Shibby FW for the AC68U on it ? I think they are pretty much the same only the DSL Version has only 1 USB 3.0. Any Ideas ?

Hey Guys, I have a question where I didn't find the Answer yet. I got a Asus DSL-AC68U Router and wanted to know if I can use the Shibby FW for the AC68U on it ? I think they are pretty much the same only the DSL Version has only 1 USB 3.0. Any Ideas ?

Click to expand...

No. Even if it flashed and runs without bricking, Tomato will not have any of the underlying code and UI necessary to manage the DSL hardware and connection.

I have ran both latest Shibby and Toastman versions on my R7000 and after consulting with Toastman and then changing a few settings, my R7000 with either flavor of tomato firmware has EXCELLANT wireless range. The 5 Ghz range is in fact better in a huge way when compared to my older E2000 and E3000 units.

for 2.4 Ghz set country to Singapore and power to 0

for 5 Ghz set country to USA and power to 0

I mainly only use 5Ghz wireless AC devices so I have wireless mode set to N only and 80 Mhz

With these settings my 5Ghz wireless AC Range is incredible!!!

I can't really comment about 2.4Ghz range as I only use it for old legacy devices that don't support 5 Ghz wireless AC, but from what I have seen its range is comparable to stock firmware

I tryed to upgrade my R7000 from v132 to v134 and saw those problems implementing this new version:

The mac address on wan port changed, and even when i changed to what it used to be on v132 doesn't change on reboot.
In my lan network i have 3 vlans beside the default vlan1 and i have associated them to bridges. When i try to associate example br1 to wifi, the client's doesn't get any ip's, and i have dhcp authorized.
One of the bridges has router ip 192.168.2.1 subnet is a 24 bits and associated to a vlan 12, when i try to connect a client on that router port (untagged) with a fixed ip, the client doesn't ping the router, i had to changed to router ip on that bridge to 192.168.4.1/24.

I just updated my Linksys E3000 router to version 133 and I have something weird going on. I have rebooted my router twice now and the power LED keeps flashing and won't stop flashing even though I can access the web GUI of the router and access the Internet through said router. Heck, I'm even posting this message while connected to the Internet through the router all the while the power LED keeps on blinking.

Why is it blinking? How can I get it to stop blinking? It's going to keep blinking until the cows come home, and then some.

Shibby wrote we had to do a full clear and reconfigure manually after updating to 133, because there are major changes he made. So you shoould initiate a thorough nvram clear and enter your configuration again then. Do not use a saved configuration file.

I have a rather different and possibly easy question to ask: If DHCP / DNS is disabled in tomato, does that break the IP traffic monitoring / device list? I'm getting somewhat annoyed with dnsmasq returning server failed when it shouldn't and then caching those results (nslookup cloudflare.com 192.168.1.1 = server failed, nslookup cloudflare.com 8.8.8.8 = the right IP results even though dnsmasq points to 8.8.8.8), so I'm planning on setting up a mini-pc to handle it separately: But I still want to keep my traffic logging, and possibly the device list.

I'm using a R7000 and since the MultiWAN release (v133 and v134) the support for vlan's seems to be broken. I'm using a Dutch ISP (Telfort) which provides a fiber connection. Up till v132 all that was required to make this work (without the supplied router that came with it) was following settings under Advanced->VLAN:

I'm running Shibby 1.28 on an Asus AC68U router. I'm using Tomato's webserver (nginx) to set up a reverse proxy per these instructions. That is, I set up port forwarding from the outside world to the router's ip, and the router's web server acts a reverse proxy (with SSL) and points to the ip camera. I set up port forwarding. I checked "Allow Remote Access" for the web server to make sure the router responds to the outside world. I also tried the steps one at a time per the post to make sure things work.

When I'm on the network, and I use the public URL, my https address works (so port forwarding and reverse proxy works). However, when I'm not on the home network, it does not. Any thoughts on what I'm doing wrong? I even tried the reverse proxy without SSL, and that too does not work when I'm outside the home network. Is it a port forwarding issue? I'm using ports in the 7000's. When I port forward to port 85 (default nginx page) without the reverse proxy, I am able to see the site in the outside world.

Have noticed that the bandwidth monitor no longer seems to record any data on v134.
Interface PPP0 doesn't show up on the 24 hour graph, but does on real time. Could perhaps be why it's not showing up. Only have one WAN connection set up, so it shouldn't be confused with recording traffic on multiple WANs. NVRAM was cleared in between the update. Not sure why it's not recording any more.

I'm running Shibby 1.28 on an Asus AC68U router. I'm using Tomato's webserver (nginx) to set up a reverse proxy per these instructions. That is, I set up port forwarding from the outside world to the router's ip, and the router's web server acts a reverse proxy (with SSL) and points to the ip camera. I set up port forwarding. I checked "Allow Remote Access" for the web server to make sure the router responds to the outside world. I also tried the steps one at a time per the post to make sure things work.

When I'm on the network, and I use the public URL, my https address works (so port forwarding and reverse proxy works). However, when I'm not on the home network, it does not. Any thoughts on what I'm doing wrong? I even tried the reverse proxy without SSL, and that too does not work when I'm outside the home network. Is it a port forwarding issue? I'm using ports in the 7000's. When I port forward to port 85 (default nginx page) without the reverse proxy, I am able to see the site in the outside world.

After further thinking and testing, I believe what's going on is that the router is ignoring the request from the outside world. I thought it was a port forwarding issue, but I have other port forwards to other internal locations, and I don't have a problem. Thus, it must be the router ignoring (except port 85, the default for nginx on the tomato).

I googled "tomato nginx remote access", and ran into this thread. Running the something like the following made things work:

iptables -t filter -A INPUT -p tcp --dport 12345 -j ACCEPT

I think this makes the router accept connections on the stated port. I'll add the necessary lines under Administration > Scripts > Init.

Hello Shibby.
I want to ask you if you are planing to update your Tomato firmware for Netgear WNDR4500v3.
I just bought this router and was hoping I will get v2 but I got v3 which has different chip than v2 and it needs .img file not .chk.

So I want to ask you if you are at least considering to update your Tomato firmware for this new version or I should go to the store and ask for replacement for older version of this router.
Thank you very much

I finally decided to try out v133 on the RT-N66U and the router wouldn't pull an IP from the modem (yes, NVRAM was cleared). Trying to revert back to v132 ended up a multi-hour debug process. I've always upgraded with almost no issue to every new version for over 4 years... did I miss something this time?

I finally decided to try out v133 on the RT-N66U and the router wouldn't pull an IP from the modem (yes, NVRAM was cleared). Trying to revert back to v132 ended up a multi-hour debug process. I've always upgraded with almost no issue to every new version for over 4 years... did I miss something this time?