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

[fink.nottle]

It's a real mess with the model id's now. ASUS shipped some pre-C1 boxes with the 1GHz processor as well. As Forrest Gump would say.... 'It's like a box of chocolates, you never know what you are gonna get'

What's the command to verify compatibility once I get it ? I don't even remember if they allow ssh out of the box.

 

[john9527]

What's the command to verify compatibility once I get it ? I don't even remember if they allow ssh out of the box.

I've been watching the forums, and I'm not sure anyone has come up with a way other than looking at the box labels.

I'm not sure about stock ssh either, but telnet should be supported Here's a check that I think will exclude from the fork, but I'm not sure about the other way around.

nvram get cpurev

if the string coming back contains 'C0', the fork is a no-go.

 

[fink.nottle]

I've been watching the forums, and I'm not sure anyone has come up with a way other than looking at the box labels.

I'm not sure about stock ssh either, but telnet should be supported Here's a check that I think will exclude from the fork, but I'm not sure about the other way around.

nvram get cpurev

if the string coming back contains 'C0', the fork is a no-go.

Thanks. I'll post the info that I can glean from the box as well as the cpurev once I get it.

 

[RMerlin]

Fork doesn't work at all....it needs a new SDK. Latest Merlin from some level of 378 I believe picked up the C1 support.

C1 support came with 380.

 

[john9527]

C1 support came with 380.

Many thanks for the correction

 

[linuxares]

Do you happen to know if the mysterious E1 version works with this fork? I presume it doesn't since C1 doesn't work.
I picked up one yesterday and it was loads and loads of boxes with E1. I could only find one single A2 unit. No C1 or B1 versions. So it would seem that E1 is the new revision now.

 

[john9527]

Do you happen to know if the mysterious E1 version works with this fork? I presume it doesn't since C1 doesn't work.

AFAIK, E1 is also a no-go.

@RMerlin, is this something I could pick up? Not sure of everything that would be required. I did try and figure it out once, but failed miserably.

 

[RMerlin]

AFAIK, E1 is also a no-go.

@RMerlin, is this something I could pick up? Not sure of everything that would be required. I did try and figure it out once, but failed miserably.

I'm not sure. Shibby has been trying recently, part of the problem is that the new SDK includes drivers compiled with the Trend Micro support. I don't know how far he's gone, haven't heard from him in a few weeks now, most likely busy with real life stuff. He seemed to have been making progress however last time we spoke.

Basically, you need the SDK (src-rt-6.x.4708/* ) as well as all Broadcom-related binary blobs (acsd, emf, libbcmcrypto, etc...). You will also need the latest kernel sources (and double check for any difference in config_base.6a content, to ensure your kernel symbols still match).

 

[john9527]

Shibby has been trying recently,

I saw that Shibby pushed a new armv7 branch....but there haven't been any updates to his git repo since 1-August. Hope he's doing OK.

 

[RMerlin]

I saw that Shibby pushed a new armv7 branch....but there haven't been any updates to his git repo since 1-August. Hope he's doing OK.

We last discussed the SDK case back in early November. He had been making progress, but still had unresolved issues revolving the updated WL driver.

 

[sfx2000]

We last discussed the SDK case back in early November. He had been making progress, but still had unresolved issues revolving the updated WL driver.

There were some IOCTL's that changed - and this is a general linux problem...

Maybe roll back to last known good ones?

 

[RMerlin]

There were some IOCTL's that changed - and this is a general linux problem...

Maybe roll back to last known good ones?

I think you missed the beginning of this conversation...

 

[Andi P]

Hi all,

very happy user of this fork since I bought my AC68 router a while ago. Really pleased with the development on it and the expertise in this thread.

Now, coming from a Draytek Vigor router previously, I am missing one smart function Vigor had:
It could be configured, only devices with known MAC addresses (put into the DHCP static IP table) were able to access the internet connection.
All other devices still got a valid IP via DHCP, but if their MAC was not registered, they could not do anything.

Just wondering if anything similar would exist for that?

(I know I can block IP traffic for my DCHP area, and maybe this is what I would do next; but it is not the same, because even is someone used a static IP configured on the device, he could not access the internet. So misuse was pretty hard. Just wondering, sometimes people have really smart ideas on how to achieve something).

Have a great day, thanks!

Andi

 

[ColinTaylor]

@Andi P I guess that when you say "I can block IP traffic for my DCHP area" you are referring to the Network Services Filter (?) which is indeed based on IP addresses. You could try using Parental Control as that is based on MAC addresses, but the default action for devices not in the list is to allow full access to the internet. So it looks like what you want can only be achieved by writing a custom script. But that would be fairly cumbersome to maintain.

 

[Andi P]

@Andi P I guess that when you say "I can block IP traffic for my DCHP area" you are referring to the Network Services Filter (?) which is indeed based on IP addresses. You could try using Parental Control as that is based on MAC addresses, but the default action for devices not in the list is to allow full access to the internet. So it looks like what you want can only be achieved by writing a custom script. But that would be fairly cumbersome to maintain.

Thanks, thought so. Not easy to achieve, if at all.

Andi

 

[john9527]

Pushed a new refresh to the beta....
So far, so good on the new traditional QoS implementation, so no changes there
But, it does include another new function for some initial testing

BETA RELEASE: Update-22B6
13-December-2016
Merlin fork 374.43_2-22B6j9527
Download http://bit.ly/1UGjcOX
============================

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

Update-22B6 Highlights

• Support for DNSCrypt
  A couple of notes on the DNSCrypt implementation
  • The option is located on the WAN > Internet Connection page
  • Doesn't use any shell scripts or hardcoded IP addresses
  • The dnscrypt-resolvers file with the keys is placed in read-only memory during build for security
  • If DNSCrypt is enabled, all boot DNS access will be through the DNSCrypt resolver, including NTP time sync
  • Integrated with the OpenVPN Client (if DNSCrypt is active, there is a new DNSCrypt option for the OpenVPN DNS)
    Note: If you select Relaxed, Strict or Exclusive for the VPN DNS Configuration, DNSCrypt will NOT be used even if enabled.
  • Only a single DNSCrypt server using IPv4 is currently supported (the IPv6 servers are filtered out from the selection pulldown).
  • If you try and enable both DNSSEC and DNSCrypt, the available DNSCrypt servers are filtered to only show those that also support DNSSEC
• Updated OpenVPN to 2.3.14

Update-22B4 Highlights

• Thanks to RMerlin for the 'howto' in his latest build, QoS Statistics graphs are available for the new traditional QoS!
• Updated OpenVPN to 2.3.13
• Misc other backports from the latest Merlin build

Update-22B2 Highlights

• A completely rewritten Traditional QoS
  This traditional QoS implementation should work more like one would expect based on the QoS rules. There is no change to the user interface....all the changes are 'under the hood'. Special thanks to @ColinTaylor for helping to test the QoS changes.
  • Overall Download/Upload limits are honored
  • Download/Upload percentage limits and priorities are enforced based on the priority levels
  • A couple of things to note
    • Rule order matters...rules are enforced 'top to bottom'. For example, with the following rules
      1. HTTP port 80 set as high priority
      2. Specific client set as low priority
      the HTTP rule will take precedence, therefore the low priority client will still process HTTP requests as high priority.
    • Rules specifying an address range will only apply to IPv4 and not IPv6 (when IPv6 is enabled). Using the pulldown to specify a specific client, will use the MAC address in constructing the rules, so will apply to both IPv4 and IPv6.
    • Users with ARM routers are recommended to use the FQ_CODEL queuing discipline (which is now the default if you perform a factory reset). With the QoS changes, there are definite improvements with FQ_CODEL over SFQ.
    • If the router OpenVPN Client is active, any clients using the VPN connection will use the default priority setting. Setting specific rules for VPN clients can entered, but will be ignored when the VPN is active.
• An update to allow MIPS based routers to properly process iptables rules using set-mark with a mask. This should eliminate problems for those writing custom iptables rules or in certain combinations of router options, such as using Merlin NAT loopback with url or keyword filters.
• An experimental change to allow JFFS to be formatted on ARM based routers with bad blocks in the JFFS space.
• A fix to fully support encrypted FTP (manual setup still required)

As always, a reminder to users with MIPS routers to have a backup of /jffs in case the jffs space needs to be reformatted due to increases in firmware size.

SHA256

2688de1c46b96d80e5741fa3f7617d31109b2dc37e3b4aa34d00982bbe17f3d9  RT-AC56U_3.0.0.4_374.43_2-22B6j9527.trx
2afc3286794dee8990037a8a95db3c3c4fb02ccf720d6005d25212ab29bf73d7  RT-AC66U_3.0.0.4_374.43_2-22B6j9527.trx
27b3615369fffd6058bd05f36b5e94d8ee005fd0d9ed007c6cc9c38b9dab3051  RT-AC68U_3.0.0.4_374.43_2-22B6j9527.trx
eac291c1b26616659eb1b6fcef58c108552ffbfe6eb3884cae1e69cbf8a0dfdc  RT-N16_3.0.0.4_374.43_2-22B6j9527.trx
cd77f7895ff1c7f19f4ae31040754693064570fbc28a1621004c107045224bd8  RT-N66U_3.0.0.4_374.43_2-22B6j9527.trx

 

[cybrnook]

There it is


If DNSCrypt is enabled, will it disable IPV6?

 

[tomsk]

There it is


If DNSCrypt is enabled, will it disable IPV6?

Looks very interesting... I've been on main Merlin fork since I've had this router, but I'm actually quite tempted to try this fork just to see how it stacks up against the entware installed version of DNScrypt i have running now.... how will it play with dnsmasq/AB-solution when using a VPN tunnel as compared to going through the WAN?

 

[john9527]

There it is


If DNSCrypt is enabled, will it disable IPV6?

No....that turned out to be a red herring. The Windows IPv6 got hosed up with me taking the interface up and down some many times.

But....there is a plug-in for DNSCrypt that will give some options there......it's on my list

 

[cybrnook]

No....that turned out to be a red herring. The Windows IPv6 got hosed up with me taking the interface up and down some many times.

But....there is a plug-in for DNSCrypt that will give some options there......it's on my list

If we are only specifying (for example) OpenDNS's IPV4 DNSCrpyt server, I assume IPV6 lookups will still route over your default (ISP provided etc...) IPV6 DNS server? So only IPV4 lookups will use the service?