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

[blueshark]

Logs are worth a thousand words. Specificity of conditions and logs are needed or else these complaints can be worthless. I think John eluded to this already.

There is no log. When i set vpn dns exclusive is not getting provide dns. Not complaint and your reply is not useful

 

[john9527]

Hi,

Thanks for keeping my old AC66U's firmware up-to-date

A simple user's question: In the more recent versions, including the official - you can set a radio-off schedule which you could control at 1h or 1/2h intervals, I don't remember exactly.
This allowed me to turn the wifi off during the night from 01:00am to 06:30am.

With the latest 36E4 - the UI only allows setting a single continuous timeframe in which the radio is on - so I can keep it up between 06-00 but not 06-01 of the next day.
I didn't find anything relevant in this thread nor in the options txt file - but might have missed it.

Any simple way I could achieve the same with your firmware?

Thanks,
Mor

It sounds like ASUS made an update allowing you to span days....I'll have to take a look at what they did and if I can backport the change.

 

[john9527]

Hi @john9527

I don't know whether it's always done this but I've just noticed that if my WAN connection goes down after it comes back up a new udhcpc process is spawned but the previous one is still running. I wouldn't normally see this because my internet is usually pretty reliable.

RT-AC68U V36E4

# ps w | grep udhcpc | grep -v grep
 2522 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
 4043 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
 5944 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
 7392 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
11347 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
15335 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
21373 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
25681 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249
29242 admin     1428 S    udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249

Must be a sneaky error path....I looked at the code and it appears it should be killing the old instance. I've added a 'catchall' to make sure the prior instance is always killed when starting a new instance.

 

[ColinTaylor]

Hi John,

Can you give me a sanity check please regarding the "Save setting (NVRAM)" file. Has something changed with this recently? BTW I'm still on v36E4.

OK John I think you can ignore this.

As far as I'm able to tell there was some sort of corruption of my NVRAM variables. It seemed to sneak in when testing the v34 release. I can't prove it but it looks like it might have been the vpn_server1_custom variable that was the root cause. Perhaps a null byte got stuck in there by mistake.

Anyway, now that I've effectively "cleansed" my NVRAM I'm able to create a working save file again.

 

[john9527]

OK John I think you can ignore this.

Whew....thanks for the follow up. I did about 5 saves through the day on v36 and they were all OK, so I was scratching my head.

 

[mymatenige]

Hi,

I've just updated to 36E9 on an RT-AC66U. Everything is working fine, apart from OpenVPN.

The system log seems to be filled with:

Oct 29 21:12:51 openvpn[4368]: hostname/ipaddress:5773 IP packet with unknown IP version=15 seen

I believe that this can be caused by client/server configuration mismatch.

Apart from the upgrade, I've not changed any settings on the client or server.

The changelog suggests that only lz4-v2 was added. I've checked and both client and server are set to lz4.

I noticed these lines in the logs as well. Not sure if they were present before the upgrade.

Oct 29 21:11:50 openvpn[4368]: ip:5773 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1542'
Oct 29 21:11:50 openvpn[4368]: ip:5773 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Oct 29 21:11:50 openvpn[4368]: ip:5773 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

Ideas?

Regards,
Nige.

 

[john9527]

Ideas?

Not much to say....your client/server settings do not match.

It sounds as if you have control over both the client and server? Can you tell us more about your configuration.

 

[mymatenige]

It sounds as if you have control over both the client and server? Can you tell us more about your configuration.

Okay, thanks John. That's all I needed to unpick it.

As a client I am using Tunnelblick 3.7.7 on Mac OS X which includes OpenVPN 2.4.6. I am also using OpenVPN Connect on Android. Everything was fine using 36E4. After an upgrade from 36E4 to 36E9, both client types can connect to my router but all traffic was failing.

Following your message I changed the server and client config from LZ4 to LZO and then normal service has been resumed. I changed them both back to LZ4 and it stopped again. I don't know why LZ4 isn't working any longer, but I can live with LZO.

 

[john9527]

Following your message I changed the server and client config from LZ4 to LZO and then normal service has been resumed. I changed them both back to LZ4 and it stopped again.

Hmm...let me double check the backport I did of the lz4-v2 support....

 

[slobodan]

Hmm...let me double check the backport I did of the lz4-v2 support....

There is a CVE about compressed VPN, maybe the provider has disabled compression.

 

[john9527]

@mymatenige @slobodan
I flubbed the backport on the lz4-v2 support (referenced the wrong buffer) Things aren't always consistent between the latest Merlin and this fork anymore.
Both lz4 and lz4-v2 will be be broken until the next release.

 

[Mr_Andy]

I have an N66u and is running latest V36E9

I've been testing the OpenVPN server on this router with OpenVPN Connect client for Android. while it connects and works fine, I have found that the router seems to be not using username and password for authentication, it connects with any username/password I enter in the Android client, which don't exist on the router. it's like it's ignoring the username I set up and just using a certificate?

how can I force it to use both the certificate and username/password ?

 

[ColinTaylor]

how can I force it to use both the certificate and username/password ?

I suppose I have to ask the obvious question. Do you have "Username/Password Authentication" = Yes and "Username / Password Auth. Only" = No.

 

[john9527]

it connects with any username/password I enter in the Android client, which don't exist on the router. it's like it's ignoring the username I set up and just using a certificate?

When I redid the username/password auth for MIPS I tested with bad username/password so it should be working. Just to be safe, try deleting the info from the server setup and re-add the username/password info.

 

[Mr_Andy]

I suppose I have to ask the obvious question. Do you have "Username/Password Authentication" = Yes and "Username / Password Auth. Only" = No.

that's correct, currently set to

Authorization Mode = TLS
Username/Password Authentication = Yes
Username / Password Auth. Only = No

 

[Mr_Andy]

When I redid the username/password auth for MIPS I tested with bad username/password so it should be working. Just to be safe, try deleting the info from the server setup and re-add the username/password info.

I have removed and re-added credentials but can still log on with any username/password

 

[Mr_Andy]

I have removed and re-added credentials but can still log on with any username/password

in the router logs it states " TLS: Username/Password authentication succeeded for username 'testuser' " but the user testuser does not exist

 

[john9527]

in the router logs it states " TLS: Username/Password authentication succeeded for username 'testuser' " but the user testuser does not exist

Thanks for reporting this.....and my apologies to everyone for my inadequate testing. I had tested bad username rejection by mangling my username with extra characters instead of a new random username.
I'll have a new release up today with a fix.

 

[RMerlin]

Thanks for reporting this.....and my apologies to everyone for my inadequate testing. I had tested bad username rejection by mangling my username with extra characters instead of a new random username.
I'll have a new release up today with a fix.

Anything I need to test on my side as well, or was it a regression on your end?

 

[john9527]

Anything I need to test on my side as well, or was it a regression on your end?

Nothing on your end. Was introduced in my replacement username/password auth for MIPS (stubby/DoT was creating a segfault in the default openvpn auth plugin on MIPS)