TomatoUSB

There is most likely a bug affecting all Shibby and Toastman builds for the Asus RT-N66U.
I have experienced this issue on all the Toastman and Shibby builds that I have tried.
When executing scripts, for instance Optware startup scripts they only execute as they suppose to do in about 50% of all tries.
I have been in contact with a few other RT-N66U owners having the very same issues.

Here is a example script containing the "case directive" pointing out what happens:

#!/bin/sh

case "$1" in
test)
echo "test working"
;;

*)
echo "Usage: `basename $0` {case parameter failed}"
;;
esac

Running this script manually a few times in a row gives me the following result.

Tomato v1.28.0497 MIPSR2-Toastman-VLAN-RT-N K26 USB VPN-NOCAT
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Usage: test {case parameter failed}
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Usage: test {case parameter failed}
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Usage: test {case parameter failed}
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Usage: test {case parameter failed}
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Usage: test {case parameter failed}
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Usage: test {case parameter failed}

I have noted tho that if I run the script the following way it works as it should.

root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /bin/sh /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root#

Not all scripts suffer from this but for instance scripts that calls the case directive do.
Please look in to this issue, as it is now Tomato is totally useless on the Asus RT-N66U.
I can provide sysinfo if needed.

Yes, this was also noted here:

http://www.linksysinfo.org/index.php?threads/toastman-rt-n-tomato-firmware-on-asus-rt-n66u-dark-knight-dual-band-wireless-n900-gigabit-router.36959/page-3#post-181608

It seems to fail (often) when the first line contains
#!/bin/sh

The shell seems to confuse $1 and $0.

Case constructs are not necesary to trigger this fault.

A simple echo $1 is enough.

Any new updates?! Does any Dev (shibby or toastman) finally accept this bug?!

And is there a solution to avoid it?!

I tried removing #!/bin/sh from my test script and then it works way more often but I do get occasional segfaults if that can be any clue.

root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
Segmentation fault
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root# /opt/etc/init.d/test test
test working
root@RT-N66U:/tmp/home/root#

Worth mentioning is that I have tested other shells too (bash, zsh) and the result are the same.

Btw… Hi thE 29, nice to see you here too.
Let's hope that some devs read here so that we at last can get a final solution to this.

Hohi ;)

Did anyone tried the costum build firmware from RMerlin?! (I am not allowed to post links.. stupid shit)

As it is based on the original Asus-FW the firmware shouldnt have that bug.. At least we could try it and see if the shell is working without random errors..

Worth mentioning is that I have tested other shells too (bash, zsh) and the result are the same.

Did you also try ash (the native shell in Busybox)?

Hmm, I can't remember if I tested ash, I might have. I tested most of the ones I could install via Optware.
I might have missed ash but I do suspect that it would be the very same result anyway.

I'm gonna check on RMerlin. Sounds interesting. I read somewhere tho that Asus native firmware is mostly built on Tomato so maybe the bug is there too. lol

Is this only RT-N builds?

If its both with firmware BusyBox and Optware only thing I can think is kernel memory management - but then you'd expect major crashes all the time!

The builds that I have tested are all RT-N builds.

Shibby
tomato-K26USB-1.28.RT-N5x-MIPSR2-083V-Mega-VPN
tomato-K26USB-1.28.RT-N5x-MIPSR2-085V-AIO
tomato-K26USB-1.28.RT-N5x-MIPSR2-087V-AIO
tomato-K26USB-1.28.RT-N-MIPSR2-088V-AIO

Toastman
tomato-K26USB-1.28.0497.1MIPSR2-Toastman-VLAN-RT-N-VPN-NOCAT

It affects virgin installs as well as with Optware added.
I second on kernel memory management, thats my bet.