commits

commits@lists.open-mesh.org

1 participants
12373 discussions

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (42683fcf)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit 42683fcf3cf786fa5ca9555505b6a1827cd8a49c Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:58:20 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 42683fcf3cf786fa5ca9555505b6a1827cd8a49c open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index d35a66db..f8afcceb 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -21,7 +21,7 @@ Gluon also supports adding the following three types of WLAN encryption: # "OWE":https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption to encrypt traffic from a user device to the direct mesh node / AP: "OWE on client network":https://gluon.readthedocs.io/en/latest/releases/v2020.2.html#owe-on-client-network # A "''Private WiFi''":https://gluon.readthedocs.io/en/latest/features/private-wlan.html with WPA-Personal/preshared key encryption, simply bridged to a mesh node's WAN port -While 1)+2) protects against passive snooping, it however **does not protect against an active attacker in an open, public network** like Freifunk. Due to the open nature of Freifunk, the SAE password would need to be published / added to the firmware (source code) to allow anyone to setup their own mesh node. So overall Freifunk even with 1)+2) would still be susceptible to Man-in-the-Middle attacks. +While 1)+2) protects against passive snooping, it however **does not protect against an active attacker in an open, public network** like Freifunk. Due to the open nature of Freifunk, the **SAE password would need to be published** / added to the firmware (source code) to allow anyone to setup their own mesh node. So overall Freifunk even with 1)+2) would still be susceptible to Man-in-the-Middle attacks. The issue with option 3) is that while it is secure, as the mesh node owner can configure their own, private password for it in the Gluon Config-Mode Web-GUI of their Gluon mesh router, it can't be used on foreign, other mesh nodes over the mesh network. There is no secure tunneling or provisioning/collaboration between mesh nodes for the "Private WiFi" feature in Gluon.

1 0

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (e93e65a1)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit e93e65a19814505bbdd5209a1caed3f3cc7833ad Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:53:51 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- e93e65a19814505bbdd5209a1caed3f3cc7833ad open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 075ec021..61157bc2 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -6,7 +6,7 @@ This document specifies a way to dynamically tunnel WPA over a potentially untru h2. Issues -h3. Scenario A) - Issues in Decentral Wireless Community Mesh Networks +h3. Scenario A) - Decentral Wireless Community Mesh Networks In a wireless community mesh network like "Freifunk":https://en.wikipedia.org/wiki/Freifunk involving "batman-adv":https://www.open-mesh.org/projects/batman-adv/wiki/ + "Gluon":https://github.com/freifunk-gluon/gluon/ has two issues:

1 0

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (2ab9fc7b)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit 2ab9fc7b72f8f93808c8fa2548440bffb30916ae Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:54:42 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 2ab9fc7b72f8f93808c8fa2548440bffb30916ae open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index a08ed06d..e5716a74 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -27,7 +27,7 @@ The issue with option 3) is that while it is secure, as the mesh node owner can !OpenHarbors-diagram-freifunk.png! -h3. Issues with Passpoint/Hotspot 2.0/OpenRoaming solutions +h3. A) Issues with Passpoint/Hotspot 2.0/OpenRoaming solutions Industry leaders currently seem to propose and advocate for solutions based on "Passpoint/Hotspot 2.0":https://en.wikipedia.org/wiki/Wi-Fi_hotspot#Hotspot_2.0 (which in turn utilizes/builds upon "WPA-Enterprise":https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#Target_users_(authentication_key_distribution)). Potentially with "WBA OpenRoaming":https://wballiance.com/openroaming/ (Informational RFC: "here":https://datatracker.ietf.org/doc/draft-tomas-openroaming/ or similar trust/contract relations as a federation. Hotspot 2.0 was/is also a requirement for the EU "WiFi4EU":https://wifi4eu.ec.europa.eu/#/home initiative/funding.

1 0

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (33d63d40)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit 33d63d4010a5f024d3b26ce8c222812f60b34446 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:54:04 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 33d63d4010a5f024d3b26ce8c222812f60b34446 open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 61157bc2..f4fd34ab 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -6,7 +6,7 @@ This document specifies a way to dynamically tunnel WPA over a potentially untru h2. Issues -h3. Scenario A) - Decentral Wireless Community Mesh Networks +h3. A) - Decentral Wireless Community Mesh Networks In a wireless community mesh network like "Freifunk":https://en.wikipedia.org/wiki/Freifunk involving "batman-adv":https://www.open-mesh.org/projects/batman-adv/wiki/ + "Gluon":https://github.com/freifunk-gluon/gluon/ has two issues:

1 0

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (477dd6c3)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit 477dd6c3d44b7a7c9d768b87fe25388f3ba83963 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:53:33 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 477dd6c3d44b7a7c9d768b87fe25388f3ba83963 open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 5b2cc6b2..075ec021 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -6,7 +6,7 @@ This document specifies a way to dynamically tunnel WPA over a potentially untru h2. Issues -h3. Issues with Gluon based mesh networks +h3. Scenario A) - Issues in Decentral Wireless Community Mesh Networks In a wireless community mesh network like "Freifunk":https://en.wikipedia.org/wiki/Freifunk involving "batman-adv":https://www.open-mesh.org/projects/batman-adv/wiki/ + "Gluon":https://github.com/freifunk-gluon/gluon/ has two issues:

1 0

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (5b8c0025)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit 5b8c0025f212e3329c5623beecfdc6ba79442b8d Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:50:36 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 5b8c0025f212e3329c5623beecfdc6ba79442b8d open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 6e5c990a..5b2cc6b2 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -6,7 +6,7 @@ This document specifies a way to dynamically tunnel WPA over a potentially untru h2. Issues -h3. Scenario A: Issues with Gluon based mesh networks +h3. Issues with Gluon based mesh networks In a wireless community mesh network like "Freifunk":https://en.wikipedia.org/wiki/Freifunk involving "batman-adv":https://www.open-mesh.org/projects/batman-adv/wiki/ + "Gluon":https://github.com/freifunk-gluon/gluon/ has two issues:

1 0

[doc] backup-redmine,main: doc: open-mesh/OpenHarbors (62ff7b24)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine,main >--------------------------------------------------------------- commit 62ff7b248507090126e32f01fe468d0da7b02f02 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jul 8 11:50:05 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 62ff7b248507090126e32f01fe468d0da7b02f02 open-mesh/OpenHarbors.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 5b2cc6b2..6e5c990a 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -6,7 +6,7 @@ This document specifies a way to dynamically tunnel WPA over a potentially untru h2. Issues -h3. Issues with Gluon based mesh networks +h3. Scenario A: Issues with Gluon based mesh networks In a wireless community mesh network like "Freifunk":https://en.wikipedia.org/wiki/Freifunk involving "batman-adv":https://www.open-mesh.org/projects/batman-adv/wiki/ + "Gluon":https://github.com/freifunk-gluon/gluon/ has two issues:

1 0

[doc] main: Merge branch 'backup-redmine' (43a71e5f)
by postmaster＠open-mesh.org 03 Aug '24

03 Aug '24

Repository : ssh://git@diktynna/doc On branch : main >--------------------------------------------------------------- commit 43a71e5fd8ea0979d9f142f1e28ec7209aeda49e Merge: 76890a6a 46f3016b Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Aug 3 09:17:44 2024 +0200 Merge branch 'backup-redmine' >--------------------------------------------------------------- 43a71e5fd8ea0979d9f142f1e28ec7209aeda49e open-mesh/OpenHarbors.rst | 75 +- open-mesh/OpenHarbors.textile | 275 ++++++ ...university-server-room-scenario-traditional.png | Bin 0 -> 23258 bytes .../university-server-room-scenario-tunneled.png | Bin 0 -> 19587 bytes open-mesh/university-server-room-scenario.dia | 920 +++++++++++++++++++++ 5 files changed, 1258 insertions(+), 12 deletions(-) diff --cc open-mesh/OpenHarbors.rst index 4712565c,00000000..998acd9e mode 100644,000000..100644 --- a/open-mesh/OpenHarbors.rst +++ b/open-mesh/OpenHarbors.rst @@@ -1,353 -1,0 +1,404 @@@ +.. SPDX-License-Identifier: GPL-2.0 + +Idea/Draft: OpenHarbors (“Gotham Docks” / “WPA over L2TP”) +========================================================== + +**DRAFT / NOT IMPLEMENTED** + +This document specifies a way to dynamically tunnel WPA over a +potentially untrusted IP network to a gateway of the user’s choice. + - Issues - ------ - - Issues with Gluon based mesh networks - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++Scenario A): Decentral Wireless Community Mesh Networks ++------------------------------------------------------- + +In a wireless community mesh network like +`Freifunk <https://en.wikipedia.org/wiki/Freifunk>`__ involving +`batman-adv <https://www.open-mesh.org/projects/batman-adv/wiki/>`__ + - `Gluon <https://github.com/freifunk-gluon/gluon/>`__ has two issues: ++`Gluon <https://github.com/freifunk-gluon/gluon/>`__: ++ ++#. Anyone can setup a node to join + contribute to the mesh ++#. No prior authorization, anonymous participation possible ++#. Uses a firmware with public OpenSource code ++ ++Issues in Decentral Wireless Community Mesh Networks ++~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++ ++Currently has the following two issues: + +#. A user’s internet traffic is typically unencrypted in the WLAN mesh + cloud (except for https etc.) +#. A set of central gateways behind a VPN tunnel is used for internet + traffic (which contradicts Freifunk’s philosophy of decentralization, + but became defacto mandatory due to for private people unclear + Secondary Liability law in Germany: + `‘’Störerhaftung’’ <https://de.wikipedia.org/wiki/St%C3%B6rerhaftung)>`__ + - .. image:: OpenHarbors-diagram-freifunk-unencrypted.svg ++.. image:: OpenHarbors-diagram-freifunk-unencrypted.png + :alt: + +Gluon also supports adding the following three types of WLAN encryption: + +#. `SAE <https://en.wikipedia.org/wiki/Simultaneous_Authentication_of_Equals>`__ + to encrypt traffic between mesh nodes: + `gluon-mesh-wireless-sae <https://gluon.readthedocs.io/en/latest/package/gluon-mesh-wireless-sae.html>`__ +#. `OWE <https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption>`__ + to encrypt traffic from a user device to the direct mesh node / AP: + `OWE on client + network <https://gluon.readthedocs.io/en/latest/releases/v2020.2.html#owe-on-client-…>`__ +#. A `‘’Private + WiFi’’ <https://gluon.readthedocs.io/en/latest/features/private-wlan.html>`__ + with WPA-Personal/preshared key encryption, simply bridged to a mesh + node’s WAN port + - While 1)+2) protects against passive snooping, it however does not - protect against an active attacker in an open, public network like - Freifunk. Due to the open nature of Freifunk, the SAE password would - need to be published / added to the firmware (source code) to allow ++While 1)+2) protects against passive snooping, it however **does not ++protect against an active attacker in an open, public network** like ++Freifunk. Due to the open nature of Freifunk, the **SAE password would ++need to be published** / added to the firmware (source code) to allow +anyone to setup their own mesh node. So overall Freifunk even with 1)+2) +would still be susceptible to Man-in-the-Middle attacks. + +The issue with option 3) is that while it is secure, as the mesh node +owner can configure their own, private password for it in the Gluon +Config-Mode Web-GUI of their Gluon mesh router, it can’t be used on +foreign, other mesh nodes over the mesh network. There is no secure +tunneling or provisioning/collaboration between mesh nodes for the +“Private WiFi” feature in Gluon. + +.. image:: OpenHarbors-diagram-freifunk.svg + :alt: + +Issues with Passpoint/Hotspot 2.0/OpenRoaming solutions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Industry leaders currently seem to propose and advocate for solutions +based on `Passpoint/Hotspot +2.0 <https://en.wikipedia.org/wiki/Wi-Fi_hotspot#Hotspot_2.0>`__ (which +in turn utilizes/builds upon +`WPA-Enterprise <https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#Target_users_(authenti…)>`__. +Potentially with `WBA +OpenRoaming <https://wballiance.com/openroaming/>`__ (Informational RFC: +`here <https://datatracker.ietf.org/doc/draft-tomas-openroaming/>`__ or +similar trust/contract relations as a federation. Hotspot 2.0 was/is +also a requirement for the EU +`WiFi4EU <https://wifi4eu.ec.europa.eu/#/home>`__ initiative/funding. + +Unfortunately, WPA-Enterprise / Hotspot 2.0/Passpoint like as follows +has conceptual, compatibility issues with open wireless community mesh +networks, like in the following scenario: + +.. image:: OpenHarbors-diagram-old-approach.svg + :alt: + +With WPA-Enterprise: + +- WPA payload frames are encrypted between the client device (ak. + supplicant) and the AP (ak. authenticator) it connects to through the + Pairwise-Master-Key +- The PMK is securely established via EAP between client device and a + RADIUS server (ak. authentication server) +- The communication between the AP and the RADIUS server might be + encrypted via TLS (`RadSec <https://en.wikipedia.org/wiki/RadSec)>`__ +- However, the PMK after it was generated is then forwarded from the + RADIUS server to and installed on the AP. + -> the RADIUS server needs to **trust** the AP here + +-------------- + +*Which means the WPA-Enterprise approach (and therefore also its users +like Wifi4EU / Passpoint/Hotspot 2.0, or also eduroam) only works if the +APs are run by*\ **trusted administrators**\ *. Or a*\ **trusted, closed +source**\ *firmware/vendor.* + +-------------- + +The second issue with WBA OpenRoaming is that it currently requires a +membership, which includes a membership fee of $3000 one-time plus $3000 +yearly. Which is not affordable for a **non-commercial** community +initiative like Freifunk. + +Solution +-------- + +-------------- + +#. Determine the tunnel destination from a domain suffix in the + unencrypted login name (ak. “identity”) the user provided +#. Tunnel the full WPA exchange (EAPoL + encrypted payload) over IP + +-------------- + +Or in other words, move the 802.1x authenticator from the AP to a remote +host of a user’s choosing: + +.. image:: OpenHarbors-diagram.svg + :alt: + ++Scenario B) Hospital/University/Company/… ++----------------------------------------- ++ ++.. image:: university-server-room-scenario-traditional.png ++ :alt: ++ ++- An exposed AP, visible/reachable by visitors ++- A server with sensitive data inside a locked server room ++- Authorized employees/students/… accessing the server via WPA ++ Enterprise from their laptop ++ ++Issue ++~~~~~ ++ ++#. Via easy social engineering (e.g. putting on the right cloths, ++ suitcase, a ladder): ++ ++ - can get physical access to the AP ++ ++#. Can then copy the AP’s flash and extract RADIUS credentials ++#. Can then replace with a rogue Man-in-the-Middle AP or install a ++ backdoor ++ ++ - If no extra encryption/authentication/tunnel is used between ++ AP<->server then can also simply add a snooping device between AP ++ and wire to server ++ ++#. Now has access to sensitive data in the locked server room ++ ++.. _solution-1: ++ ++Solution ++~~~~~~~~ ++ ++.. image:: university-server-room-scenario-tunneled.png ++ :alt: ++ ++#. Like in scenario A), move the authenticator from the AP into the ++ server room ++#. Client device will have encrypted communication into the server room, ++ AP + wire becomes part of the untrusted medium ++#. No potential to Man-in-the-Middle from outside the server room ++#. Attacker now **needs a physical key** to the server room to get the ++ sensitive data (or access to the client device) ++ +(Additional) Use-cases & Benefits - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ++--------------------------------- + +This proposed, dynamic solution yields the following, additional +interesting opportunities: + +#. Securely connecting to the wireless mesh community’s gateways. So far + in a Freifunk mesh network internet traffic is typically only + encrypted on the VPN tunnel between a mesh node with an internet + uplink and the gateway, if at all. +#. Allows anyone to set up and use alternative gateways: + + #. Securely connecting to your home network via this tunnel, even on + untrusted/insecure community mesh networks. In a mesh network that + is Freifunk / Gluon based this could even result in faster + throughputs for the user, as internet traffic would not need to go + over the Freifunk gateway. This could be useful for a residential + community, too. + #. Allows a club / organisation / residential community / group to + securely share its internet connection and/or devices/services, + like printers, network storage, media centers or LAN multiplayer + games, over an untrusted mesh network. + #. Securely connecting to your departments/organisations network via + this tunnel, even on untrusted/insecure community mesh networks. + For instance blue light organisations like fire, police or + ambulance services? + #. Securely connecting to a commercial VPN provider and use it as an + alternative gateway than the ones a wireless community network + provides by default. Without the need of installing and setting up + an extra VPN software, as smartphones typically already support + WPA Enterprise. And for the VPN providers, would need no extra + contract or setup on the APs or other third party devices to be + authorized, as the protocol for setting up the tunnel is + intrinsic, without needing a broker / rendez-vous point. In + contrast to a classic VPN or WPA Enterprise, where both sides + would likely need to exchange credentials and addresses + beforehand. + #. Securely connecting to your commercial ISP’s gateways. Also usable + for mobile-to-WiFi offloading? Similar to one of WiFi Passpoints + goals, but now also usable over on untrusted WiFi APs. + #. Allows using eduroam on untrusted Freifunk nodes. + #. Increase gateway diversity in wireless community networks like + Freifunk, without legal obstacles. Currently in most Freifunk + networks the few, select gateways are run by a few admins in their + spare time, which contradicts Freifunk’s principle of + decentralization. Choosing and using alternative internet gateways + in a such a Freifunk network is currently infeasible for a + non-technical user here. + +Overall, in general: Allows to use an untrusted wireless community mesh +network as an easy-to-use, flexible, open, mobile carrier with +end-to-gateway encryption. + +Implementation Milestones/Tasks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Steps for a first, minimum implementation with real-world usability: + +:: + + <code> + # Preparation: + + [] (Familiarizing with hostapd code, find code points to hook into) + [] Specifiy tunneling protocol: + [] packet format + [] UDP port + [] ... + + # Implementation, hostapd: + + ## AP side + + Hook into/within hostapd: + + ### Early initalization: + + [] enable/react on OpenHarbors ESSID if configuration option is enabled + [] setup mac80211/cfg80211 to receive encrypted WPA CCMP frames in hostapd + + ### On-demand initalization + EAP handling: + + [] parse domain from unencrypted EAP-TTLS username from EAPoL frames + [] create a UDP/L2TP tunnel/session to parsed domain + (likely utilize the l2tp kernel module) + [] associate/memorize MAC + UDP socket (address+port) + [] encapsulate EAPoL + [] EAPoL frames from client to the socket/tunnel: + [] encapsulate with our IP/UDP/L2TP header + [] forward to IP router/stack + [] EAPoL frames from the socket/tunnel to the client: + [] decapsulate/remove our IP/UDP/L2TP header + [] forward to mac80211 + + ### Data forwarding: + + [] WPA CCMP frames from client to the socket/tunnel: + [] encapsulate with our IP/UDP/L2TP header to <domain> + [] forward to IP router/stack + [] WPA CCMP frames from socket/tunnel to client: + [] decapsulate/remove our IP/UDP/L2TP header + [] forward to mac80211 + + ## Remote Side / Remote Authenticator + + ### Early initialization: + + [] add configuration/enable option to hostapd + [] initialize socket to listen for L2TP packets on + a specific <UDP-port> + [] load mac80211/cfg80211 kernel modules + + ### On-demand initialization + EAP handling: + + [] receive L2TP packets + [] initialize L2TP tunnel/session + (likely utilize the l2tp kernel module) + [] EAPoL frames from hostapd to the socket/tunnel: + [] encapsulate with our IP/UDP/L2TP header + [] forward to IP router/stack + [] EAPoL frames from the socket/tunnel to hostapd: + [] decapsulate/remove our IP/UDP/L2TP header + [] forward/handle in hostapd's existing EAPoL code + [] establish PMK from EAPoL exchange + [] setup mac80211/cfg80211 with PMK to use + the Linux kernel's software encryption/decryption + of WPA (likely via the mac80211_hwsim kernel module) + [] (likely) needs changes/additions / new API to mac80211(_hwsim) + + ### Data forwarding: + + [] WPA CCMP frames from mac80211(_hwsim) to the socket/tunnel: + [] encapsulate with our IP/UDP/L2TP header to <domain> + [] forward to IP router/stack + [] WPA CCMP frames from socket/tunnel to mac80211(_hwsim): + [] decapsulate/remove our IP/UDP/L2TP header + [] forward to mac80211 + + ## Firmware Packaging/Integration + + ### OpenWrt package/integration: + + AP/client side: + + [] allow building a hostapd/wpa_supplicant/wpad variant + without OpenHarbor code (size tuneability matters + on embedded / for upstream acceptance) + + [] add an openharbor-client package + [] add requirement to usable hostapd/wpa_supplicant/wpad + build variants + [] integrate into OpenWrt's netifd('s mac80211.sh) + [] add documentation/description to package + [] add document/description on OpenWrt Wiki's "UCI /etc/config/wireless page":https://openwrt.org/docs/guide-user/network/wifi/basic + + Remote Authenticator Side: + + [] add an openharbor-server (openharbor-authenticator) package + [] add documentation/description to package + + ### Freifunk/Gluon integration + + [] add a gluon-openharbor-client package to enable OpenHarbor on + WiFi radios used by Gluon + [] add documentation/description to package + / Gluon's readthedocs, including use-cases/illustrations + for Gluon/Freifunk users + [] add a gluon-openharbor-server package + [] add Gluon Config-Mode Web-GUI integration, + usable by non-technical people: + [] to set output interface for decrypted WPA + (e.g. WAN vs. LAN ports) + [] to set a list of allowed username//password + combinations + </code> + +Optional/additional/future Milestones/Ideas +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Extra kernel module which forwards between the + mac80211(_hwsim) kernel module and the l2tp + kernel module (or implement within mac80211_hwsim) + for increased/usable performance on embedded devices + (ideally already done early for/with the initial implementation) +- Roaming / handover support: When a client roams to another AP + then the old AP would need to hand over the L2TP tunnel to + the new AP? Or will the client go through the full EAPoL steps + again anyway? Or is a handover protocol only needed if 802.11r + were involved? +- More EAP methods: Any other methods other than EAP-TTLS which + can provide a cleartext username and/or domain? +- Add RADIUS server option to (Gluon’s) openharbor-server/authenticator + integration, for a more sophisticated/flexible authentication + management (for more technically versed people) +- Signal “OpenHarbor” capability via a vendor field in beacons? + To avoid a client only relying on the “OpenHarbor” ESSID name? + (if I recall correctly also Passpoint had options for similar + signalling?) +- Passpoint / Hotspot 2.0 compatibility +- additional Layer 2 encapsulation method, which skips the IP/UDP/L2TP + headers and + uses a smaller, custom ethernet frame header + + - allows login via: \ ``<mac-address-destination> + -> useful to tunnel from one mesh node to another, + within this layer 2 domain, without layer 3 routing involved + * allow using node names for login: + ** Gluon nodes only have an IPv6 address to be accesed. + And (typically) no public DNS entry for this IPv6 address. + Having a user to enter <login-name>``\ <mesh-node’s-IPv6-address> + won’t be usable in practice for the gluon-openharbor-server + package. Instead the hostname, which a Gluon mesh node owner + can set in the Gluon config-mode and is then visible on + a central map server, should be usable for a client + - option A) integrate mDNS? -> nicely decentral, but likely has too + high protocol overhead + - option B) a small nsswitch module on the openharbor AP side + which resolves a given @.local (or similar TLD) + via the nodes.json fetched from the map server + - option C) a cronjob which fetches node names from + the map server and populates /etc/hosts on the AP + +- MTU signaling compliant with + `RFC:4459 <https://www.rfc-editor.org/rfc/rfc4459>`__ diff --cc open-mesh/university-server-room-scenario.dia index 00000000,3aa06a29..7d62fac5 mode 000000,100644..100644 Binary files differ

1 0

[linux-merge]linux integration; annotated tag, v6.1.102, created. v6.1.102
by postmaster＠open-mesh.org 01 Aug '24

01 Aug '24

The annotated tag, v6.1.102 has been created at dfa7e9d8d4bc595bca1d95884a8cdf88e60b2e1b (tag) tagging c1cec4dad96b5e49c2b7680f7246acf58d4c87da (commit) replaces v6.1.92 tagged by Greg Kroah-Hartman on Sat Jul 27 11:32:43 2024 +0200 - Shortlog ------------------------------------------------------------ This is the 6.1.102 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmakvrsACgkQONu9yGCS aT7Zbw//Sj0Nn64wJmh/jMa83Ymc2kSH/ScOivXnWG/lKVcDy6aCKJIGMnxMjc+b I/rAtXeIGPanJpoVKndWJC7fsma6ZDUUENjBl5FSpLIGbms8DTzuXcISsEzu/qKG Da+EfngevVF6fea9gTsVlrqmWRiAI2ew3d5jiW7AWjnIu5fFSsryIQWv1hPAzn0e 2piPo1Lyq+hy3mBpzk/zoqxPrFppguY34EZcZ+0doeLIUA1vrAZ9zc+lVqHMhPoX krLq1KXzPYflkkDjJiGMTTqdHag9BYsclepmnGudhL9yboyFIhtGXeoGMdxCU8d1 T4bUJKdCvGRVq/LHbCVBHenpsuJP73ZrPZFrJCTGXP93hFfwouXSawMnfIvDI+jB msPT9MIVHDKrWgPRJ62vNItInO9PG2yiouA2DMocQcpsI9uUH4XAmmvgV+9j26kK qsPWsWCG3lUDcy8IZAIQ8C/GswaFgInxLZ6138CbTLsieSre/8Lk+xJEYCkwLtGH ETQ5A2IHdcLczWorC9LbIhomUpu6jIdHZeg7o4ruO/i/s2Vls5L3LB/Nzp99NnZy QQ0XsqlHoAI8HMHhiFZPVeQMAYnTBnew/zdg9/a/IE2+HK9ZIK1SMBINbGAv19ZS C5ecZfjK5pvs7/FhO1gA1imG0Qo+UZTVZ94DmDCh7gNsBpx/7cI= =t1ti -----END PGP SIGNATURE----- Eric Dumazet (1): batman-adv: bypass empty buckets in batadv_purge_orig_ref() Sven Eckelmann (1): batman-adv: Don't accept TT entries for out-of-spec VIDs ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v6.6.43, created. v6.6.43
by postmaster＠open-mesh.org 01 Aug '24

01 Aug '24

The annotated tag, v6.6.43 has been created at 763511c8f98b3b1da35d919217ef1cd7c2c42363 (tag) tagging 58b0425ff5df680d0b67f64ae1f3f1ebdf1c4de9 (commit) replaces v6.6.32 tagged by Greg Kroah-Hartman on Sat Jul 27 11:34:32 2024 +0200 - Shortlog ------------------------------------------------------------ This is the 6.6.43 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmakvygACgkQONu9yGCS aT6E+hAArjqmGY9Mv8S8F6Ry7PLi1V4gidS81dd0vmX0mx23FSeTZdm0vKZfHmTV 8xJvGkx1aV3KB9AiB4uXcjHZ0+3LSJFwVzkYaJWruJhNL3Qo99/FjZoTBTXSDkab r4zaQWOSh0DpM+UQQwC8JZgrdmdGBkg3EGieUd157Y812Mer2wImbMfwwNClB7MS rQQFTvIybUqBZCBmb0y1ugQi/ADv7PgnTgLzOt2jwAl2+rtmnRjP68Ps5rJlFsIr 3IiaFSVzccl6RaafltQDbBSIH7rVVvPK36soK3fa4cjTN12gHSWgwnKLA6gb2xVK aOgWRyDn9eA7QX+NNKXl068Lo5avV/j/bG4809o2Rc07DxXxw6cSt+WUaS8Vv7dE iHxGQ4fpp3NvEqVJcE5ZbdlPCHWhRCSm3WSIvjbX8E1G6O/aq7QmaniD1VhV35Bm haV1+bB6qINGPdL0iZ+iAfLVG3vJ1ZcdSk2TsDYsnduJr0ypnDdVJ9JEwBwLXzHD EECgC4SCR086fHnLXbcDeQlnWxeE5tsOez0o3OyRrkKQrDwUqMED5T1A7SfB2z9l jVH4j/ydOQpFNbBW3wpzFpWJ8b/JGLlXbhLt3DlKBKFeh/2QCVFYHqUtYfis8SHA 7h5+LTY1p8/sq/vBMSTc79eZ9wwyqvyTnZabw/trPL0WroJyF3o= =OlhX -----END PGP SIGNATURE----- Eric Dumazet (1): batman-adv: bypass empty buckets in batadv_purge_orig_ref() Sven Eckelmann (1): batman-adv: Don't accept TT entries for out-of-spec VIDs ----------------------------------------------------------------------- -- linux integration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits