Hello everyone, I’m Pierre, I was first introduced to Freifunk when searching for free WiFi in a cafe in Berlin, and I’m inspired by the radical visions of people attaching antennas to apartment buildings. Now I’m here to work on the community data API.
Since 2014, Freifunk has been collecting a snapshot of information about all communities, every hour, in a big directory available here. At the moment the data is being used for a calendar, a news feed,1 and a map of communities, among other services. Maybe you can think of lots of other things which could be done with that data, but first you would have to parse some 80,000+ compressed JSON files.
The goal of this Summer of Code project is to overcome that hurdle up front; make this community data more easily accessible, and uncover some insights about the network along the way. This is a typical situation for large archives, where one of the key challenges is making data readable and useful.
I intend to build a pipeline from the JSON directory through to some visualisations on a web page. One step behind that, I want to expose a GraphQL interface so that anyone else can query the data for their own purposes. The main part of this project revolves around setting up infrastructure to handle each section of this pipeline.
Although this system is conceptually very simple, there are lots of moving parts involved. The JSON files are loaded into a SQL database, the database talks to GraphQL, which itself talks to some browser-based visualisation library.
I’ve tried to make choices which prioritise boring technologies, reduce the fragility of this process, and hopefully make it easy to maintain in future. I will build it from the top down; starting with the database, and finishing with the visualisations themselves.
I’ll be working in this repository. There’s not much to show at the moment, but it should rapidly take shape in the coming weeks. My next post will be about the process of loading these files into a database.
Hi everyone. I am Raul Shahi. I am currently pursuing a Master’s degree in Computer Engineering for IoT Systems from Nordhausen University of Applied Sciences, Nordhausen, Germany. For the past couple of months, I have undertaken the position of Research Assistant at my university, which involves researching and developing open-source software for IEEE 802.11 resource allocation.
For GSoC 2024, I will work on a novel Power Control algorithm to reduce interference and increase aggregate network throughput. This introductory blog post intends to summarize the necessary background to understand the details of the project.
2. Leveraging TPC performance for enhanced WiFi Performance
Regarding WiFi networks, ensuring everything runs smoothly is all about how we manage the available resources. As the concept of WiFi resource allocation has been covered by Prashiddha during his GSoC projects before, I would suggest the readers to refer to his blog posts [3][4]. For IEEE 802.11 devices, deep diving into the system internals is required which can be overwhelming for developers as they would have to be familiar with kernel subsystems and Ansi C. This technical barrier makes it tough to adapt and innovate with new algorithms.
On top of that, many of the latest WiFi chips are becoming closed-source which means the open-source community can have a harder time developing new and advanced algorithms. However, chips like Mediatek, still share throughput information which can be utilized for the optimization of WiFi networks.
Active Transmit Power Control (TPC) is an exciting development area. By adjusting the transmit power for different devices, TPC algorithm extensions like Minstrel-Blues which is built on top of the Minstrel rate control algorithm are promising. They can reduce interference, boost overall network throughput, and improve how the network handles multiple devices in crowded spaces.
3. Motivation
To solve the challenges in WiFi resource allocation, the SupraCoNex project introduced the user-space WiFi Parameter Control API and an interface called Python-WiFi-Manger to enable the development of algorithms using Python. Developers can use these tools to create and test their algorithms on real WiFi chips. On top of the API, a remote socket extension has been realized to facilitate the remote management of access points. The API allows users to monitor transmission data and adjust rates and power on access points without technical knowledge of the kernel.
I propose developing a new transmit power control algorithm using the WiFi-Manager for IEEE 802.11 ac chips, based on throughput estimates. This approach could potentially extend to Mediatek ax chips, paving the way for smarter, more efficient WiFi networks. However, the approach can be easily extended to any chips that expose the estimated throughput information and provide an interface to fine-tune power settings in real-time.
4. Methodology
The WiFi-Manager package allows the user to monitor each transmitted frame while leveraging the options to control the rate and power for each connected access point. The first task will be to create a new Python package for the power controller and integrate it with WiFi-Manager. Since WiFi-Manager does not yet include throughput information, we will either add it to WiFi-Manager for broader use or directly into the power controller.
The power controller will track throughput at different power levels and average these observations using techniques like the Butterworth filter on EWMA. This can be the basis for determining the optimal transmission power. If throughput suddenly drops, the controller will have a fallback strategy, such as increasing power aggressively to restore the link quickly.
Like the Minstrel-HT [1] and Minstrel-Blues [2] algorithms, our power controller will have update and sample intervals. At the end of each update interval, it will adjust the power level based on recent observations. During sample intervals, it will explore different power levels to find the best settings.
The existing solutions from the Experimentation Python package from SupraConeX can be used to compare the proposed approach, evaluating performance based on rate selection, aggregation, throughput, and power levels.
5. Deliverables of The Project
The end goals of my GSoC 2024 project are as follows:
a. Implementation of a dynamic power control algorithm to adjust power levels based on throughput information with ready-to-run demo.
b. A detailed report documenting the research methodology, experimental setup, results, analysis and conclusions drawn from the study.
c. A study conducted using scnx-experimentor Python package that compares the performance of the proposed approach with the existing solutions on productive Freifunk Mesh and Access deployments.
6. What has been done until now?
a. Developed a foundational understanding of the importance of resource allocation in wireless transmission.
b. Familiarization with the ‘WiFi-Manager’ package as well as other packages from ‘SupraConeX’.
c. Remote access point setup for monitoring of data transmission and power, rate control.
7. What’s next?
a. Create a python package for power controller.
b. Preliminary performance comparison and evaluation of developed algorithm.
8. Conclusion
I am incredibly grateful to be part of GSoC 2024 as we embark on this exciting journey. Developing and implementing a new power control algorithm with WiFi-Manager is just the beginning, and I am thrilled to contribute to innovations that could significantly improve WiFi performance. This project promises to push the boundaries of what’s possible in wireless communication, and I look forward to sharing our progress and successes with you.
Please feel free to reach out and connect with me.
Hi everyone, I am Gabriel, and I am currently studying Web Application Development and Mobile Application Development. This summer, I will be participating in Google Summer of Code 2024 to work on developing a Modular Assistant for OpenWrt.
Abstract
The goal of this project is to develop a modular assistant for OpenWrt that simplifies the initial configuration of OpenWrt devices. This assistant will enable users to configure their devices quickly and easily, even without deep knowledge of wireless routers. The assistant will be implemented using LuCI, a framework for creating web interfaces for configuration and monitoring.
Plan Of Action
This project will focus on creating an assistant that guides users through the initial configuration of OpenWrt devices. The assistant will have a modular design, allowing it to be adapted to different scenarios and specific needs of communities like Freifunk.
Implementation
Analysis of LuCI’s Client-Side API:
Understanding the operation of LuCI’s client-side API will be fundamental for the development of the assistant.
Development of rpcd Services:
Learn how to write rpcd services for communication between the user interface and the backend of the OpenWrt system.
Configuration of Permissions and Menu Entries:
Configure permissions and menu entries to ensure an intuitive user interface that is easy to navigate.
Adaptable Modular Implementation:
Develop the assistant in a modular manner, allowing it to be adapted to different scenarios through scripts.
Deliverables
Creation of a stable, working modular assistant for OpenWrt.
Detailed documentation explaining the implementation and use of the assistant.
Ensure the assistant is adaptable for different scenarios and needs of the Freifunk community.
Concluding
I am delighted to be part of the GSoC 2024 program and contribute to the Freifunk project. I’m looking forward to collaborating with the Freifunk team to create a valuable tool for the community.
I would like to thank my mentors, Martin and Tobias, for their guidance and support. I hope to have a productive and successful summer working on this project.
Very happy to be in this project. Piranha captive portal solves a well-known problem in community networks: the ability to manage vouchers and access to the internet and local services. As it says in it’s README:
It could be used in a community that wants to share an Internet connection and for that the user’s pay a fraction each, but needs the payment from everyone. So the vouchers allows to control the payments via the control of the access to Internet.
My name is Henrique and I’m currently working as a substitute teacher. My background is system administration and computer networks, so developing this project will be really challenging but I feel very comfortable doing so.
I’m also part of Coolab, a collaborative laboratory that fosters communities networks in Brazil.
Context
This project aims to develop the new release of Piranha, a package from Libremesh that enables communities networks to setup a captive portal and control/share internet access in a sustainable way. Currently Piranha is only supported in OpenWRT version 19.07.
The following are objectives of this project:
Migrate from iptables to nftables;
Include Piranha package on OpenWRT repository
Make necessary changes to work with DSA on newer routers
The use of captive portals in communities enables the creation of vouchers and parental control, for example, it’s possible to disable access to social networks during night time. Since community networks can have multiple gateways to the internet, there’s a need to share information about current vouchers. This problem is solved by the shared-state package. Below is an illustration of a home user setup and a community network setup:
Regular internet accessCommunity network internet access with multiple gateways
Acknowledgment
I would like to thanks Hiure and Illario from being my mentors on this project. Libremesh is an awesome project that enables non-technical people to deploy a mesh network in a matter of seconds.
Conclusion
I’ve never developed or upgraded a package before, i’m more into system administration, so it will be really challenging. 🙂
Thanks for reading and see you in the next post! Happy coding!
Hello everybody! My name is Til, and I am currently a Master’s engineering student at the University of Applied Sciences Nordhausen. For the past year, I focused on Linux network programming, especially eBPF, which brings me to my GSoC 2024 topic.
Over the years, the network stack has evolved to support new protocols and features. The side effect is that this introduces overhead and might hinder network throughput, especially on CPU-limited devices. One solution to overcome this is eBPF.
eBPF and its hooks
eBPF (extended Berkeley Packet Filter) is a technology within the Linux kernel that allows to dynamically re-program the kernel without recompiling or restarting it. Developers can write programs in C code, compile them to BPF objects, and attach them to several so-called hooks inside the Linux kernel. You can use two hooks to redirect incoming data packages to other NICs inside the Linux network stack: XDP and TC.
The XDP (eXpress Data Path) hook is located even before the network stack itself; its programs are attached to the driver of the NIC. That should make it the fastest eBPF hook throughput-wise for redirecting packages. But there is a catch: NIC drivers must support this so-called “XDP native” mode. Otherwise, you need to attach them through the so-called “XDP generic” mode inside the network stack, which is significantly slower than native, which you will see soon in this post.
The TC (Traffic Control) eBPF hook is already located inside the Linux network stack but is driver-independent, so only the Linux Kernel needs to support it, i.e., compiled with the respective symbol enabled.
My GSoC 2024 project
My GSoC 2024 topic/goal is to introduce a new firewall software offloading variant to OpenWrt using eBPF. The idea is to intercept an incoming data packet from the NIC as early as possible inside or even before the network stack through XDP or TC. Then, for the actual firewall part, apply possible NAT (Network Address Translation) and drop or redirect the intercepted package to another network interface. That saves some CPU cycles and hopefully increases the network throughput on CPU-limited devices.
There are mainly three parts that need to be designed and implemented:
The eBPF program which intercepts, modifies, and redirects or drops network packages
A user-space program that attaches the eBPF program to the NIC(s) and checks the actual firewall rules
A BPF map used for the communication between the BPF and the user-space program
The caveat of XDP generic
As mentioned, you can use the XDP generic mode if your NIC doesn’t support XDP native. Theoretically, the XDP generic mode should be faster than TC because the XDP generic hook still comes before the TC hook. But there is a problem: For XDP generic, the Linux kernel has already allocated the SKB for the network package, and XDP programs must have a package headroom of 256 Bytes. That means if the pre-allocated SKB doesn’t have a sufficient headroom of 256 Bytes, it gets expanded, which involves copy operations that effectively negate the actual performance gain.
I created a patch that, rather than making this package headroom value constant, creates a Linux kernel variable for that headroom exposed through the sysfs interface to Linux user space. It still has the default value of 256 Bytes, but then the user can explicitly lower the XDP generic package headroom according to his requirements.
The following table presents the head of a report generated by the Linux tool perf after running an iperf3 TCP test for 30 seconds through an MIPS router. I tested using an XDP generic package headroom of 256 Bytes first and then 32 Bytes. It shows how much CPU cycles this copy operation wastes.
I will tidy up and try to submit that patch to the upstream Linux Kernel. Some people also tried similar approaches to fix the XDP generic performance by reducing the package headroom constant but never got accepted. So I hope my different approach has more success.
What to expect throughput-wise
To get some impression about the performance potential of eBPF, I have created a little BPF program that forwards all incoming IPv4 network packages. To test the program, I used an AVM FRITZ!Box 7360 v2 running OpenWrt with Linux Kernel version 6.6.30, whose CPU limits the throughput performance of its Gigabit ports. Then I grabbed a PC with two network ports, connected both ports with one port of the FritzBox respectively, and created two network namespaces at the PC to force the network traffic through the FritzBox. I used iperf3 to generate TCP traffic for 60 seconds for each tested setting respectively; you can find the results inside the following plot:
xdp256: The eBPF IPv4 forwarding program attached to the XDP generic hook with the default package headroom of 256 Bytes
xdp32: The eBPF IPv4 forwarding program attached to the XDP generic hook with a custom package headroom set to 32 Bytes allowed by my patch
tc: The eBPF IPv4 forwarding program attached to the TC hook
Unfortunately, I couldn’t test XDP native yet because I don’t have any hardware around whose driver supports XDP.
As you can see and as I already mentioned, there is no performance gain from the XDP generic mode with the default 256 Bytes packet headroom due to the SKB re-allocation. Contrary to the patched XDP generic and TC, the network throughput about doubled compared to OpenWrt’s Firewall without any offloading.
Compared to Netfilter’s offloading implementations, there is also a performance gain, but admittedly only a small one. When we look at the Linux kernel source code here, this becomes plausible because the TC hook is located right before the Netfilter ingress hook. The XDP generic hook comes earlier than those two, even before taps (e.g., where tcpdump could listen).
So what’s next?
These are the upcoming milestones for the project:
Creation of a user-space program for loading and communicating with the eBPF program
Extending the user-space program with a firewall NAT/rule parser
Extending the eBPF program to apply the parsed firewall configuration on incoming packages
Evaluating the forwarding and dropping performance of the implementation
You can find the current eBPF IPv4 package forwarder, the XDP generic headroom patch, and the measurement and plotting script in my GitHub repository here: https://github.com/tk154/GSoC2024_eBPF-Firewall.
I will also upload the source code of the firewall there, which I am excited to implement in the upcoming weeks. I think the first small forwarding performance test already shows the potential of eBPF as a new offloading variant, and I haven’t even tested XDP native yet.
If you have any questions, don’t hesitate to ask them, and thank you for reading my first post.
Hi everyone! I’m Nemael. I’m a Software Developer with a few years of experience. I recently moved to Toronto, where I’m looking for a Software Development job.
During this summer, I will be participating in the Google Summer of Code 2024, where I will be working on Cable Purpose Autodetection software for LibreMesh. For this project, I will create special configurations that routers can automatically deploy if they detect specific recognizable scenarios.
This first blog post is meant to provide details to understand the project and its implementation.
LibreMesh?
LibreMesh is a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes. As it support most OpenWrt supported devices, following the documentation you can build the firmware and configure the routers to start using them as part of a mesh network. Many communities around the world already use LibreMesh and mesh networks as their network of choice.
There is also a list of available community-specific configurations on LibreMesh’s git. These configurations contain information about how to configure your router (and your network) to join the community mesh network.
Motivations
In some scenarios, routers running LibreMesh benefit greatly from having specific configurations applied, which are not yet natively integrated — As of now, an expert needs to step in and setup these configurations manually, which is not always an option for communities.
For this project, I will take a look at scenarios that would benefit from automatically applied configurations. I will focus on Ethernet ports and WAN networks. As some of these scenario can be recognized automatically at runtime, the idea is to prepare configurations ahead of time, and apply them (either automatically or after pressing a hypothetical “configure router” button) if one of these scenario is recognized. Here are a few scenarios that I will be working on:
A router is connected to the internet (Most routers use the WAN port for this).
A LibreMesh running router is connected to another router of the same network using the Ethernet port, to extend coverage.
A router is connected to a dummy wifi device using Ethernet for a point-to-point link. This occurs, for example, when a router with its original firmware is employed for wifi links, connected to another router running LibreMesh, which manages the routing. This scenario is very uncommon, so it might not be useful to auto-detect such scenarios.
A cabled client is connected via Ethernet to a LibreMesh running router.
More scenarios might come up, and some might be deemed not occurring often enough to warrant an auto-configuration.
Methodology
I will first work in a virtualized setting, using documentation from the VIRTUALIZING.md file available on LibreMesh’s git. Once the project has progressed far enough to warrant testing on actual hardware, I will either buy a few routers, or will work with Toronto’s Hackerspace to setup LibreMesh’s software on some of their routers.
I forked LibreMesh’s project to work on my own side, and once it is ready and mergeable, I will make a PR which will be ~hopefully~ integrated into LibreMesh’s codebase.
Concluding thoughts
As I am not very much experienced in network management, I took a lot of time before the coding period started to read up on LibreMesh’s documentation, setup a development environment, and to discuss with my mentors about what the project will look like. I am not quite yet finished with that, but things are moving forward quickly! I am very excited for the advancement of this project and how it would fit within LibreMesh 😀
Thank you Ilario for your help writing details in this post, and for your information about the scenarios where it would be useful to have auto configuration.
The project aims to create a qaul Ble(Bluetooth low energy) module in Rust for Linux which is compatible with Ble modules for Android and iOS. The module should provide the following functionalities :
BLE discovery and connections: The project should be able to scan other discoverable devices and send BLE advertisements to nearby nodes at regular intervals.
Establish data communication: The connection should be able to exchange messages between qaul nodes.
Plan Of Action
This project aims to establish a BLE connection between Linux and other compatible devices.
BLE GATT Service âž–
GATT Server: A GATT server corresponds to an ATT server. It receives requests from clients and sends responses back.
GATT Client: A GATT client corresponds to an ATT client. It sends requests to the server and receives responses. After the discovery of the server’s service attributes, it can start reading/writing about attributes found on the server based on permissions provided by the server.
GATT data hierarchy.
Implementationâž–
Initiate BLE GATT server :
Initialize the Bluetooth session and activate the Bluetooth adapter.
Initiate local Ble GATT server using the bluer crate and set up Bluetooth GATT Services and Characteristics, which become available for remote servers.
Initiate BLE GATT client :
Initiate advertisement to look for nearby qaul nodes with specified service UUID and characteristic UUID.
Connect to discovered devices and send RPC messages to libqaul.
Establish communication between devices :
On receiving the message.DirectSend request from the libqaul. Write the data into the characteristic.value if the service.UUID() and characteristic.UUID() is compatible with other qaul devices.
Create a message listener and forward the characteristic value passed in the event to libqaul to be serialized as protobufs and displayed to the user.
Deliverables :
Creating a stable working ble_module for Linux including fixing, and testing the current prototype.
Establish communication of the ble_module with libqaul.
Make sure the Linux Bluetooth code is interoperable with Android and iOS Bluetooth modules.
Try to optimize the Bluetooth module for better stability and connection.
ConcludingThoughts:
I have always been inspired by the idea of a world built on free and decentralized architecture. When I read the project’s description, I felt motivated to join a community dedicated to achieving borderless, decentralized communication that rivals established centralized applications.
I would like to thank my mentors, Mathias Jud and Brenodt, for guiding me through the project and helping me understand the internal workings of the applications. I am eager to contribute to the project with great enthusiasm.
We are thrilled to announce that freifunk.net has been accepted to participate in the Google Summer of Code 2024! This year, we’re again not just going solo; we’re in great company alongside qaul.net,Libremesh, Retroshare, and OpenWRT. Together, we are set to push the boundaries of open-source technology with a series of exciting projects.
How Does Google Summer of Code work?
Google Summer of Code is an international program that invites students and contributors to engage in open source software development. Each project has a predetermined size, with contributors dedicating between 95 and 350 hours to complete their tasks. The duration of the projects can vary, ranging from 8 to 22 weeks, though the typical period is set at 12 weeks. This structured timeline ensures that contributors have ample time to design, develop, and refine their software, while also fostering mentorship and growth within the open source community.
Our Diverse Project Lineup
This year’s lineup features innovative projects proposed by a talented group of contributors. These projects aim to enhance community networks and develop advanced tools for networks and applications. Here’s a quick introduction to the contributors and their projects:
Each contributor brings unique ideas and expertise, driving forward our mission to foster a vibrant community of open-source enthusiasts.
Follow Our Journey
These projects showcase our commitment to promoting open-source values and enhancing the functionality of community networks worldwide. We invite you to follow our progress as these projects unfold over the summer. Detailed descriptions of each project will be provided soon, allowing you to explore the innovative work our contributors are planning. If you are curious about what we have achieved in the past, these blog posts will give you a glimpse into our previous successes.
Stay tuned for updates, and join us in supporting these innovative endeavors in what promises to be a groundbreaking summer of coding!
Hello, everyone! In this concluding blog post, I’m excited to highlight the achievements in the field of Joint Power and Rate Control in User Space, and also offer insights into the future of this research and development endeavor. If this is your first encounter with my work, I strongly encourage you to explore the introductory blog posts from GSoC ’22 and GSoC ’23, as they provide a comprehensive overview of resource allocation in IEEE 802.11 networks.
After the first-half of the GSoC ’23 coding timeline, I did some more modifications to the passive user space Minstrel-HT such that it is more robust and also compatible with the new WPCA API. In my mid-term report, I conducted passive measurements on a link between a BananaPi with an MT7615 chip as the Access Point (AP) and a Xiaomi Redmi 4A Gigabit Edition with MT7621 as the Station (STA). However, it’s worth noting that this setup did not support aggregation in the transmission frames.
Since the kernel Minstrel-HT also consider real-time Aggregate MAC Protocol Data Unit (AMPDU) length to calculate the estimated throughput, it was crucial to test to test the behaviour of the user space Minstrel-HT (Py-Minstrel-HT) with its kernel counterpart in an aggregation context. To do this, the experiment setup was changed to involve two identical TP-Link WDR4900 routers, both equipped with ATH9K chips. One router operated as an Access Point (AP), and the other served as a Station (STA)
Initially, the rate selection between kernel Minstrel-HT and Py-Minstrel-HT for the pure ATH9k link with frame aggregation showed a significantly higher disparity compared to previous experiments on the MT76 link, where errors were consistently below 2%. Upon closer examination, it became evident that during the refactoring of Python-WiFi-Manager and Py-Minstrel-HT, there had been a change in how AMPDU length was calculated, resulting in an incorrect calculation.
Furthermore, upon observing a consistently higher error rate associated with the maximum probability rate annotated at the end of the Multi-Rate Retry chain (MRR), I discovered a peculiarity in the kernel Minstrel-HT code. Specifically, when encountering initial attempt statistics for a rate that wasn’t used, the code assigned a previous average success probability of 0. This behavior occurred exclusively in situations where data rates had inherited their success probabilities from higher rates within the same group. It remains uncertain whether this aspect of the code logic was intentional or not.
To enhance the robustness of the measurements, I made adjustments to the execution of Passive Py-Minstrel-HT. Now, before factoring in transmission data, it follows a new sequence. Initially, it explicitly sets the lowest supported data rate, then resets the kernel rate statistics, and subsequently waits until the effect of the kernel rate statistics becomes evident in the API output trace. This revised approach ensures strict alignment between the transmission statistics in user space and those in kernel space right from the outset. As a result of these modifications, the rate selection between the kernel and user space Minstrel-HT is now identical.
In the following section, I present two comparison experiments conducted between kernel Minstrel-HT and Py-Minstrel-HT. The results are presented in terms of the number of errors, discrepancies in rate selection between the kernel and user space Minstrel-HT, and the percentage of errors observed at each Multi-Rate Retry (MRR) stage. These MRR stages, numbered from 0 to 3, are populated with rates ranked in descending order of their estimated throughput, with the final MRR stage reserved for the maximum probability rate to enhance robustness.
Given the congruent behavior observed between the user space and kernel space Minstrel-HT in terms of statistics collection and rate selection, this sets a robust foundation for expanding the capabilities of the user space Minstrel-HT with power control. This extension will allow for a performance comparison between the user space Minstrel-HT and kernel Minstrel-HT, offering valuable insights into their respective impacts.
Extending Minstrel-HT with Power Control (Joint Controller)
In this section, I will detail the implemented joint power and rate controller, which draws its inspiration from Minstrel-Blues, a framework originally developed by Prof. Thomas Hühn in 2011. The joint controller has demonstrated its effectiveness by notably reducing interference and enhancing spatial reuse, particularly in scenarios involving multiple access points that utilize the joint controller. The subsequent sub-sections will present the algorithm in a format mirroring the structure of the proposed joint controller, facilitating a straightforward comparison between the two.
Configurable Parameters
The parameters listed in the table are the precise variable names used when specifying the rate control options (rc_opts) to Py-Minstrel-HT via WiFi-Manager.
Initialisation
During initialisation, the lowest supported rates are set using the reference power, unless Py-Minstrel-HT is executed with fixed power mode. Given that the implementation already incorporates a reference power, the ceiling mode has been eliminated from the extended controller.
Updating Rate Statistics
During each update interval, the extended Minstrel-HT algorithm updates the statistics for all the rates and power levels currently in use. Moreover, it also updates the success probability for unused rates at each power level, provided that the rate group contains at least one higher rate with attempt statistics from the same group and the same power level.
Following the statistics update, the selection of the reference power and sample power for all rates is adjusted based on their success probability and the constraints specified in the rc_opts parameters. If the success probability of the sample power is within the the inc_prob_tol of the reference power, the sample power is decrease by pwr_dec. On the other hand, if the success probability of the sample power is lower the the dec_prob_tol of the reference power, the sample power is increased by pwr_inc to increase throughput. The reference power is also updated in the same way but the tolerance being based on 100% (1.0) success probability.
For example, if the successful probability of the reference power is 0.95, the dec_prob_tol is 0.1 and the pwr_dec is 1, then the reference power will decrease by 1 dB because the probability of the reference power is greater than (1.0 – 0.1)=0.9. Finally, the best power level for all the rates is set to sample_power + opt_pwr_offset.
Rate and Power Sampling
The rate sampling process remains unchanged, as it continues to be carried out by the Minstrel-HT algorithm just as it was before the extension. However, there is a modification in that the power annotation for the sampled rates is now set to the reference power. Furthermore, the algorithm has been expanded to include power sampling, which cycles through the Multi-Rate Retry (MRR) selection process in a cyclic manner.
Selecting Best Rates for the MRR chain
In order to select the best rates, the algorithm defines a linear utility function that exposes trade-off between throughput (benefit) and interferences to other transmissions (cost) of each rate.
The benefit function is defined based on its estimated throughput and the current maximal throughput.
The cost factor serves as a representation of the interference costs associated with achieving a specific throughput at a given power level. In essence, this interference cost depends on two key factors: the extent of interference coverage and the duration of the interference event. However, due to the inherent complexity of modeling such effects, the following definition opts for a simplified approach, approximating the interference area solely based on power(ratei). Similarly, the duration of interference is approximated as 1 divided by the throughput (1/throughput(ratei)).
Using the utility function, the extended joint controller selects the best rates which have the highest utility, contrary to the Minstrel-HT algorithm which only considers the estimated throughput.
Analysing Performance of the Joint Controller
In this section, I will demonstrate the performance of the joint controller in comparison to the kernel Minstrel-HT and the Py-Minstrel-HT without power control extension.
Experiment Description
The experiments consisted of two variations based on the measurement tool:
Iperf3 and tcpdump
The traffic for the measurement was generated using iperf3, with the server hosted on the STA and the client on the AP. Consequently, the traffic flow traversed from the AP to the STA, aligning with the experiment’s objective of running resource controllers on the AP. Furthermore, the network traffic was monitored using tcpdump with a snapshot length of 150 bytes per packet to limit the amount of payload data captured. This data was then stored in a pcap file, which we subsequently parsed to extract the achieved throughput values.
The experiment setup involved two TP-Link WDR4900 routers, both featuring ATH9K chips. One router operated as an Access Point (AP), while the other functioned as a Station (STA).
Flent
Flent is a tool that serves as a wrapper around netperf and similar utilities to execute predefined tests, aggregate the outcomes, and generate plots. It also retains the raw data, providing users the opportunity to analyze and visualize the data, alongside the automated plots. The measurement traffic was generated using flent, with the server hosted on the AP and the client on the STA. However, the traffic direction was inverted using the “–swap-up-down” option. Notably, Flent can measure packet latency, a capability unavailable with iperf3.
The experiment setup involved a TP-Link WDR4900 router as an Access Point (AP) with a Macbook Pro 13′ 2017 as the Station (STA).
Results
The results have revealed a rather surprising trend: the joint controller consistently delivers improved throughput, even in single-link experiments. When compared to the kernel Minstrel-HT and Py-Minstrel-HT without the power control extension, the joint controller demonstrates a noteworthy throughput gain in UDP experiments, consistently falling within the range of 10-25%. These results highlight the joint controller’s capability to improve aggregation and dynamically select power levels.
Additionally, the results showcase various runs of the joint controller, each with a utility weight factor set to 1, 10, and 100. It is worth noting that the experiment using Flent utilised TCP traffic.
The analysis of the joint controller shows immense promise, and I’m excited about the prospect of continuing to run and test it with multiple interfering routers even beyond the conclusion of GSoC ’23. Regrettably, newer WiFi chips are becoming increasingly closed-source, limiting access to information and functionality related to resource control for the general public. Unfortunately, these newer chips still support power control and provide real-time estimates of throughput. As a result, our plan is to develop an independent power controller after completing Minstrel-Blues in the user space.
I am happy to share the completion of the Google Summer of Code Program for 2023 and into this post, You will find about how you can use my project for interconnecting the Qaul and the Matrix chat applications.
I would recommend reading about the project via my previous blog posts.
You should have an account on matrix that can act as a bridge bot.
For more secure communications you can opt for running your own matrix homeserver but that is not necessary since our bridge works well on the default matrix server as well.
You should have the binary to the bridge either as code or distributed package.
We are still working on packaging the binary for end users and then in place of cargo run –bin qaul-matrix-bridge you can simply run our binary.
Initialization and Configuration
As of now, We are supporting the bridge only as a daemon process binary without any control on it via CLI or GUI. All the logics are integrated on matrix-sdk or ruma and qaul or libqaul.
On the server where you wish to start a binary between a local qaul network, You need to have one node running the binary and rest will follow along the way.
After installing the qaul project you can
cargo run --bin qaul-matrix-bridge {homeserver-url} {bot-matrix-id} {bot-account-password}
- homeserver-url : The URL for matrix homeserver. Default can be [https://matrix.org]
- bot-matrix-id : The user account of the bot on matrix. Eg : @qaul-bot:matrix.org then id is [qaul-bot]
- bot-account-password : The password for your bot account on matrix
Inviting the Bridge to Matrix Room
Once the bridge is running up. You have to go to your own matrix account and create a new room. Please make sure to turn off any encryption. Now invite the bot to your matrix room and it automatically joins the room.
1. Create a matrix room and disable end to end encryption
2. Invite the bot account into the room
Navigating through Matrix Menu
We have multiple menu options available in our Matrix Menu. You can see the list of all the possible functionalities with !help command.
!help
!qaul
!users
Here the users are displayed over a local peer network in qaul. Qaul Matrix Bridge Bot is the default bridge user unless opted for other users. Along with their name the random strings which you can see are the PeerID of a user on qaul-network.
!invite
!group-info
!remove
Not just messages 🎉 but exchange files too
Closing Notes
I am glad to share the prototype of the bridge. It was a great experience learning from different matrix specifications and their protocol design. In future, We are looking forward to incorporate Qaul Menu, distribute the binaries over various mediums, Styling the bot responses via emotes and lot more.
A special thanks to my mentor MathJud who have helped with serious problems whenever we faced it and with him I have learned very important principles when designing a chat application. He also introduced me to Matrix Camp in Chaos Communication Camp where we presented the prototype (bit buggy at that time) to people who are working on Matrix protocol.
I would also encourage people to come and contribute to the Qaul project because this project serves an important use case to allow communication during Internet break-outs. Developing a solution to stay hidden from government will help sustain the openess of speech and freedom.
