Experimental BcraFFY (OpenSSL 1.1.x) builds

[XIII]

I might give that another try this weekend (I failed today).

I managed to build the firmware and OpenSSL-1.1.x for my AC-86U (tip for other newbies: make sure you convert spaces to tabs for aligning in the Makefile).

Unfortunately I'm unable to compile unbound against this OpenSSL library:

configure: error: OpenSSL found in /home/parallels/asuswrt-merlin.ng/release/src-rt-5.02hnd/bcmdrivers/broadcom/net/wl/bcm94908/main/src/router/openssl-1.1.x, but version 0.9.7 or higher is required

If anyone knows how to fix this I would love to learn.

 

[sfx2000]

I know. They use the same patch as me.

Heads up - recent OpenWRT/Master checkin/commit

commit ddee1825de2a9c472f8bffc9ff3097f6421842a8
Author: Eneas U de Queiroz <cote2004-github@yahoo.com>
Date:   Fri Feb 15 22:35:19 2019 +0000

    openssl: patch to fix devcrypto sessions leak

    Applies a patch from https://github.com/openssl/openssl/pull/8213
    that fixes an error where open /dev/crypto sessions were not closed.
    Thanks to Ansuel Smith for reporting it.

    Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>

 

[sfx2000]

spaces to tabs

Grrrr...

https://www.businessinsider.com/tabs-vs-spaces-from-silicon-valley-2016-5

 

[RMerlin]

Heads up - recent OpenWRT/Master checkin/commit

commit ddee1825de2a9c472f8bffc9ff3097f6421842a8
Author: Eneas U de Queiroz <cote2004-github@yahoo.com>
Date:   Fri Feb 15 22:35:19 2019 +0000

    openssl: patch to fix devcrypto sessions leak

    Applies a patch from https://github.com/openssl/openssl/pull/8213
    that fixes an error where open /dev/crypto sessions were not closed.
    Thanks to Ansuel Smith for reporting it.

    Signed-off-by: Eneas U de Queiroz <cote2004-github@yahoo.com>

I don't use cryptodev.

 

[QuikSilver]

Curiosity got the best of me. Upgraded to test build, everything seems to be running fine. Not using the router for anything special though. Will update if anything odd jumps out.

 

[QuikSilver]

Odd thing happened this morning. Everything working fine yesterday but this morning nothing was working. Long story short it seems the router reset itself to factory. I connected to the open Asus wifi (was even a privatewifiranger SSID?) and reconfigured everything. Everything back up but found that extremely odd. Any ideas what may have caused it. Don't believe a surge (its plugged into a battery backup) or storm came through or if that would have reset it somehow.

 

[RMerlin]

Odd thing happened this morning. Everything working fine yesterday but this morning nothing was working. Long story short it seems the router reset itself to factory. I connected to the open Asus wifi (was even a privatewifiranger SSID?) and reconfigured everything. Everything back up but found that extremely odd. Any ideas what may have caused it. Don't believe a surge (its plugged into a battery backup) or storm came through or if that would have reset it somehow.

Could be nvram corruption. Can happen for example if you were running out of nvram.

 

[QuikSilver]

Could be nvram corruption. Can happen for example if you were running out of nvram.

Anything I could look out for to make sure it doesnt do it again? I was torrenting a new linux build. Too many connections possibly?

 

[RMerlin]

Anything I could look out for to make sure it doesnt do it again? I was torrenting a new linux build. Too many connections possibly?

A network-related issue couldn't lead to that kind of problem. Just make sure you don't run out of nvram, on the Tools/Sysinfo page.

 

[QuikSilver]

A network-related issue couldn't lead to that kind of problem. Just make sure you don't run out of nvram, on the Tools/Sysinfo page.

Thank @RMerlin, Would having a scheduled reboot help alleviate that if it does get high over time?

 

[L&LD]

Thank @RMerlin, Would having a scheduled reboot help alleviate that if it does get high over time?

It will mask the underlying issue(s). In this case, I would be looking for the root of the problem instead.

While the router may have reset itself, I would have also done a full reset to factory defaults, intentionally, afterward.

Including an NVRAM reset and a format jffs on next reboot command (reboot the router at least 3 times, waiting about 5-10 minutes in between for it to settle down and finish its internal setup/shuffling after each reboot).

 

[QuikSilver]

It will mask the underlying issue(s). In this case, I would be looking for the root of the problem instead.

While the router may have reset itself, I would have also done a full reset to factory defaults, intentionally, afterward.

Including an NVRAM reset and a format jffs on next reboot command (reboot the router at least 3 times, waiting about 5-10 minutes in between for it to settle down and finish its internal setup/shuffling after each reboot).

Thanks @L&LD , I'm leaning towards a possible power surge as I had a couple quirky items I've noticed since then.

 

[RMerlin]

admin@rtac5300:/tmp/home/root# /usr/lib/ipsec/starter --daemon charon
Starting weakSwan 5.7.2 IPsec [starter]...

 

[RMerlin]

I'm uploading test2 builds. In addition to a number of performance optimizations to OpenSSL 1.1.1 and general size optimization. A large portion of the past week was spent upgrading strongswan from 5.2.1 to 5.7.2, required for OpenSSL 1.1.1. It was a fairly major project (and thankfully I had help for the most technical portions of it, such as the kernel patching that was required along the way for proper HND support). But in the end, aside from having the latest strongswan version in the firmware, we were also able to significantly reduce the size of the HND build (as we are now able to link it against the regular 32-bit shared library, instead of a static-linked 64-bit version).

The new strongswan will require extensive testing. I already tracked down and resolved one new issue that was introduced by the update (Android's native client only supported older DH parameters that were no longer enabled by default in 5.7.2), however other clients will also require testing.

Again, note that these are experimental builds. So far the results have been positive enough for me to seriously consider merging that into 384.10, regardless of the minor performance loss in certain applications. In the long run it will eventually become a necessary move anyway, as OpenSSL 1.0.2 will reach EOL at the end of this year.

 

[Marin]

I'm uploading test2 builds. In addition to a number of performance optimizations to OpenSSL 1.1.1 and general size optimization. A large portion of the past week was spent upgrading strongswan from 5.2.1 to 5.7.2, required for OpenSSL 1.1.1. It was a fairly major project (and thankfully I had help for the most technical portions of it, such as the kernel patching that was required along the way for proper HND support). But in the end, aside from having the latest strongswan version in the firmware, we were also able to significantly reduce the size of the HND build (as we are now able to link it against the regular 32-bit shared library, instead of a static-linked 64-bit version).

The new strongswan will require extensive testing. I already tracked down and resolved one new issue that was introduced by the update (Android's native client only supported older DH parameters that were no longer enabled by default in 5.7.2), however other clients will also require testing.

Again, note that these are experimental builds. So far the results have been positive enough for me to seriously consider merging that into 384.10, regardless of the minor performance loss in certain applications. In the long run it will eventually become a necessary move anyway, as OpenSSL 1.0.2 will reach EOL at the end of this year.

@RMerlin, do you recommend performing router restores after upgrading to each of these builds? Thank you.


Sent from my iPhone using Tapatalk

 

[L&LD]

@RMerlin, do you recommend performing router restores after upgrading to each of these builds? Thank you.


Sent from my iPhone using Tapatalk

I think you mean resets? I would say, yes. If you're serious about finding true bugs in these experimental builds.

 

[Marin]

I think you mean resets? I would say, yes. If you're serious about finding true bugs in these experimental builds.

Yes that is what I meant, thank you. I know many folks here usually do dirty upgrades with most alpha/beta setups and wait to restore/Initialize their routers only when jumping to a new firmware version. My configuration is very simple, so I don’t mind restoring to defaults and manually reconfiguring everything from scratch again.


Sent from my iPhone using Tapatalk

 

[sbsnb]

And remember, for long, tedious settings such as static DHCP lists, etc., you can copy/paste NVRAM values using SSH. Just don't try to copy paste your entire old NVRAM, that defeats the point of reset.

 

[RMerlin]

@RMerlin, do you recommend performing router restores after upgrading to each of these builds? Thank you.

No, the changes are strictly at the software level, there has been no configuration changes between those test builds.

 

[Marin]

No, the changes are strictly at the software level, there has been no configuration changes between those test builds.

Thank you!


Sent from my iPhone using Tapatalk