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

[User1000]

I just tried again. I disconnected everything (Went to adapter settings, right clicked wireless network connection, and clicked disable. I have no other cables attached except to the N66U Router and that isn't connected to anything but the power cable) and still got the IP address error. When I try to ping, I get:

C:\Windows\System32>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

This is the second try after I posted the last reply. The first try, windows update decided to restart my computer while I was in the other room. Should I try a Rescue Mode with the regular ASUS Firmware, then factory reset, and then try again?

 

[ColinTaylor]

The "PING: transmit failed. General failure." suggests that your PC's network interface is not configured. Did you remember to change your PC's network interface from DHCP to a static configuration?

https://www.asus.com/uk/support/FAQ/1000814/

 

[User1000]

Yup. It's on static.

Goddamnit I set it to 192.168.1.1 instead of 192.168.1.10

So now, another problem appears. I start the router in rescue mode, and when I hit upload file, the router doesn't stay in rescue mode.

When trying to access 192.168.1.1 from a browser, I get "This site cannot be reached 192.168.1.1 took too long to respond" and with ping I now get:

C:\Windows\System32>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

 

[ColinTaylor]

Are you sure it's in rescue mode? If it's in rescue mode the TTL from the ping will be 100, if it's booting up normally the TTL will be 64.

I prefer to start a continuous ping going in a window beforehand using "ping -t 192.168.1.1". Then when I attempt to put it into rescue mode I can see the TTL change to 100. At that point I know it's time to release the reset button. If you wait too long it will start to boot normally.

 

[ColinTaylor]

Personally I always had problems with the recovery utility. What I do is boot into recovery mode like you did (TTL=100). Then I open a browser and go to http://192.168.1.1 You should now see the CFE miniWeb Server. I upload the firmware from there. *** It will appear to timeout, but you just have to wait (up to 40 minutes in my case) ***

 

[User1000]

It's definitely in rescue mode. The point where it says "Request timed out" is when I hit the upload button, and then it isn't in rescue mode anymore.

C:\Windows\System32>ping -t 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=3ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Reply from 192.168.1.1: bytes=32 time=1ms TTL=100
Request timed out.
Request timed out.
Reply from 192.168.1.10: Destination host unreachable.
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=14ms TTL=64
Reply from 192.168.1.1: bytes=32 time=11ms TTL=64

I tried accessing the other way you suggested. It just brings up the typical "no internet" thing from Chrome. When I ping it, I get:

C:\Windows\System32>ping -t 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.10: Destination host unreachable.
Reply from 192.168.1.10: Destination host unreachable.
Reply from 192.168.1.10: Destination host unreachable.
Reply from 192.168.1.10: Destination host unreachable.
Reply from 192.168.1.10: Destination host unreachable.

Ping statistics for 192.168.1.1:
    Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Control-C
^C
C:\Windows\System32>

 

[ColinTaylor]

It's definitely in rescue mode. The point where it says "Request timed out" is when I hit the upload button, and then it isn't in rescue mode anymore.

Strange. So after the "Request timed out" message appears it looks like the router has booted up as normal (judging by the pings). Is that the case? Can you log into the router? What is the current firmware version that you're running?

Perhaps the partition layout of the flash memory is messed up from a previous firmware (I think DD-WRT might do this IIRC). If you have a syslog file could you upload it to pastebin.

 

[RMerlin]

If you get ping responses with 64 hops, then your router has booted into a working firmware.

 

[User1000]

Strange. So after the "Request timed out" message appears it looks like the router has booted up as normal (judging by the pings). Is that the case? Can you log into the router? What is the current firmware version that you're running?

Perhaps the partition layout of the flash memory is messed up from a previous firmware (I think DD-WRT might do this IIRC). If you have a syslog file could you upload it to pastebin.

I can't even access the GUI of the router. I've been trying to install the latest firmware from this post. (374.43) Before I had the firmware I downloaded from the ASUS website (Version 3.0.0.4.382.50702), and before I had that I had the ancient version of DDWRT that was installed on the router when I got it that I screwed up. The last functioning firmware was the ASUS one. I didn't test if it actually worked, but I could at least access the GUI.

 

[ColinTaylor]

I tried accessing the other way you suggested. It just brings up the typical "no internet" thing from Chrome. When I ping it, I get:

Sorry, I'm confused. Above this quote you are successfully pinging the router. Below the quote the pings are failing. What are these two different scenarios? Can you not access the router with a browser in scenario 1? Either the CFE when TTL=100 or the normal GUI when TTL=64?

 

[User1000]

I'm also confused. It seems to have a mind of its own.

Anyways, just turned the router off, then back on. Nothing else is connected to the router except the computer and the power cable, there are no other connections to my laptop, and the wireless adapter is disabled.

Ping test:

C:\Windows\System32>ping -t 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.10: Destination host unreachable.
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.1:
    Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
^C
C:\Windows\System32>

Attempting to access the GUI:

 

[john9527]

Your browser is converting the access to https (I HATE that feature on the new browsers in the name of security)

Clear your browser cache and cookies and try it again.

EDIT: I got so tired of this....I never access the router over https from my Firefox install, and use Chrome exclusively for https.

 

[User1000]

Your browser is converting the access to https (I HATE that feature on the new browsers in the name of security)

Clear your browser cache and cookies and try it again.

EDIT: I got so tired of this....I never access the router over https from my Firefox install, and use Chrome exclusively for https.

Wow. It was this simple the whole time.

 

[dave14305]

Wow. It was this simple the whole time.

A picture is worth 1,000 posts.

 

[Jack Yaz]

Your browser is converting the access to https (I HATE that feature on the new browsers in the name of security)

Clear your browser cache and cookies and try it again.

EDIT: I got so tired of this....I never access the router over https from my Firefox install, and use Chrome exclusively for https.

HSTS don't you love it? Can be cleared in chrome://net-internals

Had great fun with that when setting up some Web applications

 

[john9527]

Can be cleared in chrome://net-internals

That must be something that was added....at the time I banging my head against this 'help' by the browser, the only way to clear it was clearing cache. Thanks for the pointer!

 

[john9527]

The next release is out!
Note that we have jumped from V34 to V36 due to a rework of my repo. I'm still deciding how to handle the GIT update, so it will be a few days before that occurs. Users that have made a local copy of the repo will probably need to download a fresh copy.

Thanks to everyone who helped out in debugging/testing this release.

LATEST RELEASE: Update-36E4/36L4
27-September-2018
Merlin fork 374.43_36E4j9527
Download http://bit.ly/1YdgUcP
============================

Major changes (further details can be found in the first post of this thread):

• Fix for VPN Server logons failing with username/password auth on MIPS
• Updated releases of OpenSSL, dnsmasq, wget, curl and OpenPAM
• Stability improvements for DNS over TLS (DoT)
• Fix for disabling DoT via the gui breaking DNS in some configurations
• DDNS HTTPS support
• New QoS reserved minimum bandwidth settings for download
• New NTPD filter to force use of routers NTP server
• DNS rebind protection via the gui

SHA256

(Default Build - All supported routers)
a4d858d4aa6f5f16dc33f4dd3d6405fb88595f5d1130a263784b035fa8a908b2  RT-N16_374.43_36E4j9527.trx
0b1c4572da2e64543f4a99ef2af06bc6fa88f243534e061b60424951d9ed8135  RT-AC66U_374.43_36E4j9527.trx
763ce84a64b4708aad8f7628ba5ecea7951411c0a9f0f5f8df6e9e0e61013ef8  RT-N66U_374.43_36E4j9527.trx
807a6f4f2725eb5c478edb086db31541b20fa88f99321f621934194875be3f0d  RT-AC68U_374.43_36E4j9527.trx
47de0600eef2e5c321291a2aa7e07c86b709946886a41944f8edc5f009464235  RT-AC56U_374.43_36E4j9527.trx

(Legacy Only Builds)
e8a8ae0524bc5edec38010de8f41417bc7492e61df304e1429ddaec297558553  RT-AC68U_3.0.0.4_374.43_2-36L4j9527.trx
730cadcd044a046d292ccda91cb9db7c813ee8012c8cd5a79c95fecc4e272220  RT-AC56U_3.0.0.4_374.43_2-36L4j9527.trx
7878408d806077a7fe1ba93c957a46f64dd9f55caf4a1313524d3cf411103482  RT-N16_3.0.0.4_374.43_2-36L4j9527.trx
4a59f372a55cb74d4a82d588855e74b07389a6ad70eb65fb7381919981e75201  RT-AC66U_3.0.0.4_374.43_2-36L4j9527.trx
53b40aa38aecfd40bdecff5f113507503556df74c463d5239d6850c4cb89cbfc  RT-N66U_3.0.0.4_374.43_2-36L4j9527.trx

 

[blueshark]

perfect. One question: name of script to update stubby-resolvers.csv

 

[john9527]

perfect. One question: name of script to update stubby-resolvers.csv

stubby-update-resolvers.sh

The version in the code is the latest...

 

[blueshark]

stubby-update-resolvers.sh

The version in the code is the latest...

i restaure from 34E backup nvram and jffs part, its problably not the last resolver