Closed openwrt-bot closed 6 years ago
openwrt-bot
commented
7 years ago 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.
openwrt-bot
commented
7 years ago openwrt-bot
commented
7 years ago 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.
openwrt-bot
commented
7 years ago bjonglez:
It should be fixed with the next dropbear release.
openwrt-bot
commented
7 years ago 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.
openwrt-bot
commented
7 years ago avbohemen:
This bug hit me too today. Both dropbear and uhttpd not functioning properly, and the only way to recover is via failsafe.
openwrt-bot
commented
7 years ago ezar:
Same here! Both dropbear and uhttpd not functioning properly. I revert to 6.3 build. Regards, César.
openwrt-bot
commented
7 years ago 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.
openwrt-bot
commented
7 years ago freefor:
Yesterday I had the same problem compiling with GCC 7.0 for my 'xway' router.
openwrt-bot
commented
6 years ago nouman8:
few days ago again i compiled with GCC 7.2 and had the exact same problem as i described in FS#830.
openwrt-bot
commented
6 years ago None:
This is a bug in gcc 7 (&8) described https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
openwrt-bot
commented
6 years ago nbd:
Fixed in r6322-25aaff9100
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.