[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[hifiwifi]

I have problems with pia vpn client, i get this error in the log

Oct 21 00:05:50 ovpn-client1[5495]: ERROR: Failed to apply push options
Oct 21 00:05:50 ovpn-client1[5495]: Failed to open tun/tap interface
Oct 21 00:05:50 ovpn-client1[5495]: SIGUSR1[soft,process-push-msg-failed] received, process restarting

Fallback cipher seems to be missing from client settings

I had a similar issue with this result in the log:
OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher (B'F-CBC') to --data-ciphers (currently 'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC') if you want to connect to this server.
I am using the PIA "next generation" OpenVPN config. It worked fine under 384.19. Adding the cipher resolved the problem.

 

[Nasua]

Have you tried to adding BF-CBC to your openvpn client 1 Data ciphers field, just like the first line in the log says? (the field should be:
CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC:BF-CBC )

Also, isn't BF-CBC the cipher that your openvpn client 1 uses to connect in 384.19? (maybe this is set in the Legacy/fallback cipher field, which is no longer used in 386.1_alpha2 as @RMerlin said above)

It is done automatically when I load the client certificate, I have also tried to add it manually, it is still rejected.
I also use PIA "next generation" OpenVPN config.

 

[Nasua]

I had a similar issue with this result in the log:
OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher (B'F-CBC') to --data-ciphers (currently 'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC') if you want to connect to this server.
I am using the PIA "next generation" OpenVPN config. It worked fine under 384.19. Adding the cipher resolved the problem.

Where did you add the cipher to make it work, can you post a screenshot please

 

[hifiwifi]

Where did you add the cipher to make it work, can you post a screenshot please

In the "negotiable ciphers" field, using the format with a colon. I put the BF-CBC first, followed by the colon, per their format. (I rolled back to 384.19, and this was no longer necessary).

 

[SomeWhereOverTheRainBow]

https://onedrive.live.com/?authkey=!AJLLKAY--4EBqDo&cid=CCE5625ED3599CE0&id=CCE5625ED3599CE0!19515&parId=CCE5625ED3599CE0!1427&o=OneUp

Available build(s)
RT-AC68U

386.1 (xx-xx-xxxx)
Switched to the new 386 codebase. Models are going to
gradually be re-added to this new code base.
386 introduces AiMesh 2.0, finalizes the move to
OpenSSL 1.1.1 firmware-wide, adds a new speedtest
(powered by Ookla). For more details, please refer
to Asus's own release notes

Merged 386_39179 binary blobs for
RT-AC86U, RT-AC68U, RT-AC5300 and RT-AX88U.

I am so tempted to test this at one of my locations, but I am also running jackyaz guest network script; with all these boasted changes asus has done, i do not want it to break anything with the guest network setup.
I guess my only concern is, has any one who uses Jack's guest network script tested this with running it?

 

[Blacklistedcard]

I don't think anyone on the Alpha is running Jack guest network script. At least I have not seen anyone mention it.

 

[Adamm]

PIA users will need to add the following to their "custom configuration" section on each VPN Client due to their custom OpenVPN implementation;

ncp-disable
cipher AES-128-GCM

 

[RMerlin]

PIA users will need to add the following to their "custom configuration" section on each VPN Client due to their custom OpenVPN implementation;

ncp-disable
cipher AES-128-GCM

Sadly my contact at PIA no longer works there, or I would have pinged him about this. Their server should definitely NOT be trying to use such an insecure cipher such as BF. Looks like a misconfiguration on their end preventing NCP from working properly. And NCP will become more or less required with OpenVPN 2.5, as the old cipher parameter is getting deprecated.

Asuswrt-Merlin 386.1 runs OpenVPN 2.5, and follows as closely as possible that version's recommendations. data-cipher is now the proper way to specify ciphers, and the ncp-disable setting as well as the cipher parameters are getting phased out (except for when using static key authentication, then the cipher parameter can still be used).

 

[Adamm]

Sadly my contact at PIA no longer works there, or I would have pinged him about this. Their server should definitely NOT be trying to use such an insecure cipher such as BF. Looks like a misconfiguration on their end preventing NCP from working properly. And NCP will become more or less required with OpenVPN 2.5, as the old cipher parameter is getting deprecated.

Asuswrt-Merlin 386.1 runs OpenVPN 2.5, and follows as closely as possible that version's recommendations. data-cipher is now the proper way to specify ciphers, and the ncp-disable setting as well as the cipher parameters are getting phased out (except for when using static key authentication, then the cipher parameter can still be used).

I think they are aware of the issue, when it will get fixed is another story.

https://www.reddit.com/r/PrivateInternetAccess/comments/iwvx3n

 

[Blacklistedcard]

Is anyone else running the alpha firmware and aimesh setup? I was wondering if you could confirm that your devices connected to a node and are getting valid ip addresses/working.

I still have not figured out why my devices are not getting valid IP address from the node even though the GUI is reporting the proper IP addresses.

I ssh into the node and checked the logfile. Looks ok.

 

[octopus]

Is anyone else running the alpha firmware and aimesh setup? I was wondering if you could confirm that your devices connected to a node and are getting valid ip addresses/working.

I still have not figured out why my devices are not getting valid IP address from the node even though the GUI is reporting the proper IP addresses.

I ssh into the node and checked the logfile. Looks ok.

Yes, Its working here. Get ip from master nod here.

 

[Blacklistedcard]

Yes, Its working here. Get ip from master nod here.

Thanks for confirming. I go back and see why mine is not working.

 

[RMerlin]

I think they are aware of the issue, when it will get fixed is another story.

It will probably become more of a problem once OpenVPN 2.5.0 comes out of beta. They are currently in a late release candidate stage, so it shouldn't be too long now. I expect they will be more willing to look into this when that comes out.

 

[SideSwipe]

That build was uploaded because Asus and I were testing a DHCP-related fix with a user who was affected by it. This should still be considered early alpha, and a lot will change in the coming weeks once I move to updated GPL code from Asus.

Is there any information as to what the DHCP related fix is?

I posted earlier in October about an issue with my AX58U and my phone, where the phone would seemingly not receive correct ARP information from the router until I reset the router. While I have since replaced the phone for unrelated reasons, I'm now encountering the same problem with my laptop, where after about 24 to 48 hours it will show as being connected to the router, but unable to communicate over the wireless network. I'm currently using build 384.18, but have also seen the problem on 384.19. My laptop is running Windows 10 using a Realtek 8822CE wireless adapter on the latest available drivers. Unfortunately I'm not sure what other troubleshooting/diagnostic steps to take as I'm still not entirely sure what is going wrong, and whether as one user theorised on the other thread if this is a driver issue on the router itself, or something else in the networking stack.

 

[RMerlin]

Is there any information as to what the DHCP related fix is?

Some ISPs (like Beeline using IPoE) were having trouble renewing their DHCP lease once it expired.

Has nothing to do with the LAN clients, only with the WAN connection.

 

[JohnD5000]

Can a dirty update be done, or do we need to start with a clean install?

 

[jsbeddow]

Can a dirty update be done, or do we need to start with a clean install?

It is strongly advised to do a clean install because this is based on a significantly revised/new code base (SDK): flash the new firmware, then factory reset, then configure from scratch (no importing of old config backups).

 

[SomeWhereOverTheRainBow]

It is strongly advised to do a clean install because this is based on a significantly revised/new code base (SDK): flash the new firmware, then factory reset, then configure from scratch (no importing of old config backups).

Can a dirty update be done, or do we need to start with a clean install?

yea you definitely want to start from scratch. It is best to. What I did was save my essentials as a backup of jffs and i manually copy over the stuff i need using an editor such as nano, but i did not load the backup'd settings config. Some people just screen shot settings as well to easily remember what they had saved.

 

[Vexira]

eh mabye they need a push, or asus needs to switch to a different qos solution.

 

[JohnD5000]

"Merged 386_39179 binary blobs for
RT-AC86U, RT-AC68U, RT-AC5300 and RT-AX88U. "

Does this mean we should have a RT-AC86U version soon?