> On Jul 25, 2020, at 1:36 AM, Stijn Segers <f...@volatilesystems.org> wrote:
>
> Hi Petr,
>
> Op zaterdag 25 juli 2020 om 10u08 schreef Petr Štetiar <yn...@true.cz>:
>> m...@adrianschmutzler.de <m...@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@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
