search

libremesh / lime-packages

LibreMesh packages configuring OpenWrt for wireless mesh networking
https://libremesh.org/
GNU Affero General Public License v3.0
277 stars 96 forks source link

Consider including wpad-mesh-openssl by default #613

Open ilario opened 4 years ago

ilario commented 4 years ago

Currently we ship images with just wpad-mini. This means that one willing to have encryption over the ieee802.11s mesh connections has to install additional packages. This is incorrectly documented in lime-example: wpad-mesh should be replaced by wpad-mesh-wolfssl or wpad-mesh-openssl. In my opinion we could just add wpad-mesh-wolfssl in the default packages list. This also have the advantage of adding the support for WPA3-SAE, channel auto selection and DFS restricted channels (cit. @p4u on #268).

I tried to compile an image (with all the LibreMesh packages, for a TP-Link WDR3600) with just wpad-mini and one with just wpad-mesh-wolfssl (strange thing, the package does not appear at first in the menuconfig, it appears after selecting and deselecting wpad): With only wpad-mini the sysupgrade.bin image is 4915204 bytes. With only wpad-mesh-wolfssl the sysupgrade.bin image is 5308420 bytes. So there's 384 kB difference.

Both if we agree on this or not, we should document this also on the website and update lime-example.

nicopace commented 4 years ago

would this also allow the use of ssl on uhttpd?

ilario commented 4 years ago

I don't think so... Maybe that would be more overlapping if we use wpad-mesh-openssl?

nicopace commented 4 years ago

Yep, they share packages:

dangowrt commented 4 years ago

would this also allow the use of ssl on uhttpd?

Yes, you'd need to install libustream-wolfssl and px5g-standalone to make uhttpd use WolfSSL for HTTPS.

ilario commented 4 years ago

This sounds great! As I suppose we're not going to support any 4 MB flash memory router anymore, there's no excuse for not supporting mesh encryption by default :) @germanferrero @gmarcos87 @spiccinini do you plan to allow the access to lime-app using HTTPS? Do you know if these packages would allow it?

dangowrt commented 4 years ago

I'm using wpad-mesh-wolfssl with libremesh (with lime-proto-batadv) on quite a lot of 4/32 MB devices (without LuCI). I agree that those should no longer be officially supported to discourage anyone from buying them. But I guess I will be needing to maintain quite a number of them for quite a while...

ilario commented 4 years ago

Sure, we can try (and I agree that it would be great) to have also 4 MB images released (and even if we do not, it will be possible to obtain 4 MB images compiling a custom image). I think that if we include mesh encryption on the 8 MB image, we need to include it also on the 4 MB one, but we will discuss this elsewhere :)

nicopace commented 4 years ago

@germanferrero @gmarcos87 @spiccinini do you plan to allow the access to lime-app using HTTPS? Do you know if these packages would allow it?

@ilario i started reflecting a bit about that here: https://hackmd.io/@nicopace/PWA-LibreRouter

AndyMcSchopf commented 4 years ago

@ilario As posted on the user-list I found a problem with mesh-encryption. Using wpad-mesh-wolfssl (as recommended in the lime-community-default file) is working on openwrt 18.06.8 - but stops working on 19.07.3. I got only SAE-AUTH failures and no connection between the nodes. I found, among others, the following link: https://forum.openwrt.org/t/wpa3-wolfssl-fail-openssl-success/50161 So i tried and replaced wolfssl with the openssl package. (wpad-mesh-openssl) This solved the Problem - the encryption (now on WPA3-Level) is working again. The option I used in both Environments: (in lime-community) option ieee80211s_mesh_id '_mesh' option ieee80211s_encryption 'psk2+tkip+ccmp' option ieee80211s_key ''

ilario commented 4 years ago

Thanks @AndyMcSchopf !!

https://forum.openwrt.org/t/wpa3-wolfssl-fail-openssl-success/50161

Reading the thread you linked seems that a patch was created, but it is not present in 19.07.3. Surely it will be present in 19.07.4. In the meanwhile, can you try to compile using openwrt-19.07 branch instead of v19.07.3 tag? This way you should have the patch :) Let us know if it fixes!!!

AndyMcSchopf commented 4 years ago

@ilario I compiled the 19.07 branch (SNAPSHOT) Yesterday, and yes! I works with the new wolfssl Version. I only have a minor Problem with my Ubiquiti Outdoor Meshpoint - there the 5Ghz Mesh is still not working... But I think this may be driver related.

dangowrt commented 4 years ago

@ilario I compiled the 19.07 branch (SNAPSHOT) Yesterday, and yes! I works with the new wolfssl Version.

wolfssl has been fine for a while, it was hostapd which needed some fixing: https://github.com/openwrt/openwrt/commit/d8d1956a8087da2fd4465c4381d9e28b91cdc1e8

I only have a minor Problem with my Ubiquiti Outdoor Meshpoint - there the 5Ghz Mesh is still not working... But I think this may be driver related.

Is that ath10k? If so, which firmware you are using? (-ct?) And are you trying on DFS channels?

AndyMcSchopf commented 4 years ago

@ilario I compiled the 19.07 branch (SNAPSHOT) Yesterday, and yes! I works with the new wolfssl Version.

wolfssl has been fine for a while, it was hostapd which needed some fixing: openwrt/openwrt@d8d1956

Thanks for the correction ;-)

I only have a minor Problem with my Ubiquiti Outdoor Meshpoint - there the 5Ghz Mesh is still not working... But I think this may be driver related.

Is that ath10k? If so, which firmware you are using? (-ct?) And are you trying on DFS channels?

Meanwhile I found the hint in the openwrt wiki to not use the -ct driver and firmware for meshing. I got this one working too ;-)

ilario commented 4 years ago

A small follow-up: OpenWrt 19.07.4 was released on past Wednesday and its Hostapd/Wolfssl already include the needed patch (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=631c437a91c20df678b25dcc34fe23636116a35a)

AndyMcSchopf commented 4 years ago

@ilario I might add that I compiled my whole images with 19.07.4 and they are all working with wolfssl.

ilario commented 3 years ago

would this also allow the use of ssl on uhttpd?

Yes, you'd need to install libustream-wolfssl and px5g-standalone to make uhttpd use WolfSSL for HTTPS.

Sorry for not testing this before, I just tested compiling an image based on OpenWrt 19.07 with wpad-mesh-wolfssl, libustream-wolfssl and px5g-standalone: lime-app opens directly using HTTPS! The sysupgrade.bin file grew of just 450 kB. In my opinion we should suggest all these packages as "optional" in the development page.

I did not test with OpenWrt 18.06, nor I tested if shared-state is affected.

ilario commented 3 years ago

In order to consider this fixed, we have to resolve #799 and https://github.com/libremesh/lime-web/issues/125

ilario commented 2 years ago

When compiling on top of OpenWrt 22.03 I didn't manage to deselect wpad-basic-wolfssl (which was selected by default) in order to select wpad-mesh-wolfssl. See https://github.com/openwrt/openwrt/issues/8312

ilario commented 1 year ago

From various sources, mainly users on the Element/Matrix chatroom, seems that WolfSSL is not good for lossy transport medium like wifi mesh, on which OpenSSL is much more stable. Clearly, wpad-mesh-openssl is much larger. When I tried to install it on a LibreMesh router with some rather default packages selection, it pulled:

973.2K libopenssl1.1_1.1.1n-1_mips_24kc.ipk
9.7K libubus20210603_2022-02-21-b32a0e17-1_mips_24kc.ipk
435.5K wpad-mesh-openssl_2019-08-08-ca8c2bd2-8_mips_24kc.ipk

so it is approx 1.5 MB, maybe it takes more space when unpacked.