What's new

Beta Asuswrt-Merlin 386.3 beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
On the VPN Client page, just above Custom Configuration.
bild screen.jpg


today is not my day...
I cannot see it...
sorry...
 
Beta 1 and 2 ran great on my AC3100 and AX58U. So where is Beta 3 ? :oops:
 
anyone know if 386.3_x fixed the issue with EEE randomly turning off?

I can force it back on through SSH on 386.2_4 but it always randomly turns back off. CPU temp difference is nearly 25C (low 70s vs mid 90s)
 
What router are you talking about? What is EEE? What do your tests conclude about the random issue?
 
Doesn't seem that important inside most homes (with such few Ethernet runs).
 
Doesn't seem that important inside most homes (with such few Ethernet runs).

Thats not the point the poster is looking to reduce the temp issue. I think Asus changed something with EEE to make the router run cooler and that change seems to revert itself.
 
What router are you talking about? What is EEE? What do your tests conclude about the random issue?

RT-AC86U.

Not sure what tests I'm supposed to perform (lol), the issue is pretty straight forward. I turn EEE on, it stays on for a bit, then turns off. I can turn it back on but it always eventually turns back off.

I typically don't SSH into my router on a routine so I dunno how long it stays on before it turns off, but it's at least a couple hours.

EEE is supposed to turn off when you enable QoS/fq_codel but I'm not using either. It should stay on, AFAIK.

Thats not the point the poster is looking to reduce the temp issue. I think Asus changed something with EEE to make the router run cooler and that change seems to revert itself.

pretty much. not a huge deal because I'm not throttling but it's a pretty significant increase in temperature for no reason.
 
already been done. happens on the factory firmware too. it's just a bug and/or because of some other setting conflicting with it that I'm unaware of, I'm just assuming the former.
 
Quick question: My goal is to have some redundancy on my VPN - if VPN-Server 1 goes down, the system will switch to VPN2, then VPN3. If all three servers are not reachable, the kill switch is supposed to kick in. My current setup is seen below. My questions would be, and any help is much appreciated:

1) Would these setting alow me the desired VPN redundancy?
2) Would VPN2 and VPN3 need to be set to ON? Or could I leave them OFF ("Stop Client"), and the router would switch them ON automatically if VPN1 goes down and it is looking to enforce policy rule no 2?
3) If they have to be switched ON for the redundant setup to work: Are the constantly connected to the VPN (as the status is "Connected")? My VPN provider only allows six connected devices - so having three connections from my router would be a shame.

1626646811000.png
 
Beta 3 has been uploaded. Changes since beta 2:
Code:
b450eefd91 Updated documentation
352ab973d5 inadyn: handle Freedns authentication errors as such; improve error logging
dbfafff825 openvpn: only set error state in nvram on fatal config errors
c157287738 libovpn: only enforce DNS exclusive for a client if the rule has no remote IP specified
8a80d88fa1 Bump revision to beta 3
2c88c8ee59 rc: remove code handling cleanup of old 1.xxx TrendMicro signatures
7a37a1eaed libovpn: add log message when creating RPDB rule for OVPN_RGW_ALL mode
 
BOOM!
 
Beta 3 has been uploaded. Changes since beta 2:
Code:
b450eefd91 Updated documentation
352ab973d5 inadyn: handle Freedns authentication errors as such; improve error logging
dbfafff825 openvpn: only set error state in nvram on fatal config errors
c157287738 libovpn: only enforce DNS exclusive for a client if the rule has no remote IP specified
8a80d88fa1 Bump revision to beta 3
2c88c8ee59 rc: remove code handling cleanup of old 1.xxx TrendMicro signatures
7a37a1eaed libovpn: add log message when creating RPDB rule for OVPN_RGW_ALL mode

Quick testing on Beta3 (dirty upgrade)
dbfafff825 openvpn: only set error state in nvram on fatal config errors
seems to have fixed my VPN issue we discussed and seems to be working as expected now.
 
Quick question: My goal is to have some redundancy on my VPN - if VPN-Server 1 goes down, the system will switch to VPN2, then VPN3. If all three servers are not reachable, the kill switch is supposed to kick in. My current setup is seen below. My questions would be, and any help is much appreciated:

1) Would these setting alow me the desired VPN redundancy?
2) Would VPN2 and VPN3 need to be set to ON? Or could I leave them OFF ("Stop Client"), and the router would switch them ON automatically if VPN1 goes down and it is looking to enforce policy rule no 2?
3) If they have to be switched ON for the redundant setup to work: Are the constantly connected to the VPN (as the status is "Connected")? My VPN provider only allows six connected devices - so having three connections from my router would be a shame.

View attachment 35086
1) yes
2) yes
3) yes

It seem to be configured fine, but with the old firmwares with such setting, I could not excluse a device or website from the chain.
I want also to know why. I have just installed the firmware now. I have not tested anything yet.

BTW I see the kill switch is configured to the last active client only, it is well configurated!
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top