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

[shauno100]

No, I wouldn't have expected any problems. I just double checked the led commands from the command line on my AC68P and they worked fine.

So, two questions.....
- Did you do a factory reset after loading this fork?
- What is the rev level of your AC68U? (only rev A1, A2 and B1 are supported....C1 and E1 are not)

Hi John,

The router is an A2 revision. I didn't actually do a factory reset which i should have so will do that tonight when i get home and let you know the outcome.

Thanks for the reply

Shaun

 

[atkinsom]

Hi John,

Running your latest released fork and using openvpn server on the router. I noticed something come up in the client logs on my PC when I connect that I'm not sure if it's something I should worry about. Should I add the auth-nocache line to the openvpn config file or just ignore the warning? thanks

"WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this"

 

[Deleted member 27741]

Glad to hear you figured it out.
I did a little playing, and was able to connect to PIA via pptp client...but found that the auto-negotiation for encryption wasn't working too well, and I had to force the right level via nvram, (exposing this to the gui was in a later level that I hadn't backported.....it is backported now )

You are a scholar and a saint, my man.

 

[krick]

I've never used OpenVPN before. Is there a guide somewhere that can help me set it up on this fork and figure out how to use it effectively?

 

[cybrnook]

Hi John,

Running your latest released fork and using openvpn server on the router. I noticed something come up in the client logs on my PC when I connect that I'm not sure if it's something I should worry about. Should I add the auth-nocache line to the openvpn config file or just ignore the warning? thanks

"WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this"

Add:

auth-nocache

to the additional options section at the bottom of the OpenVPN client config page.

 

[john9527]

Before anyone posts....the MAC vendor lookup is currently not working. Here is a quote from the provider we are currently using.

Due to the abuse of our API from several large companies and smart phone app creators who have incorrectly implemented our API, we are essentially being DDoSed.

At the moment, we have restricted MAC address lookups to our home page.

Not to worry! We are currently spinning up new servers and will have a temporary fix ASAP along with an updated website containing more features soon.

I'll be keeping on eye on things...

 

[jrmwvu04]

I loaded the beta and lost upload bandwidth, couldn't get above 1Mb and should have at least 10. Tinkered forever. Didn't work. Loaded 23E4, reset, didn't help. Tinkered. Still didn't work. At the three hour mark I finally had the idea to remove the router from the equation and the problem persisted.

So I noticed an unexplained (Comcast was not able to tell me why on two separate calls) random internet breakage at exactly the moment I tried beta firmware. Sooooooo.. it's finally working properly now and after reconfiguring from scratch for the 700th time, I am *pleased* to report everything working on 24B6.

 

[john9527]

I loaded the beta and lost upload bandwidth, couldn't get above 1Mb and should have at least 10. Tinkered forever. Didn't work. Loaded 23E4, reset, didn't help. Tinkered. Still didn't work. At the three hour mark I finally had the idea to remove the router from the equation and the problem persisted.

So I noticed an unexplained (Comcast was not able to tell me why on two separate calls) random internet breakage at exactly the moment I tried beta firmware. Sooooooo.. it's finally working properly now and after reconfiguring from scratch for the 700th time, I am *pleased* to report everything working on 24B6.

Strange to say the least. Only thing I can think of is that when the router rebooted and got a new IP it also got connected to a different set of equipment at Comcast, and that has a problem they don't know about (or acknowledge).

One other suggestion should this happen again is to try powering down your modem for about 15-30 minutes, which can cause a reset at Comcast's end.

 

[john9527]

Hi John,

Running your latest released fork and using openvpn server on the router. I noticed something come up in the client logs on my PC when I connect that I'm not sure if it's something I should worry about. Should I add the auth-nocache line to the openvpn config file or just ignore the warning? thanks

"WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this"

Depends on your level of paranoia and annoyance with the message
The client by default caches your credentials to speed up auth renegotiatons. If someone were to hack your client, they could conceivably do memory dumps and get your credentials.

For me, I got tired of seeing the message, so set the auth-nocache option

BTW - It also shows up when running the OpenVPN client on the router.

 

[jrmwvu04]

Strange to say the least. Only thing I can think of is that when the router rebooted and got a new IP it also got connected to a different set of equipment at Comcast, and that has a problem they don't know about (or acknowledge).

One other suggestion should this happen again is to try powering down your modem for about 15-30 minutes, which can cause a reset at Comcast's end.

Yeah that was among the things I tried after ruling out the router as the problem, having seen Merlin suggest it in other threads. I left it unplugged overnight and even set up and used a different modem.

All they want to do is reset the modem over and over, but that's a rant for some other time. The pertinent info is that my scripts work, QoS works, and as far as I can tell to this point everything is smooth.

 

[john9527]

I see a couple of folks have loaded the beta with Busybox 1.25.1 on AC68's. Anybody with an N18, N66 or AC66 tried it?

 

[john9527]

I've never used OpenVPN before. Is there a guide somewhere that can help me set it up on this fork and figure out how to use it effectively?

What kind of setup are you looking at? Running an OpenVPN server on the router, a site-to-site VPN, or connection to a commercial VPN provider?

For the latter, do a search for posts by @yorgi or @Xentrk who have written up some guides. For the others, I don't recall a single guide being written up.

 

[RMerlin]

Before anyone posts....the MAC vendor lookup is currently not working. Here is a quote from the provider we are currently using.


I'll be keeping on eye on things...

Asus's own database remains a good alternative.

(which reminds me, been a while since I've updated it).

 

[Deleted member 27741]

Look, John- there is a "problem" with the y axis of the temp graph...

 

[john9527]

Asus's own database remains a good alternative.

(which reminds me, been a while since I've updated it).

Yeah.....I'm looking at it now. Minor problem is that the structure of the .js files has changed a lot from the fork, and I need to decide the best place to put things. I'll also watch for you to update the db

BTW.....Good catch on the second use of stop_gmac3!

 

[RMerlin]

Yeah.....I'm looking at it now. Minor problem is that the structure of the .js files has changed a lot from the fork, and I need to decide the best place to put things. I'll also watch for you to update the db

I just checked, and Asus hasn't updated it since last time. They did update it at least once last year. Hopefully they won't let it fall too far behind.

Note that the GPL and my implementations are different. Asus directly accesses it remotely, which creates browser warning whenever accessing the webui over https (as their download server is http-only). That's why I chose to include it in the firmware itself. You'll probably need to deal with the difference in lookup code indeed.

As for its size, don't worry too much - it's highly compressible by LZMA. Might have a small impact at page load time, however lookups themselves will be near instantaneous - one of the things I love about it.

BTW.....Good catch on the second use of stop_gmac3!

Thanks. I knew about the second similar function due to my work on fixing MAC retrieval for rstats/cstats a few months ago, so I figured I'd better check if there was also a gmac3 reference in it as well.

For reference, that bug still exists in GPL 382 as well... They didn't define the missing vars in their revamped defaults.c either (the new defaults.c now defines a lot of metadata for each variable, such as its type of data).

 

[RMerlin]

Look, John- there is a "problem" with the y axis of the temp graph...

Your temperature is unusually low. Sadly, the temperature range of these routers can go from 40C to 100C, which means if you want to have any accurate graph, you have to restrict the scale, otherwise the 1-2C variations woulnd't be visible.

 

[wiz]

Add:

auth-nocache

to the additional options section at the bottom of the OpenVPN client config page.

You are right. However, when the time comes that the certs get checked again you will have to put in your password again. I had the "auth-nocache" added and removed it again as you have to put in your password periodically at the most inconvenient times...

 

[cybrnook]

You are right. However, when the time comes that the certs get checked again you will have to put in your password again. I had the "auth-nocache" added and removed it again as you have to put in your password periodically at the most inconvenient times...

I will have to look into that. I use that option at home because I also did not like the look of the log message, but I have not noticed an issue with my tunnel not being able to renegotiate. Will keep a closer eye on it.....

 

[cowst]

Hi John, I have an issue since 374.43_2-23E3j9527.
One of m devices (my linux satellite receiver) after a while loses internet connectivity.
It is actually connected to the router and has the usual local IP, but cannot get out.
A router reboot solves it.

I sent you a PM with the syslog.