FS#814 - When LEDE is compiled with GCC 7 on at least ar71xx and brcm47xx, Dropbear won't accept connections

[aparcar]

mamarley:

When using the GCC 7.x compiler, I have found that Dropbear in LEDE images for ar71xx (Ubiquiti Unifi) and brcm47xx (generic) (built with the default configuration, other than changing the compiler to GCC 7.x) won't accept incoming SSH connections. Instead, as soon as a connection is received, it spins the CPU indefinitely and the connecting SSH client hangs. Nothing relevant is printed in the logs. This behavior does not occur on x86_64; there Dropbear works fine.

I realize I haven't provided much information here, but I don't really know how to collect anything else on embedded platforms like this. One of the devices on which I have reproduced this does have a serial adapter though, so I can use that to get any additional information that might be helpful.

[aparcar]

None:

To further muddy the waters - I've two ar71xx Archer C7 v2 running GCC 7 compiled images working fine. However I've changed the processor target to MIPS 74kc rather than the default MIPS 24kc.

I guess I could rebuild with the default processor selection and see if that reproduces the issue.

[aparcar]

harrylwc:

https://github.com/wongsyrone/dropbear-test

[aparcar]

bjonglez:

Here is the discussion from the mailing for reference:

Had a really quick play with this and as I suspected it's related to compiler optimization flags. In essence, if I compile with '-Os' then dropbear plays dumb, with my usual (but different from default) of '-O2' then dropbear, gcc 7 & mips get on fine, irrespective of target -march settings.

So as further totally wild guesses and on the basis 'ssh -vvv' shows things hanging during the initial ECDH key exchange, I'm going to guess this is happening somewhere in the libtommath/crypt libraries.

I checked the bundled libtom* in dropbear:

bundled: libtomcrypt is 1.16, libtommath is 0.40 latest: libtomcrypt is 1.17, libtommath is 1.0

There are various fixes since the bundled version: https://github.com/libtom/libtommath/releases

Confirmed that with the latest libtom*, dropbear works well on MIPS & GCC 7.

This repo is based on dropbear 2017.75.

[aparcar]

bjonglez:

It should be fixed with the next dropbear release.

[aparcar]

arjendekorte:

Note that other packages are affected by similar problems with GCC 7. For instance, uhttpd will also fail on a Netgear WNDR4300 when compiled with -Os. For the moment, I would recommend to just stick to -O2 if a slight increase in size is acceptable.

[aparcar]

avbohemen:

This bug hit me too today. Both dropbear and uhttpd not functioning properly, and the only way to recover is via failsafe.

[aparcar]

ezar:

Same here! Both dropbear and uhttpd not functioning properly. I revert to 6.3 build. Regards, César.

[aparcar]

None:

Two patches authored today (22 Aug 17) to bump gcc 7 to 7.2.0 (https://patchwork.ozlabs.org/patch/804368/) and also one that removes a MIPS 'optimization' patch https://patchwork.ozlabs.org/patch/804367/

The removal of '300-mips_Os_cpu_rtx_cost_model.patch' has solved the dropbear '-Os' failure for me with no apparent size penalty. It would be worth testing again with those patches applied.

[aparcar]

freefor:

Yesterday I had the same problem compiling with GCC 7.0 for my 'xway' router.

[aparcar]

nouman8:

few days ago again i compiled with GCC 7.2 and had the exact same problem as i described in FS#830.

[aparcar]

None:

This is a bug in gcc 7 (&8) described https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496

[aparcar]

nbd:

Fixed in r6322-25aaff9100