I found another discrepancy:
"Make Target" v has option JFFS to Y, but in the makefile the option NO_JFFS=y for K26.
Is this a fault in the makefile or in the builds.png?
Gesendet von meinem GT-I9100 mit Tapatalk 2
Tomato Shibby's Releases
- Thread starter shibby20
- Start date
I found another discrepancy:
"Make Target" v has option JFFS to Y, but in the makefile the option NO_JFFS=y for K26.
Is this a fault in the makefile or in the builds.png?
Gesendet von meinem GT-I9100 mit Tapatalk 2
@zorkmta - i suggest you do:
1) make settings backup of v104
2) download v104 and latest v108
3) upgrade to v108 without nvram clear
4) If all works correct then have fun
5) If you have some issues, router is unstable or some of services does not work, then return to v104, clean nvram and restore settings from backup
BR!
1) make settings backup of v104
2) download v104 and latest v108
3) upgrade to v108 without nvram clear
4) If all works correct then have fun
5) If you have some issues, router is unstable or some of services does not work, then return to v104, clean nvram and restore settings from backup
BR!
I dirty flashed 108 from 104 and had major issues with wireless.
I upgraded my router Asus rtn16 from v. 83 to 108 k26 RT build and I experienced the same long boot issues that users in the polish forum have been describing.
I did clear nvram. I am not sure what revision my router is but when I bought it came in a bluebox with a manufactured in 2010 logo.
I downgrade to the 105.1 build and the long boot is gone.
Does anyone know if the k26 RTN 108 build has the same long boot problems as the RT version?
I did clear nvram. I am not sure what revision my router is but when I bought it came in a bluebox with a manufactured in 2010 logo.
I downgrade to the 105.1 build and the long boot is gone.
Does anyone know if the k26 RTN 108 build has the same long boot problems as the RT version?
Trying to build the tomato-shibby-RT-N branch, more specifically the aio version (make r2z). I am on lubuntu 12.10 32 bit.
The build fails quite a bit in (it is a slow machine) when trying to build openvpn, it says something about missing ltmain.sh, which google tells me amounts to this: http://www.gnu.org/software/automak...or-required-file-ltmain_002esh-not-found.html
Anyone stumbled into this? And solved it?
Sounds like you're missing dependencies. http://tomatousb.org/tut:how-to-build-and-rebuild-tomato-for-total-noobs
Thanks, saw that just after submitting my question. Looks like there could be trouble building on any recent Ubuntu distribution though. Not giving up just yet though.
Signature? Signature!
Hi!
just rolled back to v104 from v108 because two issues on RT-N66U (AIO 64k):
1- Introduced in v105: bandwith history doesn't get saved, there's no "WAN" tab when looking through the data on the web interface in "last 24h". I think this happens when I add br1 to get a virtual wifi on a diferent network subnet
2- Introduced in v108: my PSVita can't access internet.
Rolling back to v104 solved both problems.
Regards and thanks for the great work!
just rolled back to v104 from v108 because two issues on RT-N66U (AIO 64k):
1- Introduced in v105: bandwith history doesn't get saved, there's no "WAN" tab when looking through the data on the web interface in "last 24h". I think this happens when I add br1 to get a virtual wifi on a diferent network subnet
2- Introduced in v108: my PSVita can't access internet.
Rolling back to v104 solved both problems.
Regards and thanks for the great work!
Is anyone else having problems in v108 with connecting to the FTP server from the WAN side?
On my RT-N66U ftp works fine in LAN (and thru the loopback) but is major no-go from outside. First I though, it might had been the not-cleared-nvram problem but I just tried on a clean install and it shows the same behavior: connecting client times out, there are basically no signs of the connection in log. Could it be a firewall issue??
I went through the log and found this entry:
Now, can someone knowledgeable please tell me if this can be the culprit of the ftp problem?
On my RT-N66U ftp works fine in LAN (and thru the loopback) but is major no-go from outside. First I though, it might had been the not-cleared-nvram problem but I just tried on a clean install and it shows the same behavior: connecting client times out, there are basically no signs of the connection in log. Could it be a firewall issue??
I went through the log and found this entry:
And here's the iptables.error file:
root@unknown:/tmp/etc# vi iptables.error
:OUTPUT ACCEPT [0:0]
COMMIT
*nat
:OUTPUT ACCEPT [0:0]
:WANPREROUTING - [0:0]
-A PREROUTING -d 87.206.212.*** -j WANPREROUTING
-A PREROUTING -i vlan2 -d 192.168.1.1/255.255.255.0 -j DROP
-A WANPREROUTING -p icmp -j DNAT --to-destination 192.168.1.1
-A POSTROUTING -o vlan2 -j MASQUERADE
-A POSTROUTING -o br0 -s 192.168.1.1/255.255.255.0 -d 192.168.1.1/255.255.255.0 -j SNAT --to-source 192.168.1.1
COMMIT
*filter
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
:logdrop - [0:0]
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-macdecode --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
:logreject - [0:0]
-A logreject -j LOG --log-prefix "REJECT " --log-macdecode --log-tcp-sequence --log-tcp-options --log-ip-options
-A logreject -p tcp -j REJECT --reject-with tcp-reset
:logaccept - [0:0]
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-macdecode --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-N shlimit
-A shlimit -m recent --set --name shlimit
-A shlimit -m recent --update --hitcount 4 --seconds 60 --name shlimit -j logdrop
-A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
-N ftplimit
-A ftplimit -m recent --set --name ftp
-A ftplimit -m recent --update --hitcount 21 --seconds 1800 --name ftp -j logdrop
-A INPUT -p tcp --dport 21 -m state --state NEW -j ftplimit
-A INPUT -i lo -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -p udp --sport 67 --dport 68 -j logaccept
-A INPUT -p tcp --dport 21 -j logaccept
-A INPUT -j logdrop
:FORWARD DROP [0:0]
-A FORWARD -m account --aaddr 192.168.1.0/255.255.255.0 --aname lan
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
:wanin - [0:0]
:wanout - [0:0]
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i vlan2 -j wanin
-A FORWARD -o vlan2 -j wanout
-A FORWARD -i br0 -j logaccept
COMMIT
Now, can someone knowledgeable please tell me if this can be the culprit of the ftp problem?
Nevermind, i see now there isn't even an available setting for that.
@Shibby
Your bulid 108-AIO running fine here, just have to ask if this is in your build, Column sorting fixes:
http://repo.or.cz/w/tomato.git/commit/0e3ab0fe28e681012f69d468191d5895a96f2579
kthaddock
Your bulid 108-AIO running fine here, just have to ask if this is in your build, Column sorting fixes:
http://repo.or.cz/w/tomato.git/commit/0e3ab0fe28e681012f69d468191d5895a96f2579
kthaddock
Hello shibby,
A few issues to report here (please excuse me for not posting at OpenLinksys). I'm using build 108 on my Asus RT-16N.
Bandwidth Limiter:
Using build 108 firmware defaults on my RT-16N, the connected LAN ports are displayed in the correct position, but the port labels are reversed, i.e. LAN 1 thru LAN 4 should be labelled right-to-left (not left-to-right). If I enable "Invert Ports Order" then the connected port positions are reversed, but the port labels do not change.
To illustrate, I have cables connected to the WAN, LAN 1, and LAN 2 ports. This status display puts the cables in the correct locations but the port labels are reversed:
FYI, I noticed that nvram shows t_model=35 for this build, while build 106 shows t_model=32.
Thanks!
EDIT: Finally found your bug tracker at http://tomato.groov.pl/?page_id=334 . I've created bug reports 232 and 233 for these issues. Report 233 (re: Default Class for br0) is really a combination of bug report and feature request. If you could at least switch the priority to Normal that would be good enough for now, thanks.
P.S. Also found your Donate button there, pizza and beer money is on the way...
A few issues to report here (please excuse me for not posting at OpenLinksys). I'm using build 108 on my Asus RT-16N.
Bandwidth Limiter:
- The Default Class for br0 creates a "prio 3" (i.e. "Low") ruleset in /tmp/etc/qoslimit. Can this be changed to instead create a "prio 2" (i.e. "Normal") ruleset?
- Better yet would be the ability to change the priority via a dropdown menu like you have for br1, br2, and br3.
- And if you will be going to that trouble, perhaps add TCP Limit and UDP Limit menus for br1, br2, and br3, like you have for br0?
- Minor nit: "bandwidth" is misspelled in the sections for all four interfaces.
Using build 108 firmware defaults on my RT-16N, the connected LAN ports are displayed in the correct position, but the port labels are reversed, i.e. LAN 1 thru LAN 4 should be labelled right-to-left (not left-to-right). If I enable "Invert Ports Order" then the connected port positions are reversed, but the port labels do not change.
To illustrate, I have cables connected to the WAN, LAN 1, and LAN 2 ports. This status display puts the cables in the correct locations but the port labels are reversed:
FYI, I noticed that nvram shows t_model=35 for this build, while build 106 shows t_model=32.
Thanks!
EDIT: Finally found your bug tracker at http://tomato.groov.pl/?page_id=334 . I've created bug reports 232 and 233 for these issues. Report 233 (re: Default Class for br0) is really a combination of bug report and feature request. If you could at least switch the priority to Normal that would be good enough for now, thanks.
P.S. Also found your Donate button there, pizza and beer money is on the way...
@kthaddock, yes I've seen that, thanks. On my RT-16N, Invert Ports Order just flips the connected port order (which is not what I want, since the default order is correct). It's the default port labels that need to be flipped. Please check the thumbnail in my previous post for a picture of what I mean. I'm using tomato-K26USB-1.28.RT-N5x-MIPSR2-108-VPN.
If I recall correctly this was not a problem with build 106. But I may not be recalling correctly.
As I mentioned above, I see that nvram shows t_model=35 for this build 108, while build 106 shows t_model=32. This might be a hint as to what happened to cause this bug, but I'm just guessing.
If I recall correctly this was not a problem with build 106. But I may not be recalling correctly.
As I mentioned above, I see that nvram shows t_model=35 for this build 108, while build 106 shows t_model=32. This might be a hint as to what happened to cause this bug, but I'm just guessing.