Year: 2025

Introduction

Hello everyone!
I’m Agustin Trachta, a Computer Engeneering student at National University of Cordoba (Argentina), and I’m thrilled to be participating in Google Summer of Code 2025 with Freifunk, working on LibreMesh!

This summer, I’ll be focusing on simplifying and modernizing LibreMesh by:

• Migrating legacy components to OpenWrt-native solutions, such as replacing custom scripts like deferrable-reboot with watchcat, and moving DHCP handling from dnsmasq to odhcpd.
• Removing unnecessary complexity, like VLANs on Babel interfaces, which have caused compatibility and MTU issues.
• Creating a layer-2-only variant of LibreMesh tailored for lightweight community deployments, based on BATMAN-adv.

My goal is to help make LibreMesh leaner and more accessible to new users, especially communities that rely on low-resource hardware and need plug-and-play reliability. Many of these networks operate in rural or underserved areas where internet access is limited, budgets are tight, and technical expertise is scarce. In such environments, every kilobyte of firmware matters.

By replacing legacy components with OpenWrt-native solutions, we reduce the need for LibreMesh to maintain parallel tools, making the codebase easier to understand and integrate with upstream developments. Additionally, offering a layer-2-only firmware variant allows communities to deploy simpler, lightweight networks that require minimal configuration, consume fewer resources, and are easier to debug.

What I’ll Be Working On

The first task involves replacing LibreMesh’s custom deferrable-reboot script with watchcat, a integrated OpenWrt package. The original script was created to schdeule periodic reboots in order to recover from possible instability after long uptimes, great idea but it’s already implemented in a more robust way, allowing also to trigger network interface restart based on ping failures. Migrating to watchcat ensures better integration with OpenWrt’s LuCI interface.

The second task focuses on improving DHCP handling by transitioning from dnsmasq to odhcpd. While dnsmasq is widely used and remains excelent for DNS forwarding, it’s not ideal for handling modern DHCPv6 configurations and dynamic lease sharing. This migration has been requested for years by the community, and I will work hard on making this a reality!

The third task is about removing VLAN from Babel routing interfaces. LibreMesh always used VLANs to isolate Layer 3 traffic from BATMAN-adv’s Layer 2 mesh, but it introduced issues like lower MTUs, hardware incompatibilities and added configuration burden. My work will include applying and testing relevant patches that have already been worked on, updating configurations and validating that removing VLANs does not introduce routing lops or instability.

Finally, I’ll be developing a Layer-2-only version of LibreMesh, this is other request from the community members who want a simpler and lighter firmware that doesn’t include routing extra daemons. In small mesh networks, users only need a transparent Layer 2 bridge using BATMAN-adv and gateway node doing NAT, my goal is to create a dedicated firmware profile that includes only the essential packages for a Layer-2 mesh and removes unnecessary services. This variant will help networks that value simplicity, speed, and minimal configuration, especially on older routers with tight resource constraints.

Plan of action

To ensure that each change is reliable, compatible, and valuable to the LibreMesh community, I’ll follow a staged and test-driven approach throughout the project.

I’ll begin by setting up a virtualized test environment to quickly prototype and iterate on changes. In parallel, I’ll be using at least three physical routers compatible with LibreMesh to validate the behavior of the firmware under real-world conditions.

Each task will follow a similar cycle:

1. Development and Integration of the change in the LibreMesh build system.
2. Configuration and Testing, both in isolated and multi-node environments.
3. Documentation and Feedback, where I’ll share results with the community, post updates, and adapt based on what users report.

I’ll be actively engaging with the LibreMesh mailing list, GitHub issues, and chat channels to keep the process transparent and collaborative.

Conclusion

I’m very excited to be working on this project as part of the GSoC 2025. I’m looking forward to collaborating, learning, testing, and sharing throughout the summer!

Also I would like to thank my mentor, Javier Jorge, who will be guiding and teaching me a lot about open source projects and local networks.

Hello everyone! I’m Victor Spehar, a Master’s student from Paris studying operating systems and distributed systems, and this is my first blog post for Freifunk!

This summer, I will be participating in Google Summer of Code 2025 for the Freifunk sister organization, LibreMesh, under the mentorship of Javier Jorge, where I’ll be working on adding Wi-Fi support to QEMU simulations in LibreMesh.

In simple terms, the goal of this project is to have:

• A fully virtualized Wi-Fi router running LibreMesh firmware
• The ability to “bridge” these virtual machines through their Wi-Fi interface in order to create a mesh network
• A more realistic testing pipeline – as far as virtualization goes – to catch regressions earlier and improve overall reliability of LibreMesh

What Is LibreMesh?

LibreMesh is a modular framework for creating OpenWrt-based firmware for wireless mesh nodes. It aims to enable non-expert users to set up mesh networks and manage them through a simple web interface.

Setting up LibreMesh goes like this :
First, find your router, then follow the installation procedure, and voilà – you have a node that is set up and ready to mesh!

Wi-Fi mesh networks provide an easy, cost-effective way to distribute Internet access in large buildings or public places, but they can also effectively be used to bridge 60+ families together. In LibreMesh, it’s simple to host services on each node because every router has its own hostname, making it easily reachable from anywhere in the mesh.

Testing in LibreMesh

Testing is an essential part of any software project: it ensures that new changes don’t introduce regressions and that features work as intended across different environments.

Currently, LibreMesh firmware testing is done in multiple ways:

Unit Tests of the lime-packages

Individual lime-packages are covered by unit tests. A Docker container emulates the OpenWrt userland, but all system-level configuration – which normally runs through UCI – are mocked or stubbed out.

• Pros:
  • Easy to run, providing quick insight into which package might be broken
  • Generates coverage metrics
• Cons:
  • Not so easily expandable : mocks up need to be set up
  • Does not emulate a real-world environment, and the distributed nature of LibreMesh
  • Abstracts the entire kernel, system configuration cannot be tested that way

Testing on Real Hardware

LibreMesh is tested on real physical routers, but this process is:

• Hardware intensive: Multiple routers required and possibly different clients (laptops, smartphones, etc.) to connect to the mesh
• Time intensive: Each router needs to be flashed with the correct firmware version, all hardware must be set up, configured, and every steps should be documented manually

Additionally, there are currently no automated tests or a documented, repeatable procedure for hardware testing. This kind of testing is not easily reproducible, lacks observability (the bane of a distributed system – and it’s even worse when you are transmitting data over thin air!) and requires manual effort and lots of steps, but it remains essential to catch hardware-specific regressions.

QEMU-Based Testing

At the moment, LibreMesh provides scripts to spin up multiple virtual machine instances and connect them via an Ethernet bridge. Unfortunately, this setup does not cover LibreMesh’s core feature set: Wi-Fi meshes. Moreover, although these virtual machines provide helpful information to developers, no automated tests exist for this environment in LibreMesh, meaning no repeatability.

Since some communities rely on LibreMesh firmware for Internet access, an undetected regression in a new release could cut off users from essential services. Ensuring robust and reproducible testing during development is therefore essential.

Further integrating QEMU-based testing into LibreMesh will enable more realistic scenarios: no more mocking or stubbing for general system configuration testing, and the ability to perform Wi-Fi tests in a virtualized environment by leveraging the Linux mac80211_hwsim kernel module – already widely used by kernel developers for testing Wi-Fi.

A beneficial side effect: Once a test is set up for a QEMU virtual machine, it now can also run on real hardware ! The tests meant for a QEMU virtual machine should run the same on real hardware, meaning from two birds, one stone!

Plan of Action

The Linux mac80211_hwsim kernel module provides support for virtual WLAN devices – allowing us to access, configure, and observe a virtual Wi-Fi interface. It allows the users to set up, monitor and test all kind of configuration for Wi-Fi – no limitation in software compared to hardware, and it’s also not bound to legislation since all of this is virtual, and no radiowave being emitted. A detailed article describing its use can be found here

The idea would be to create a LibreMesh virtual machine with full Wi-Fi support that could speak to similar virtual machines through the Wi-Fi stack, effectively creating a Wi-Fi mesh network, while also being truly observable, tunable, and testable. This will give us complete control over the testing environment: different topologies, latency scenarios, even roaming tests that would be difficult or impossible to recreate in real life without a large real life setup.

To achieve this, I will have to :

• Include the mac80211_hwsim module in a LibreMesh QEMU image and verify that the VM boots with virtual radios
• Bridge VMs through their virtual Wi-Fi interfaces so guest radios can communicate directly via Wi-Fi frames
• Develop a set of scripts using RPCd interfaces for network diagnostics (e.g., checking link quality, peer discovery)
• Implement automated tests for different mesh scenarios (e.g., single-link failures, packet loss, variable TX power, multi-hop reachability, routing effectiveness)
• Integrate these new tests into LibreMesh’s existing testing framework

My project will enhance LibreMesh’s QEMU testing environment, improving development efficiency and deployment reliability. It won’t replace hardware testing but will catch bugs earlier in development with a faster, more robust testing pipeline and a controlled and repeatable environment.

Throughout my project, I will communicate with the LibreMesh community, sharing technical details about Wi-Fi integration in a virtualized context and providing documentation for setting up and testing LibreMesh with these new features.

Google Summer of Code: A Fantastic Opportunity!

I would like to thank everyone who made this possible. I’m truly grateful to GSoC, Freifunk, LibreMesh, and my mentor, Javier Jorge. This is my first step as an active open-source contributor and the beginning of a long, exciting journey where I’ll learn a lot!

For any suggestions or comments on my project, you can find me on the LibreMesh mailing list or the Matrix chatroom: libremesh-dev:matrix.guifi.net

Introduction

Hi everyone! I’m Raul Shahi, a Master’s student in Computer Engineering for IoT Systems at Nordhausen University of Applied Sciences, Germany. I’ve been working as a Research Assistant at my university, where I’ve been developing and experimenting with tools for Wi-Fi resource control.

I was also a part of GSoC 2024, where I worked on Throughput-based Dynamic WiFi Power Control for Real Networks. Please feel free to check this blog for the project.

For GSoC 2025, I will work on building a Deep Q-Learning (DQN)-based Wi-Fi Rate Adaptation algorithm for IEEE 802.11ac networks. This project leverages machine learning techniques to address the limitations of traditional rate adaptation algorithms in dynamic wireless environments. In this blog post, I’ll walk you through the motivation, approach, and expected outcomes of the project.

Motivation

Rate Adaptation(RA) in Wi-Fi networks refers to the selection of the optimal Modulation and Coding Scheme (MCS) to maximize data throughput in the presence of varying channel conditions. As wireless links experience fluctuations due to interference, mobility, and environmental factors, a robust RA mechanism is crucial for achieving high performance. RA is a MAC-layer task that must respond rapidly and intelligently to the dynamic nature of wireless channels. The complexity of this task continues to grow with the expansion of the MCS index space, advancements in Wi-Fi standards, and increasingly heterogeneous network topologies.

Several RA algorithms have been developed to address this challenge, with Minstrel-HT being the default RA algorithm in the Linux kernel. While Minstrel-HT performs well in relatively stable conditions, its responsiveness and decision quality tend to degrade in rapidly changing environments, often resulting in sub-optimal throughput and increased latency. Study such as MAC-Layer Rate Control for 802.11 Networks: A Survery [2] provides comprehensive overviews of these limitations.

Recent research has explored the application of Deep Reinforcement Learning (DRL) to Rate Adaptation (RA), showing potential performance improvements over traditional heuristic-based methods by learning RA policies directly from network statistics such as Signal-to-Noise Ratio (SNR), throughput, or ACK failures [3, 4]. However, most of these SOTA approaches are evaluated solely in simulated environments (e.g., ns-3 or MATLAB), lack validation on commercial off-the-shelf (COTS) hardware, and often consider outdated standards like IEEE 802.11n. Additionally, they usually operate on a reduced set of MCS indices or simplified network models, which limits their applicability to modern Wi-Fi deployments with complex topologies and diverse traffic patterns.

Moreover, implementing DRL in practical systems presents inherent challenges: DRL agents typically require substantial computational resources and time for training, making real-time learning and deployment on embedded devices difficult. These issues hinder the direct transfer of DRL-based RA algorithms from simulation to real-world applications.

This project aims to bridge this gap by leveraging the ORCA API and RateMan framework to deploy and evaluate a DRL-based RA solution on real IEEE 802.11ac hardware, with minimal overhead and full observability into transmission statistics.

To overcome the lack of practical platforms for evaluating advanced RA algorithms, this project builds upon ORCA[1], a kernel-user space API that exposes low-level transmission statistics and allows runtime control over Wi-Fi parameters such as MCS, bandwidth, and spatial streams.

On top of ORCA, we utilize RateMan[1], a Python-based interface that simplifies per-STA rate adaptation and integrates cleanly with real-time experimental setups across multiple access points (APs). This setup offers a testbed that is both flexible and extensible, making it well-suited for developing and evaluating DRL-based RA algorithms.

Fig 1. Overview of the architecture of the user-space resource control using RateMan via ORCA[1]

This setup abstracts away kernel-level complexities, allowing developers to focus on high-level algorithm design for rate adaptation. By integrating Deep Reinforcement Learning (DRL) into this user-space framework, we can overcome the limitations of prior work, such as reliance on simulation tools, limited rate sets, or outdated standards and evaluate learning-based approaches directly on commercial off-the-shelf (COTS) Wi-Fi hardware. This bridges the gap between theoretical advancements and practical deployment, enabling reproducible and scalable experimentation in real environments.

Methodology

A Deep Q-Network (DQN) is a reinforcement learning (RL) algorithm that uses deep learning to estimate the Q-function, which represents the cumulative reward of taking an action in a given state.

Fig 2. Illustration of state, action, and reward sequence in the interactions between the agent and environment within the reinforcement learning algorithm [5]

We’ll use the ORCA API and Rateman as our experimental framework. Here’s a high-level overview of our approach:

• DQN Agent Design: The agent observes channel statistics (e.g. throughput, retries, SNR) and learns to select optimal data rates.

• Environment Feedback: The environment will be represented through Rateman, which interfaces with ORCA to provide real-time feedback in the form of Transmit Status (txs) events from OpenWrt-based nodes. These txs events encapsulate per-frame transmission statistics such as retry count, transmission rate (MCS), and success/failure outcomes. This detailed low-level feedback serves as the observable state for our learning agent, enabling fine-grained adaptation and evaluation of RA policies on real hardware.

• Reward Function: We’ll design a reward function based on achieved throughput and transmission efficiency.

Learning: The agent updates its decision policy based on the rewards received, continuously improving its ability to choose optimal actions.

Training Strategy: We’ll apply experience replay, epsion-greedy exploration, and target network updates to stabilize training.

Evaluation: Compare performance against baseline algorithms like MInstrel-HT in both stable and mobile scenarios.

Setup

For the experimentation and evaluation of the DQN-based rate adaptation algorithm, I have access to two primary test environments:

• Local OpenWrt Setup

A pair of OpenWrt-based nodes is configured, one as an Access Point (AP) and the other as a Station(STA). This setup allows for short-range, controlled experiments where the data transmission between the AP and STA can be directly observed and influenced in real-time. The system logs transmission statistics such as throughput, retry rates, and modulation rates, which are essential inputs for the learning algorithm.

The basic setup is ideal for testing initial versions of the DQN agent, debugging learning behavior, and validating the integration with the Rateman interface.

Fig 3. Local Desk Setup

• Remote Shielding Box Environment

Additionally, a remote RF shielding box setup is available, which offers an advanced testing environment. The shielding box can emulate various wireless channel conditions by introducing configurable attenuation, effectively emulating mobility, interference, or range variations. This is particularly valuable for testing how well the DQN agent adapts to dynamic network environments.

Together, these setups provide a well-rounded experimentation environment. The local OpenWrt pair allows for fast prototyping, while the shielding box supports in-depth analysis under variable channel conditions. This ensures the project has ample experimental infrastructure to develop, test, and fine-tune the proposed Learning-based rate adaptation (RA)l algorithm.

Deliverables of The Project

The main outcomes of this GSoC project are : 

1. A modular, well-documented DQN-based Wi-Fi RA agent integrated into Rateman.
2. A training and evaluation pipeline for testing the algorithm on real hardware using ORCA.
3. Performance analysis comparing our method with standard algorithms in dynamic and static environments.
4. A comprehensive technical report and user guide to help others replicate or extend this work.

What has been done until now?

So far, the initial groundwork for the project has been laid out, with the following accomplishments:

• Explored the fundamentals of Deep Q-Learning (DQN) by implementing and experimenting with standard reinforcement learning environments such as FrozenLake and CartPole. These helped build an intuitive understanding of how Q-learning and neural networks interact in dynamic decision-making problems.
• Familiarized with the ORCA API and RateMan interface 
• Successfully set up the experimental testbed with a pair of OpenWrt nodes configured in AP-STA mode. This local setup has been validated for basic connectivity and is ready for integration and testing of learning-based algorithms.
• Studied the performance and limitations of existing ML-based rate adaptation (RA) papers to refine scope.

While the concrete architecture for integrating the DQN agent with real-world transmission feedback is still under development, the foundational components are in place. The next phase will focus on defining a robust training pipeline using txs statistics and determining how to feed real-time feedback into the learning loop.

What’s Next?

• Implement the DQN agent and environment class using PyTorch.
• Integrate the agent with Rateman to observe real-time transmission feedback.
• Begin training and hyperparameter tuning on experimental data.
• Evaluate performance and iterate over model improvements.

Conclusion

I’m incredibly excited to begin this project as part of GSoC 2025! By merging Reinforcement Learning with real-world Wi-Fi experimentation, this project aims to push the boundaries of rate adaptation in wireless networks. I hope this work contributes to more intelligent, efficient, and adaptable wireless systems, and I am looking forward to sharing updates as we move forward. 

Feel free to reach out if you’re interested in the project or have any questions.

References

1. Pawar, S. P., Thapa, P. D., Jelonek, J., Le, M., Kappen, A., Hainke, N., Huehn, T., Schulz-Zander, J., Wissing, H., & Fietkau, F. 

Open-source Resource Control API for real IEEE 802.11 Networks. 

2. Yin, W., Hu, P., Indulska, J., & Portmann, M. (2020). 

MAC-layer rate control for 802.11 networks: A survey. Wireless Networks

3. Queirós, R., Almeida, E. N., Fontes, H., Ruela, J., & Campos, R. (2021). 

Wi-Fi Rate Adaptation using a Simple Deep Reinforcement Learning Approach. IEEE Access. 

4. Karmakar, R., Chattopadhyay, S., & Chakraborty, S. (2022). 

SmartLA: Reinforcement Learning-based Link Adaptation for High Throughput Wireless Access Networks. Computer Networks. 

5. State-Action-Reward Diagram