commits

commits@lists.open-mesh.org

1 participants
12373 discussions

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors-diagram-freifunk-unencrypted.dia (aa9a76a8)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit aa9a76a8138ab24814848bf8b621a8674fe5f8b6 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Jan 31 22:20:25 2024 +0000 doc: open-mesh/OpenHarbors-diagram-freifunk-unencrypted.dia >--------------------------------------------------------------- aa9a76a8138ab24814848bf8b621a8674fe5f8b6 open-mesh/OpenHarbors-diagram-freifunk-unencrypted.dia | Bin 0 -> 3778 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/open-mesh/OpenHarbors-diagram-freifunk-unencrypted.dia b/open-mesh/OpenHarbors-diagram-freifunk-unencrypted.dia new file mode 100644 index 00000000..2f7640e8 Binary files /dev/null and b/open-mesh/OpenHarbors-diagram-freifunk-unencrypted.dia differ

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors (7f796bae)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit 7f796baee6c64c68c16bdb54e3537577064cdffd Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Thu Feb 1 06:35:09 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- 7f796baee6c64c68c16bdb54e3537577064cdffd open-mesh/OpenHarbors.textile | 160 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 148 insertions(+), 12 deletions(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 9c98359c..223ca191 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -10,41 +10,177 @@ 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) A user's internet traffic is typically unencrypted in the WLAN mesh cloud -2) 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) +# A user's internet traffic is typically unencrypted in the WLAN mesh cloud +# 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) !OpenHarbors-diagram-freifunk-unencrypted.png! Gluon also supports adding the following three types of WLAN encryption: -1) "SAE":https://en.wikipedia.org/wiki/Simultaneous_Authentication_of_Equals to encrypt traffic between mesh nodes -2) "OWE":https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption to encrypt traffic from a user device to the direct mesh node / AP -3) 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 +# "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-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. 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. +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. !OpenHarbors-diagram-freifunk.png! h3. Issues with Passpoint/Hotspot 2.0/OpenRoaming solutions -Industry leaders currently seem to propose and advocate for solutions based on Passpoint/Hotspot 2.0 which in turn 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. +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. 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: !OpenHarbors-diagram-old-approach.png! +With WPA-Enterprise: + * WPA payload frames are encrypted between the client device (ak. supplicant) and the AP 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 the AP (ak. authenticator). +* However, the PMK after it was generated is then forwarded from the RADIUS server to and installed on the AP (ak. authenticator). -> 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. +---- + +__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. h2. Solution -1) Determine the tunnel destination from a domain suffix in the unencrypted login name the user provided -2) Tunnel the full WPA exchange over IP +# Determine the tunnel destination from a domain suffix in the unencrypted login name (ak. "identity") the user provided +# Tunnel the full WPA exchange over IP + +Or in other words, move the 802.1x authenticator from the AP to a remote host of a user's choosing: + +!OpenHarbors-diagram.png! + +h3. (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. + +h3. Implementation Milestones/Tasks + +<pre><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 to parsed domain +[] 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 + +### Initialization + +Option A) +* Setup/Utilize mac80211_hwsim kernel module? + +Option B) +* + + * Remote Server side, initialization / EAP handling: + * Remote Server side, data forwarding, from client: + ... + * Remote Server side, data forwarding, to client: + ... + +## 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) + +[] 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 side: + +[] add an openharbor-server 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></pre> + +## Optional/additional/future Milestones/Ideas +* Kernel module / mac82011 additions for encapsulation for performance - if necessary? +* Passpoint / Hotspot 2.0 compatibility +* More EAP methods: Any other methods other than EAP-TTLS which + can provide a cleartext username and/or domain? +* Layer 2 encapsulation method, which skips the IP/UDP/L2TP headers and + uses a smaller, custom ethernet frame header + * allows login via: <username>@<mac-address-destination> + -> useful to tunnel from one mesh node to another? \ No newline at end of file

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/News-draft (15ecc49e)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit 15ecc49e0a8528e31f2c90452699f34557dad37b Author: Sven Eckelmann <sven(a)narfation.org> Date: Mon Jan 29 09:12:57 2024 +0000 doc: open-mesh/News-draft >--------------------------------------------------------------- 15ecc49e0a8528e31f2c90452699f34557dad37b open-mesh/News-draft.textile | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/open-mesh/News-draft.textile b/open-mesh/News-draft.textile index acfe5e00..1c9d001b 100644 --- a/open-mesh/News-draft.textile +++ b/open-mesh/News-draft.textile @@ -1,6 +1,6 @@ h1. DRAFT: Batman-adv 2024.0 released -Jan 30th, 2024. Today the B.A.T.M.A.N. team publishes the January 2024 update to batman-adv! batman-adv gained support for the new stateless, TVLV capable batman-adv multicast packet type. The originator of a multicast packet includes all destinations for this packet. The routers on the way will potentially split this destination list (based on the best next hops) and and forward for each chunk an adjusted packet to the best next neighbor. +Jan 30th, 2024. Today the B.A.T.M.A.N. team publishes the January 2024 update to batman-adv! batman-adv gained support for the new stateless, TVLV capable batman-adv multicast packet type. The originator of a multicast packet includes all destinations for this packet. The routers on the way will potentially split this destination list (based on the best next hops) and and forward for each chunk an adjusted packet to the best next neighbor. Also several bug fixes and code cleanups are included in this version. As the kernel module always depends on the Linux kernel it is compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section: @@ -72,8 +72,8 @@ h2. batctl <pre> $ git describe origin/main -v2023.3-3-gaf2806d -$ range=v2023.3..v2023.3-3-gaf2806d +v2023.3-9-gfb7a514 +$ range=v2023.3..v2023.3-9-gfb7a514 $ git shortlog --email --no-merges "${range}" $ git log --no-merges "${range}"|grep -e '$Reported\|Tested\|Acked\|Reviewed-by\|Co-authored-by$-by'|sed 's/.*:/*/'|sort|uniq @@ -96,12 +96,20 @@ coding style cleanup/refactoring bugfixes ======== - + batctl: tcpdump: Fix missing sanity check for batman-adv header + batctl: tcpdump: Add missing throughput header length check + batctl: tcpdump: Fix IPv4 header length check + batctl: tcpdump: Add missing ICMPv6 Neighbor Advert length check + batctl: tcpdump: Add missing ICMPv6 Neighbor Solicit length check + batctl: tcpdump: Fix ICMPv4 inner IPv4 header length check 2024.0 (2024-01-30) =================== * Add stateless multicast packet format support +* bugs squashed: + + - Fix various length checks in tcpdump-like subcommand </pre>

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors-diagram-freifunk.png (dd6fa981)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit dd6fa981116e7b68bd71a060c693b5bed85230f4 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Jan 31 22:16:06 2024 +0000 doc: open-mesh/OpenHarbors-diagram-freifunk.png >--------------------------------------------------------------- dd6fa981116e7b68bd71a060c693b5bed85230f4 open-mesh/OpenHarbors-diagram-freifunk.png | Bin 0 -> 108354 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/open-mesh/OpenHarbors-diagram-freifunk.png b/open-mesh/OpenHarbors-diagram-freifunk.png new file mode 100644 index 00000000..7ca13b38 Binary files /dev/null and b/open-mesh/OpenHarbors-diagram-freifunk.png differ

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors-diagram-freifunk-unencrypted.png (a826bf73)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit a826bf73adcf2d7303827723306a8d3491797bca Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Wed Jan 31 22:20:17 2024 +0000 doc: open-mesh/OpenHarbors-diagram-freifunk-unencrypted.png >--------------------------------------------------------------- a826bf73adcf2d7303827723306a8d3491797bca open-mesh/OpenHarbors-diagram-freifunk-unencrypted.png | Bin 0 -> 101909 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/open-mesh/OpenHarbors-diagram-freifunk-unencrypted.png b/open-mesh/OpenHarbors-diagram-freifunk-unencrypted.png new file mode 100644 index 00000000..2a821075 Binary files /dev/null and b/open-mesh/OpenHarbors-diagram-freifunk-unencrypted.png differ

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/News-draft: stub for 2024.0 (3dea0931)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit 3dea09318de3cba6cdcd903bc88c530775608448 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jan 25 20:12:29 2024 +0000 doc: open-mesh/News-draft: stub for 2024.0 >--------------------------------------------------------------- 3dea09318de3cba6cdcd903bc88c530775608448 open-mesh/News-draft.textile | 64 +++++++++++++++++++++----------------------- 1 file changed, 31 insertions(+), 33 deletions(-) diff --git a/open-mesh/News-draft.textile b/open-mesh/News-draft.textile index a99a8db0..acfe5e00 100644 --- a/open-mesh/News-draft.textile +++ b/open-mesh/News-draft.textile @@ -1,91 +1,90 @@ -h1. DRAFT: Batman-adv 2023.3 released +h1. DRAFT: Batman-adv 2024.0 released -Nov 15th, 2023. Today the B.A.T.M.A.N. team publishes the November 2023 update to batman-adv! batman-adv is no longer warning about an MTU reduction when the soft-interfaces already has a reduced MTU. Also several bug fixes and code cleanups are included in this version. +Jan 30th, 2024. Today the B.A.T.M.A.N. team publishes the January 2024 update to batman-adv! batman-adv gained support for the new stateless, TVLV capable batman-adv multicast packet type. The originator of a multicast packet includes all destinations for this packet. The routers on the way will potentially split this destination list (based on the best next hops) and and forward for each chunk an adjusted packet to the best next neighbor. As the kernel module always depends on the Linux kernel it is compiled against, it does not make sense to provide binaries on our website. As usual, you will find the signed tarballs in our download section: -https://downloads.open-mesh.org/batman/releases/batman-adv-2023.3/ +https://downloads.open-mesh.org/batman/releases/batman-adv-2024.0/ h2. Thanks Thanks to all people sending in patches: +* Linus Lüssing <linus.luessing(a)c0d3.blue> * Simon Wunderlich <sw(a)simonwunderlich.de> * Sven Eckelmann <sven(a)narfation.org> -* YueHaibing <yuehaibing(a)huawei.com> h2. batman-adv <pre> $ git describe origin/main -v2023.2-9-g5fecd4a3 -$ range=v2023.2..v2023.2-9-g5fecd4a3 +v2023.3-11-gecdc425a +$ range=v2023.3..v2023.3-11-gecdc425a $ git shortlog --email --no-merges "${range}" $ git log --no-merges "${range}"|grep -e '$Reported\|Tested\|Acked\|Reviewed-by\|Co-authored-by$-by'|sed 's/.*:/*/'|sort|uniq - -Sven Eckelmann <sven(a)narfation.org> (6): - -YueHaibing <yuehaibing(a)huawei.com> (1): - batman-adv: Remove unused declarations +Sven Eckelmann <sven(a)narfation.org> (4): features ======== + batman-adv: mcast: implement multicast packet reception and forwarding + batman-adv: mcast: implement multicast packet generation + batman-adv: mcast: shrink tracker packet after scrubbing + batman-adv: mcast: fix mcast packet type counter on timeouted nodes + batman-adv: mcast: fix memory leak on deleting a batman-adv interface + new kernel version ================== + batman-adv: compat: Fix skb_vlan_eth_hdr conflict in stable kernels + batman-adv: Drop support for Linux < 4.19 coding style cleanup/refactoring ================================ - batman-adv: Remove unused declarations - batman-adv: Avoid magic value for minimum MTU - batman-adv: Drop unused function batadv_gw_bandwidth_set - batman-adv: Keep batadv_netlink_notify_* static - batman-adv: Drop per algo GW section class code + batman-adv: Switch to linux/sprintf.h + batman-adv: Switch to linux/array_size.h various ======= - batman-adv: Check hardif MTU against runtime MTU - bugfixes ======== - batman-adv: Hold rtnl lock during MTU update via netlink -2023.3 (2023-11-15) +2024.0 (2024-01-30) =================== -* support latest kernels (4.14 - 6.7) +* support latest kernels (4.19 - 6.8) * coding style cleanups and refactoring -* only warn about too small MTU when soft interfaces wasn't already reduced -* bugs squashed: - - - Hold rtnl lock during MTU update via netlink +* Add stateless multicast packet format support </pre> h2. batctl <pre> $ git describe origin/main -v2023.2-1-g5b72033 -$ range=v2023.2..v2023.2-1-g5b72033 +v2023.3-3-gaf2806d +$ range=v2023.3..v2023.3-3-gaf2806d $ git shortlog --email --no-merges "${range}" $ git log --no-merges "${range}"|grep -e '$Reported\|Tested\|Acked\|Reviewed-by\|Co-authored-by$-by'|sed 's/.*:/*/'|sort|uniq + features ======== + batctl: mcast_flags: update to current state + batctl: tcpdump: parse batman-adv mcast packet type + coding style cleanup/refactoring @@ -99,10 +98,10 @@ bugfixes -2023.3 (2023-11-15) +2024.0 (2024-01-30) =================== -* (no changes) +* Add stateless multicast packet format support </pre> @@ -110,15 +109,14 @@ h2. alfred <pre> $ git describe origin/main -v2023.2-1-ge51f93a -$ range=v2023.2..v2023.2-1-ge51f93a +v2023.3-1-g729f31f +$ range=v2023.3..v2023.3-1-g729f31f $ git shortlog --email --no-merges "${range}" $ git log --no-merges "${range}"|grep -e '$Reported\|Tested\|Acked\|Reviewed-by\|Co-authored-by$-by'|sed 's/.*:/*/'|sort|uniq - -2023.3 (2023-11-15) +2024.0 (2024-01-30) =================== * (no changes)

1 0

[doc] main: Merge branch 'backup-redmine/2024-02-03' (4f3758cd)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branch : main >--------------------------------------------------------------- commit 4f3758cd896b6cf25db84596d7fc5dec7c0bfdf6 Merge: a4585a15 fbf96130 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Feb 3 13:49:26 2024 +0100 Merge branch 'backup-redmine/2024-02-03' >--------------------------------------------------------------- Diff suppressed because of size. To see it, use: git diff-tree --root --patch-with-stat --no-color --ignore-space-at-eol --textconv --ext-diff --cc 4f3758cd896b6cf25db84596d7fc5dec7c0bfdf6

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors (fbf96130)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit fbf9613096fb09d5cabe8c57b7b04398b771134e Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sat Feb 3 05:45:09 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- fbf9613096fb09d5cabe8c57b7b04398b771134e open-mesh/OpenHarbors.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/open-mesh/OpenHarbors.textile b/open-mesh/OpenHarbors.textile index 56500b20..5b2cc6b2 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -37,10 +37,10 @@ Unfortunately, WPA-Enterprise / Hotspot 2.0/Passpoint like as follows has concep With WPA-Enterprise: -* WPA payload frames are encrypted between the client device (ak. supplicant) and the AP it connects to through the Pairwise-Master-Key +* 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 (ak. authenticator). +* 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 ----

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors (fb8d8545)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit fb8d854543fc52c0f810a2efaa87d51913c8eb66 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sat Feb 3 05:43:10 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- fb8d854543fc52c0f810a2efaa87d51913c8eb66 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 12442199..56500b20 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -10,7 +10,7 @@ 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: -# A user's internet traffic is typically unencrypted in the WLAN mesh cloud +# 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) !OpenHarbors-diagram-freifunk-unencrypted.png!

1 0

[doc] backup-redmine/2024-02-03,main: doc: open-mesh/OpenHarbors (dd2e166d)
by postmaster＠open-mesh.org 03 Feb '24

03 Feb '24

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2024-02-03,main >--------------------------------------------------------------- commit dd2e166de6ff554ffbeff6f126f66a5b1ccdb513 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sat Feb 3 04:35:21 2024 +0000 doc: open-mesh/OpenHarbors >--------------------------------------------------------------- dd2e166de6ff554ffbeff6f126f66a5b1ccdb513 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 cbeee6c4..12442199 100644 --- a/open-mesh/OpenHarbors.textile +++ b/open-mesh/OpenHarbors.textile @@ -1,4 +1,4 @@ -h1. Idea/Draft: OpenHarbors ("Gotham Docks" / "WPAoverL2TP") +h1. Idea/Draft: OpenHarbors ("Gotham Docks" / "WPA over L2TP") **DRAFT / NOT IMPLEMENTED**

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits