[PATCH 2/3] treewide: use wpad-basic-wolfssl as default

[Rosen Penev]

> On Jul 25, 2020, at 1:36 AM, Stijn Segers <foss at volatilesystems.org> wrote:
> 
> Hi Petr,
> 
> Op zaterdag 25 juli 2020 om 10u08 schreef Petr Štetiar <ynezz at true.cz>:
>> mail at adrianschmutzler.de <mail at adrianschmutzler.de> [2020-07-24 17:36:08]:
>> Hi,
>>> I would prefer to not touch ar71xx here, as this is essentially only used
>>> for backporting, and changing stuff would only make these backports more
>>> complicated, while not really providing a benefit. (I'm not sure whether it
>>> can be still built with master at all.)
>> ok, noted.
>>> Despite, is my impression correct that this patchset won't affect the size
>>> of pure "tiny" targets, like ath79/tiny?
>> Good catch. It was all just done with git grep & sed replacing wpad-basic with
>> wpad-basic-wolfssl, so this targets were missed as they're using wpad-mini.
> 
> I read Adrian's reply as 'we'll keep ath79/tiny out of the wpad SSL push?' but I
> might be mistaken of course.
> 
>> I'm going to switch those to wpad-basic-wolfssl variant as well, since it
>> seems that the only difference is CONFIG_IEEE80211R=n in wpad-mini.
> 
> I think that will kill even more tiny images (master has been seeing a lot of those
> being disabled lately). On my TL-WR841ND v7, e.g., I have stripped some more stuff
> from master, after the 5.4 bump (which was to be expected). I was able to squeeze
> in wpad-basic again for the 802.11r (PPP removed though), but it's not like those tiny
> targets have 20 kB to spare, from what I can tell.
> 
> (I heard through the grapevine older flash/RAM constrained devices might just stick
> with kernel 4.19 btw? ath79/tiny is already on 5.4.)
> 
> Since ath79/tiny is a separate subtarget altogether, it makes sense to offer them with
> fewer features. Unless I'm mistaken we'll see a lot of ramips/mt76{20,x8} stuff going
> the same route in the near future, they have similar flash constraints. I don't think
> feature parity with more recent targets (or ones with more space) is what one should
> aim for, with a separate subtarget.
> 
> 
> Just my 2 cents.
> 
> Stijn
> 
> P.S. Is there a way to use mbedtTLS with wpad? That would be neat since one could have
> LuCI SSL and wpad lean on the same crypto library. I am now building images with mbedTLS
> for LuCI and wolfssl for wpad; it's still smaller than having both build with OpenSSL
> but a bit cumbersome nonetheless.
I will note that WolfSSL is based on OpenSSL, meaning it’s not too difficult to add wolfSSL support to OpenSSL packages.
> 
> 
>> Adding SAE (as all images should support WPA3-Personal from now on) is adding
>> way more to the images, so excluding 802.11r doesn't make sense as the size
>> difference would be probably negligible compared to the size of wolfSSL,
>> certificates etc.
>> -- ynezz
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel