[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[Badlandz]

Confirmed. This is an old bug that appears when you have enabled parental control;

Without parental control:
-A FORWARD -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A FORWARD -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT

With parental control:
-A FORWARD -i br0 -m mac --mac-source 34:14:5F:3E:C7:8B -j DROP
-A PControls -i eth0 -m state --state INVALID -j DROP
-A PControls -d 192.168.100.1 -i br0 -o eth0 -p tcp -j DROP
-A PControls -i br0 -o eth0 -j ACCEPT
-A PControls -j ACCEPT

So it seems that enabling parental control moves the NSF rules into the PControls chain, whilst putting the parental control rule into the FORWARD chain.

I'm not sure how the PControls chain is intended to be used as it isn't called from anywhere.

EDIT: To see this bug parental control must be enabled AND have at least one rule setup.

Ah, did not turn on parental control as of yet, so a factory reset didn't resolve it. Thanks for the heads up.

 

[ColinTaylor]

OK that makes sense, but what, other than ACCEPT, is meant to be in the PControls chain? It just seems to have copied 3 unrelated rules.

To answer my own question ... This is the "normal" chain without NSF active. So it looks like it's just adding the 2 extra NSF lines by mistake.

-A PControls -i eth0 -m state --state INVALID -j DROP
-A PControls -j ACCEPT

 

[john9527]

To answer my own question ... This is the "normal" chain without NSF active. So it looks like it's just adding the 2 extra NSF lines by mistake.

-A PControls -i eth0 -m state --state INVALID -j DROP
-A PControls -j ACCEPT

Caught me typing There's actually a reason for those rules

I've just tested a fix for the next beta (A long standing problem....still in the latest Merlin).

But it also pointed out something else. The more options you use, the more likely that something may break, just because the code uses some hardcoded offsets to insert some rules and multiple options change these offsets. Asus should really take a look at another way to do the final build of the rule order.

 

[RMerlin]

Asus should really take a look at another way to do the final build of the rule order.

The "clean" way to do it would be (IMHO) have a separate chain for every feature, and have a static list of jumps to these chains. If a feature isn't used, then the empty chain will simply return you back to the primary chain (probably the FORWARD chain).

This static list of jumps would be done at firewall_setting() or nat_setting(), depending on which chain they jump from.

But that's the kind of change that can become a train wreck as Asus keeps making changes to that code, and would require actively maintaining. Not something I'd personally be willing to. Architectural changes are rarely a good idea with the type of projects we are trying to run here...

 

[john9527]

But that's the kind of change that can become a train wreck as Asus keeps making changes to that code, and would require actively maintaining. Not something I'd personally be willing to. Architectural changes are rarely a good idea with the type of projects we are trying to run here...

Amen to that! Me neither....

 

[Chrysalis]

John I sent you more detailed feedback on my ipv6 stuff in a PM.

 

[john9527]

Time for a beta refresh...
Thanks all for the test and feedback....keep it coming!

BETA RELEASE: Update-19B8
2-September-2016
Merlin fork 374.43_2-19B8j9527
Download http://bit.ly/1UGjcOX
============================

Following are the major changes (full changelog is in the zip files)

Update-19B8

• Update OpenVPN to 2.3.12
• No longer dump the VPN status to the syslog when opening the status page
• Add the new IPTV profiles to the initial setup dialogue - @threepwood
• Fixes/Updates
  • Updates to the IPv6 conf files for subnets larger than /64 - @Chrysalis
  • Generate QoS rules for a single MAC address for IPv6 - @Chrysalis
  • Fix bad iptable rule generation when using both Parental Controls and Network Services Filter - @Badlandz
  • Fix scheduled disk scans could run on the wrong drive

Update-19B4

• Support prefix lengths other than 64 for native IPv6
  This is one needing some testing, as my ISP only support 64 prefix length.
• Support Meo, Vodaphone and Hinet MOD profiles for IPTV
  Another one where I need help testing, both the new profiles and older ones, as I needed to make some changes affecting the older profiles in order to support the new.
  Before anyone asks, Movistar is NOT supported. Movistar is a complex nightmare, and I quit working on it after backporting over 1000 lines of code.
• Update to version 6 of IPSET for ARM routers
  This updates IPSET to the same version used by Tomato and DD-WRT for ARM. It will require some changes to scripts if you are using IPSET on ARM. Here's a code snip that will detect the IPSET version and apply the correct modules. The rest of the commands for IPSET should be backwards compatible. If you find something that is not, please give feedback.
  

  # Load ipset modules                                                        
  ipset -v | grep -i "v4" > /dev/null 2>&1                                      
  if [ $? -eq 0 ];                                                              
  then                                                                    
     # old ipset                                                           
     ipsetv=4                                                              
     lsmod | grep "ipt_set" > /dev/null 2>&1 || \                          
     for module in ip_set ip_set_nethash ip_set_iphash ipt_set             
     do                                                                    
         insmod $module                                                
     done                                                                  
  else                                                                          
     # new ipset                                                  
     ipsetv=6                                                     
     lsmod | grep "xt_set" > /dev/null 2>&1 || \                  
     for module in ip_set ip_set_hash_net ip_set_hash_ip xt_set   
     do                                                           
         insmod $module                                       
     done                                                         
  fi

• Fixes/Updates
  • Minidlna would use a different uuid on every start. If your DLNA client tracked DLNA servers, this would result in multiple 'phantom' servers being shown as offline.
  • Dropbear: fix ability to link to SFTP server - @errorsys
  • Dropbear: include dropbearconvert utility
  • AICloud: pick up some changes tied to the update to lighttpd - @Grump

As always, a reminder to users with MIPS routers to have a backup of /jffs just in case!

SHA256

7f6bd98f71731749256c5036403a39929dd94e3a07dfdf9a6200d4c1f2fbd8fc  RT-AC68U_3.0.0.4_374.43_2-19B8j9527.trx
a2a14c05fdc664cd7da215b1f36889f1aec01c5376bc03edba71f714912092f2  RT-AC56U_3.0.0.4_374.43_2-19B8j9527.trx
6784e154b3a9c4723105c19659c01d0d3a215bcd210805ce88713692035a5879  RT-N16_3.0.0.4_374.43_2-19B8j9527.trx
db004792be04fd8fa4c4e7657a9b0c3bfe23f4887f2ec258db5bc7bbe55670ff  RT-AC66U_3.0.0.4_374.43_2-19B8j9527.trx
c12e9765a9fb7ac56030052d735d4d2a2e67ed46a085ff04a2d02421e93013ed  RT-N66U_3.0.0.4_374.43_2-19B8j9527.trx

 

[ColinTaylor]

• Fix bad iptable rule generation when using both Parental Controls and Network Services Filter - @Badlandz

Hi John,

Just tested this again and can confirm that it's fixed now. The 2 NSF-related rules are no longer being moved to the PControls chain. There were a few people that had been caught out by this in the past so I'm sure they'll be happy now. Is this something that needs to be applied to the current Merlin as well?

 

[john9527]

Hi John,

Just tested this again and can confirm that it's fixed now. The 2 NSF-related rules are no longer being moved to the PControls chain. There were a few people that had been caught out by this in the past so I'm sure they'll be happy now. Is this something that needs to be applied to the current Merlin as well?

First place I look for a fix when I identify a problem is the current Merlin In this case, nothing there, so yes I think this is something Merlin might pick up.

It looks like ASUS actually wanted to start doing something similar to what Merlin suggested above with respect to the iptables rules, but didn't quite get it right/completed.

 

[Badlandz]

Found another possible bug in Firewall>Network Services Filter:

I am unable to enter an asterisk into the fields to block all ranges. ex 192.168.*.*
It says its not valid. This did work at some point in the past fork versions.

 

[john9527]

Found another possible bug in Firewall>Network Services Filter:

I am unable to enter an asterisk into the fields to block all ranges. ex 192.168.*.*
It says its not valid. This did work at some point in the past fork versions.

Not a bug....a feature It was changed about a year ago to use CIDR notation instead for consistency with some of the newer features (as it says in the not valid popup). For example, for 192.168.*.* use 192.168.0.0/16

EDIT: I'll remove the now incorrect field help popup in the next release.

 

[Zapps]

I just learned about this fork but I'm on Merlin 380.61. Is it possible to revert now that I'm beyond the newer firmware format?

I tried to flash the latest non beta fork and well...I'm still trying to recover. [emoji27]

Sent from my Nexus 6 using Tapatalk

 

[john9527]

I just learned about this fork but I'm on Merlin 380.61. Is it possible to revert now that I'm beyond the newer firmware format?

I tried to flash the latest non beta fork and well...I'm still trying to recover. [emoji27]

Sent from my Nexus 6 using Tapatalk

Yes, with the ASUS Firmware Recovery Tool.
Power down the router, unplug any USB devices, and power up while holding in the reset button.
When the power light starts a slow blink, release the reset button and start the Recovery tool.
(You may need to assign a static address on your PC although I've never had to, see the docs on the ASUS website).

 

[Zapps]

Yes, with the ASUS Firmware Recovery Tool.
Power down the router, unplug any USB devices, and power up while holding in the reset button.
When the power light starts a slow blink, release the reset button and start the Recovery tool.
(You may need to assign a static address on your PC although I've never had to, see the docs on the ASUS website).

That did it.

The key for me was waiting 25 minutes for my N66U to complete the flash procedure.

Thanks for your assistance.

Sent from my Nexus 6 using Tapatalk

 

[gdalsnes]

Running 18E3. I think I see some strange things. IPv6 is not enabled, but i still get IPv6 DNS Server: 2a01:566:53f1:bc5c::1
I do not get this at my work pc (ipv4 only).
Windows console:
nslookup dlcdnet.asus.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 2a01:566:53f1:bc5c::1

---
In nslookup network tools on router it works:
Target: dlcdnet.asus.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name: dlcdnet.asus.com
Address 1: 178.164.7.238 178-164-7.238.3p.ntebredband.no
Address 2: 178.164.7.245 178-164-7.245.3p.ntebredband.no
---
Seems IPv6 is not completely disabled?
Update: ifconfig on router show no ipv6 address, so must be Windows... Google says Windows sometimes think it got a ipv6 connection (teredo etc.) and make up stuff, and also that nslookup on windows is broken...

Another thing:
In wan settings I changed to use google DNS: 8.8.8.8 \ 8.8.4.4 (LAN DNS is empty = use router), but after, nslookup network tools on router still show same output as above. Looks like WAN DNS settings are not effective? Or maybe effective to LAN clients but not router itself? (don't know how to find out).

 

[punchsuckr]

Well today my n66u has just completely shut down. No lights anywhere on the router or the hdds.. No changes made recently to the software.

The blue light on the power brick is on and stays on for quite a while after being disconnected.

Anyone else had this happen?! Its slightly more than 2 years old.

EDIT:
Oh well .. found plenty of posts with n66u's dying. Let the troubleshooting begin.. <sigh>

EDIT2:

Well that was quick.. the stupid power button is shot.. won't stick in the on state. Time for a toothpick repair it seems.

EDIT3:

And it lives on! That button isn't going anywhere now. Wonder why do they even put those damn things there.
The only reason this took the time it did was cause of the ultra optimized position i have it located in my house which takes it out of quick reach.

 

[Builder71]

Update-19B8

• Update OpenVPN to 2.3.12
• No longer dump the VPN status to the syslog when opening the status page
• ...

Thx for the update.

 

[Builder71]

...
EDIT2:

Well that was quick.. the stupid power button is shot.. won't stick in the on state. Time for a toothpick repair it seems.
...

On a lot of professional equipment you will not find a power switch, just for that reason!
Mine feels flimsy but still works.

Ohh, like your signature.

 

[punchsuckr]

On a lot of professional equipment you will not find a power switch, just for that reason!
Mine feels flimsy but still works.

Ohh, like your signature.

Thanks

They really shouldn't be used.. Just another failure point.

Seems it just spontaneously gave up and flung outward at some point during the night. I probably used it just once during its lifetime. Hopefully stuck in the fully depressed position isn't going to damage something else..

 

[punchsuckr]

Funny thing is in the short time between finding the router dead and fixing it, i was beginning to have grim thoughts of an RMA and asus loading up their latest official release which would have prevented me using @john9527 's fork