commits August 2024

commits@lists.open-mesh.org

1 participants
41 discussions

[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

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

01 Aug '24

The annotated tag, v6.10.2 has been created at 7ed333d041c7d6e4e5176f4c2b6f7865edb57b3f (tag) tagging 2d002356c3bb628937e0fb5d72a91dc493a984fe (commit) replaces v6.10 tagged by Greg Kroah-Hartman on Sat Jul 27 11:40:43 2024 +0200 - Shortlog ------------------------------------------------------------ This is the 6.10.2 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmakwJsACgkQONu9yGCS aT7aBw/8CDokcAJ2ybxQOfyBAv3jdvB8Hos8jp6v7/wbJjzXPNfmFEMPblSywOKz 092MDGQZg0VIOTd642J+keAzmDHED0kjLD56EJr64M9BHggLy0Q1qj2z4KosI5Qa 9folBTGd8PvFn+6QVVshQvyvuvn5TPsjXQSmmc+tOm/s5IbE8M/eE6B3SGbHLwaD fY1dQHnYQuDH1cCeVloV/e36TYhKx9bEVEzomSPYxeEDyG8J083fU0gwuRIB9teD xBMyFZHnj9bEsu9VxyFBd287hHKIm+Kv7TBHVe3QV1KC/FDZ+tyNsj+9rc+tJlup 1VWPYUeytFbE0nyq+tx53Ml894Un+x8E7TjT9L7T5//KCAqaxl3EmuLXVj5YEgyT 1Fn+o+Dp+6zAi+r7c7U9QMpDRRyMfeC12nIKTbDigE+mkzHHh0slXlEBmcNBlgkh FhUZV3bChs4bRayoMiewZfOVa20ubQaGuL2+/MF+LwiUKo7hLCURQ38jWE6MooUL 57+Y1YbPgjXE6p9LhEFWKPy8AmNzabTnBBYQGaNNK1xYgpzaGviq9g0cZy8uNQ3L Y1MA9bN2q/tmxXZATkCiqM2PiplJb0kiuaY/8FpNkU+7VeYQpXYWfifbW/zKwsd4 2MiryLnZKUvrSm/gKuPWwIxYxe92wAwvlCMJ3jmQMK42zQAzEZM= =vSF+ -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

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

01 Aug '24

The annotated tag, v4.19.319 has been created at 24371c5e00ac0b1456707733e90290c00568d010 (tag) tagging bd67cb15e90fa8b47b84e8554569ef5657a05c80 (commit) replaces v4.19.315 tagged by Greg Kroah-Hartman on Sat Jul 27 10:34:13 2024 +0200 - Shortlog ------------------------------------------------------------ This is the 4.19.319 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmaksQUACgkQONu9yGCS aT5OpQ/+K4AfHjtxA+9r2Y37MrlCCetA57xbQORnHU6t20Vve+4xl/rlEi0l5FL1 QkJUWD8bhByOHfO/wHSJewjnd+HB3MsTYnk/E+UD3COUyWWZYDe68CR7V3O1jf4F Wu3ufkZ294ZXNc6wWPkBvybagqQFqdXEej0I65J6bYcJJy0QymzofZ90BQawP3cM IwOU+5MQ6vPWHaDXzelEJMXj2ZUbPdpYBSt5R6XcdS54p5sB9EFBBImgOxvctJpJ HYt/UCToz+L1tgOY51f0qnGgmOQxlyy7P+72gvjqfvqlKbn/602Io8Vcn/EDcGkF qkbHnGaKyqh0vcAf8UPaZ2wBowZ2EouynP+WTriwGsURhr6LHlJxazQBbP0r7DqL GBC2yn/BofNVMXZ5Uj03+AkBjojTEFgDKbGXQqmgHQ7zwfQNZXVru0FT3yXKtC1w es9VMBRU7BJHe9UhYrlW50UD6f2eI9PR+GyhCP6lWH2N4+CLlzEZRd7/dCgC1Rxl hIHRc9TXfQo8S9uKYHYO3vygDWytOg9EHNwpnsHfC94jksR6T9HdudJMqLk/RBje WB0vVu17YVakv+8ykIRJQ8vNcL2mNXb2WuTOF5xLnLH9setN6xnwW0Q7OXsBWW5P BuaPlBPyYU2onbcLEUC9XJQ1u4MFpePtWWbDtrsEQ90j6+Sj3sU= =0Syt -----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, v5.4.281, created. v5.4.281
by postmaster＠open-mesh.org 01 Aug '24

01 Aug '24

The annotated tag, v5.4.281 has been created at c9e29cadf0e64f4eb55131629977e4ce2c388c23 (tag) tagging 84d75fd864979b0228cfe7170a359c0a60f04a98 (commit) replaces v5.4.277 tagged by Greg Kroah-Hartman on Sat Jul 27 10:39:00 2024 +0200 - Shortlog ------------------------------------------------------------ This is the 5.4.281 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmaksiQACgkQONu9yGCS aT6WTw//aaGRbEkRWNuJKZ4vLTl8W4jRW2iWoSchPoXVJ1/xzOj5GGxGN3QVL0cC 5z0VslncxsfqCuHNIUlMG1nHhtG+P3T0w6vHe4IX/X8FJzpYsQsaTx42jGZedGkZ dV4ksCtJ6VWR/zeApf4jBbFDisxy2FelAvHoOFiXdgXznyVbeglCHxu9gCArM+qA 08Y0iEIK29WTvmMDfvekTi1OrBQSm8p9QsD/pXUH3D7Y863rm+K8Gv3B4Po4l8mH RPyi+B/FX+j7Gk6RWfw2tJ9Y+7bOLt6Pt9Zc8ImKdjXSUxfphznfsuOY8gO09WnN izqibrudoMmD/VQDR3VosTy0X9d32Jd1iGovwBID+4D+Sg8mqOQ97x1+f9nfcw5/ D1tgRanO7L7wVFIjgvbOq6j5u3Bp/J2CNQJUfRcPa95+TJUU0AWPf3NGb56kQQlF L1JW0rMizSOzsROiki0JBH80nxwCukVk5SBetN/OoyusyRlkYqBrlSKaB+Nz/7Q9 rJ/23X9fvbp2cMjRULIXZjBwPsg7U6ZcimS88ZLsH88/4oBqgEUGSBQPuEA4Ix9C uvNQPum0y2hTFYYI/mGRt5kWcPqqJWmMNNf/u/1HCzYXpc3nKQUedKyKuXRi3lYh i7pc9IPG5ey9jnB+bSImq/ykjzP51rxV1/NsQ21HakaaY+rgiY4= =j/gs -----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, v5.10.223, created. v5.10.223
by postmaster＠open-mesh.org 01 Aug '24

01 Aug '24

The annotated tag, v5.10.223 has been created at b8198d9fc02df54d53d83b8b851975c304e283aa (tag) tagging b15dc4170c6317731c00fa8fe7d4d99a0a04c83c (commit) replaces v5.10.218 tagged by Greg Kroah-Hartman on Sat Jul 27 10:40:28 2024 +0200 - Shortlog ------------------------------------------------------------ This is the 5.10.223 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmaksnwACgkQONu9yGCS aT4PcQ//fATT8wjblT5zZ2dKy/LsTD8xKD8YfNKJDYvuYIMtli1hXmpQeeY237yt d/zepYo4pN6onVa00S0gob2TUeR+Zz1/o++blIGsHzU26wme6hkSyvrFys88dR+h BDTscrW9Q5ApFg7pJxvqkj+kpirqskXVXS1g2b7OA/8JY1hmDX6X9vxlwXJTaam2 wjUv+xblOAptmuTmZWxvgiezqJ6nwU8085+F60TOhDdOjx5MAmDbdVqDv2hXQE/U VIjZqhUFXxomckwjaN9B2lAFYWxT30aR9+OKUzuck3eLEe4xrcohv6NdZ88obHRM 8YWqjjubYhpkfnQ+AsCTPFFNeK3NbnhDADwLIazPdyNUnd76HhVfs/yZOuE/hWPi mLz7o+UUBwdmR13qJzYwAgN/ddLZV4VGCmRma3XneSwOAQhEkHomlSjplOc7GafG QgKTxM7tmbcdM/NTH6Am+Bc3y9nI2NkjgV5fafant6xj++n7HDAI07UK5L/vUMcF QxA/jn74MB9YG71BKXRT6xfVRhUGLQ/OMXBxdyUvUOFCa7nggYm7qCI+S5KdUz50 UP7KPmBBntsd6Mr06QaH+fgXszjZSSHXhHgeL5QRFZDUVvOWK66XS5S3Z+Ll3xgc /26iJ1qYuGFj4k34ab6lM3q2ZuHAT1jS5URY6uVwxWN2BJDvGDQ= =7Kf2 -----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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits August 2024