Asuswrt-Merlin - Project update

[RMerlin]

I guess the folks at Asus didn't appreciate that you maintained it better than they did. Either way, is it possible for you to maintain networkmap separately in the same way that you plan to maintain OpenVPN?

Not really, as Asus re-implemented portions of networkmap. Data is now stored in a json format for instance, and too many pieces of the firmware need to interact with this.

All very clear and sensible, I find it hard to believe Asus also haven't moved the MIPS based routers into a security only 'care and maintenance' role, they have kept updating for a very long time compared to other manufacturers

I was told that the RT-N16 would not be moved to the 382 codebase. I assume that means that the N66U is still considered fully supported, altho I have seen them reduce the frequency of firmware releases for the N66U/AC66U these last two years. This is what will make it hard for me to keep supporting them, as I need the binary files from these to be able to support them when a new GPL release comes out for other models.

Suspect a lot of pressure to make Asus proprietary firmware unusable on other manufacturers hardware

I've said it many times in the past - I blame in large part the current move to closed sourceness to projects such as Xvortex and Koolshare. I can understand Asus wanting to protect their IP. And the software is in large part what gets Asus sales for their router, as the hardware itself is more or less identical to competitors.

I hope they are being careful with the strict interpretations of the various GPL licences, but I'm not sure it is still in the spirit...

They assured me that the open source community was important to them, and that they were looking in finding ways to better interact with it. Whether they will find a way or not remains to be seen. This might be a situation where marketing, engineering and legal departments all have very different opinions. Marketing says it help selling routers. Engineering says it allows them to reuse code and security fixes from the community. And legalese will say: "we don't want anyone to be able to see ore reuse what we invest in, keep this all behind closed doors". I imagine it's not easy to juggle this all.

Asus could have easily closed down everything. From what little I've seen, Broadcom's new platform allows for secure boot support, which would have prevented ANY third party firmware from running on the HND platform, but Asus chose not to go down that route.

In general, I'd say Asus has been far, far more cooperative with the open source community than all other manufacturers combined. TP-Link tried to shut them out entirely, only to be told by the FTC that they couldn't (to my biggest surprise). Netgear has the bulk of their firmware code closed-source, except where it's GPL code from a third party (like dnmasq). Linksys might be the ones closest to Asus there, with how they handled the new WRT line of products (although they started their relationship with the OpenWRT community on the wrong foot - that has since been corrected as far as I know).

 

[David B]

Not really, as Asus re-implemented portions of networkmap. Data is now stored in a json format for instance, and too many pieces of the firmware need to interact with this.

And I suppose writing your own implementation is infeasible. Especially since you don't even have the ASUS source to reference.

 

[RMerlin]

And I suppose writing your own implementation is infeasible. Especially since you don't even have the ASUS source to reference.

Far too much work, it's fairly technical stuff. I've considered doing it in the past, back when I was depressed by the state of the networkmap code, and decided to settle on just fixing things in it. Thankfully, almost all those fixes have been picked up by Asus, so the current closed source code should be close to mine in terms of security/stability.

 

[Deplorable]

You're a gem Merlin.

 

[scavenger]

Really appreciate your commitment to finding a path forward, thank you.

 

[Ryansr]

Thanks.

 

[jim769]

Yes much appreciated. I see Asus has released there source code for there latest 382 code for the 88/3100 any way you can see what the heck is going on with the system log ? Other then that at least for me it seems to work fine. Just basic routing for me. But that system log slamming full is a huge annoyance.

 

[RMerlin]

Yes much appreciated. I see Asus has released there source code for there latest 382 code for the 88/3100 any way you can see what the heck is going on with the system log ? Other then that at least for me it seems to work fine. Just basic routing for me. But that system log slamming full is a huge annoyance.

Priority is on getting the code working on the AC86U, I won't have time to look at any other models for a few weeks.

 

[Xentrk]

I for one am happy that I have several AC88U that can take advantage of the new roadmap. And thank you @RMerlin fo your continued efforts.

With pfSense 2.4 release, they are implementing OpenVPN 2.4. OpenVPN on pfSense will be able to use AES-NI acceleration for AES-GCM tunnels, improving the tunneled traffic throughput between 30% and up to 50%. Do you see any tweeks that can be done on ASUS routers to do the same? Or, is it a limitation of the CPU's on the routers that will prevent this?

 

[David B]

Would you happen to know if ASUS has plans on implementing 382 for the 87U?

 

[RMerlin]

Would you happen to know if ASUS has plans on implementing 382 for the 87U?

AFAIK, there are already internal beta builds available for that model based on 382, so I expect they will eventually migrate that model to it.

The only device they specifically mentioned as being excluded when discussing it was the RT-N16.

Do you see any tweeks that can be done on ASUS routers to do the same? Or, is it a limitation of the CPU's on the routers that will prevent this?

I already squeezed everything I could out of openssl on these older ARM processors (including backporting optimizations from newer openssl releases at the time). For the RT-AC86U I don't know yet, optimization is far at the bottom of my list of things to do. Here are the current results using Asus's default optimizations on the RT-AC86U:

OpenSSL 1.0.2j  26 Sep 2016
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
compiler: /opt/toolchains/crosstools-arm-gcc-5.3-linux-4.1-glibc-2.22-binutils-2.25/usr/bin/arm-buildroot-linux-gnueabi-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_HEARTBEATS -DL_ENDIAN -Os -march=armv7-a -fomit-frame-pointer -mabi=aapcs-linux -marm -ffixed-r8 -msoft-float -D__ARM_ARCH_7A__ -ffunction-sections -fdata-sections -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM

The 'numbers' are in 1000s of bytes per second processed.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             19452.99k    70705.77k  226198.86k   496435.88k   769111.38k
aes-128 cbc      67813.30k    74312.02k    77161.30k    78323.33k    78692.19k
aes-192 cbc      58153.93k    64428.71k    66564.44k    66911.77k    67012.75k
aes-256 cbc      52080.34k    56746.70k    58479.70k    58827.27k    59176.28k
sha256           43923.10k   151693.35k  383434.08k   621045.04k   762250.53k
sha512           11354.54k    45011.22k    70937.43k    99912.70k   113602.08k

 

[jim769]

Priority is on getting the code working on the AC86U, I won't have time to look at any other models for a few weeks.

Understand. Thanks !!

 

[bsdsource]

RMerlin I downloaded the source code (382) for the RT-AC3100 just released and it's still using Linux 2.6 kernel. Do you know if Asus plans to change to the 4.1 kernel with this model? I already see they have with the RT-AC86U.

It's too bad that Asus is moving to a lot more closed source code. But I understand why Asus why they are doing it. You seem to have caught and patched a lot of potential exploits that Asus in turn have patched their code with.

On a side note I'm wondering how many coders they have working on their team? I think they really should audit their code much better.

Keep up the great work!

 

[RMerlin]

RMerlin I downloaded the source code (382) for the RT-AC3100 just released and it's still using Linux 2.6 kernel. Do you know if Asus plans to change to the 4.1 kernel with this model? I already see they have with the RT-AC86U.

The kernel is tied to a model's SDK. It cannot be changed by Asus. The RT-AC86U uses a completely different SDK from Broadcom, needed to support its new SoC.

 

[cybrnook]

86U is on 4+ Kernel?

 

[RMerlin]

86U is on 4+ Kernel?

Yes, 4.1.27, compiled 64-bit.

BTW, here's what you get when you let the BCM4906 fully stretch its legs:

admin@RT-AC86U-DFD8:/tmp/home/root# openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 35491686 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 64 size blocks: 24811450 aes-128-cbc's in 2.97s
Doing aes-128-cbc for 3s on 256 size blocks: 11333538 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 1024 size blocks: 3625589 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 8192 size blocks: 492161 aes-128-cbc's in 2.98s
OpenSSL 1.0.2j  26 Sep 2016
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) 
compiler: /opt/toolchains/crosstools-arm-gcc-5.3-linux-4.1-glibc-2.22-binutils-2.25/usr/bin/arm-buildroot-linux-gnueabi-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_HEARTBEATS -DL_ENDIAN -march=armv7-a -fomit-frame-pointer -mabi=aapcs-linux -marm -ffixed-r8 -msoft-float -D__ARM_ARCH_7A__ -ffunction-sections -fdata-sections -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     189922.07k   534657.51k   970363.12k  1241673.29k  1352947.29k

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     172477.81k   427770.52k   670943.40k   796123.70k   839262.21k

 

[cybrnook]

Does this mean you can do other trickery like introducing "Cake" intercepting QoS? Similar to what you did with fq_codel?

 

[RMerlin]

Does this mean you can do other trickery like introducing "Cake" intercepting QoS? Similar to what you did with fq_codel?

Don't know yet, haven't looked at it. I'm currently focusing on just migrating the existing code to 382, new enhancement will come much later.

 

[cybrnook]

Absolutely understand. Just trying to rattle off a thing or new that the older kernels have been holding us back on (well you, since we are just customers).

Glad to see you sticking with it through this transition.

 

[David B]

It's too bad that Asus is moving to a lot more closed source code. But I understand why Asus why they are doing it. You seem to have caught and patched a lot of potential exploits that Asus in turn have patched their code with.

I don't suppose we'd be able to get Asus to consider open-sourcing networkmap by making lots of noise about them closing it? Just a thought...