Hello everyone! This summer as part of GSOC 2025 I’ve worked on Adding Wi-Fi Support to QEMU Simulations in Libremesh. This project consisted in “bridging” virtual machine running LibreMesh firmware using their Wi-Fi interfaces inside QEMU, in order for it to become part of the development loop of the LibreMesh.
This is my final write up for this project, and a conclusion of an enriching journey. You can also explore my first and second blogposts for Freifunk.
This project led me to learn a lot about virtualization, OpenWrt, and open source in general !
Simulating Wi-Fi within a Virtual Machine
Testing wireless communications is a tricky problem for many reasons : the medium through which the messages are being sent around being literally made out of thin air, observability is subpar and repeatability is complicated, involving hardware heavy setup.
Thankfully, mac80211_hwsim solves (most) of the issues for us. In simple terms, this module simulates Wi-Fi hardware inside the Linux Kernel, and allows us full control of it – as many Wi-Fi radios as one would want within a single machine and with complete control over it, with each of the radios able to talk to the other radios created by this module.
kmod-mac80211-hwsim
OpenWrt being based on the Linux Kernel, we should have access to this module.Even better : it’s a package ! That’s good news since now integrating this solution to our future testing will require minimal intervention : it’s a simple package to add to our build configuration.
LibreMesh virtual Wi-Fi capable firmware
So following LibreMesh instructions for building our own firmware, and by simply adding kmod-mac80211-hwsim to our configuration, we end up with exactly what we are looking for : a virtual Wi-Fi capable LibreMesh firmware.
Unfortunately, mac80211_hwsim limitless possibilities bring us some issues : LibreMesh firmware have never been tested against 6G capable router, and ends up wrongly configuring the virtual radios, preventing us from obversing the expected behaviors. This led me to dig about Wi-Fi bands and their specifications, especially 802.11ax which brings a whole set of restrictions (and confusions) especially in the upper range of the spectrum.
All in all this was beneficial to the project since I was able to provide a patch to fix the unexpected behaviors, which in the end should speed up the (future) integration of LibreMesh to 6G capable routers.
Once the fix provided, LibreMesh firmware was working as expected when run inside a QEMU virtual machine – I was able to replicate the classic AP-STA set up within the virtual machine, as is usually showcased when demonstrating the capabilities of mac80211_hwsim.
Connecting multiple virtual machines through Wi-Fi interfaces
Now that we were able to have a working virtual machine with Wi-Fi capabilities, the goal was to have multiple of these virtual machines, and to connect them to each other through their Wi-Fi interfaces, create a “virtual mesh”.
Connecting multiple QEMU virtual machines through their virtual ethernet interfaces have been a solved issue since many years (even though there is still active development in that area) due to the critical nature of the problem for the big cloud services provider, connecting multiple virtual machines through their Wi-Fi interfaces have mostly remained an afterthought, an academic project at most.
vwifi
vwifi is a project enabling simulation of Wi-Fi across multiple Linux QEMU virtual machines, relying on the mac80211_hwsim driver and finally, with specific support for OpenWrt
It basically relays Wi-Fi frames across the virtual machines : a server is running on the Host machine and each vms are connected to it. Inside each virtual machine, each radios are managed by the vwifi-client : each frame is passed to the server. A schematic is provided for easier understanding of the setup.
Compilation of this project for OpenWrt is a bit finicky, but manageable. A package for easier integration with OpenWrt is under development by my mentor Javier Jorge.
Virtual Mesh in LibreMesh !
Now that we have a way to create Wi-Fi frames inside a virtual machine and have it relayed to an other machine, let’s piece everything together and create our LibreMesh mesh !
Meaning that new development of features for LibreMesh such as the shared-states packages relying on heavy and cumbersome infrastructure to test and iterate will be possible by simply cloning this set of scripts inside your OpenWrt build directory, and simply running them will provide a lightweight, reliable and quick to set up testbed.
Automation of testing in LibreMesh
Last piece of this puzzle is the automation of the testing in LibreMesh.
So far, testing in LibreMesh was provided by unit testing using a docker image and mockups of the expected behavior, and manual testing using real hardware. QEMU only occured during development and wasn’t fully integrated in the development process, since it was easier and more reliable to just upload the firmware to an adjacent router and observe the behavior. But now that we proved that it was possible to set up true and reliable Wi-Fi mesh network, the next obvious step is to provide automated testing and completely integrate it in the LibreMesh development loop.
OpenWrt-test
OpenWrt-test is a labgrid test based framework aiming at providing worldwide testing for OpenWrt across multiple devices. I’ve had the opportunity to meet up with the main developer of this project apacar during BattleMeshv17 and with my mentor and the LibreMesh community we decided to based our future QEMU based testing on this framework, since it is tightly integrated with OpenWrt and also based on the convenience when wanting to run the tests across different devices.
To use it, OpenWrt-test have to be cloned inside the OpenWrt build directory, and then a Makefile will handle the rest of the setup.
make tests/qemu-x86-64 V=s will allow you to run the different tests (specific to OpenWrt) located inside the tests/ directory of the project.
The project have been forked in order to provide specific test to LibreMesh : despite being based on OpenWrt, LibreMesh still show some specific differences. And finally, after a lot of struggle, I was finally able to integrate LibreMesh inside this framework with the rest of my work.
The setup consists in :
starting the virtual LibreMesh mesh and setting up each of the VM,
Running the labgrid test
Labgrid will then spin up its own virtual machine based on the latest build present in bin/target/x86/64 and then be able to connect to the virtual Wi-Fi mesh, and run automated test against the infrastructure. This allows to run repeatable tests in a controlled manner, orchestrate 4 different machines and quickly iterate when developing new feature requiring some specific Wi-Fi setup.
Future Work
This project managed to showcase the repeatability and convenience of Labgrid for automated tested, which coupled with the ability to create virtual Wi-Fi meshes brings a whole new worlds of possibilities for LibreMesh development, as well as any Wi-Fi mesh features : lightweight infrastructure, quick setup and fully repeatable.
Future work will concentrate on bringing better coverage for LibreMesh testing using the new tools that are now proven to be effective from this GSOC project. So far testing covers part of the shared-state packages, but different packages could be targeted, and not only the ones relying on a Wi-Fi mesh network but also general configurations.
Lastly, vwifi document way to introduce packet loss as well as nodes mobility : this could allow for different scenario of testing and bring a whole new set of robutness to the LibreMesh project.
Conclusion
This Google Summer of Code provided me the opportunity to discover many new things : I broaden my understanding of Wi-Fi and even discovered new use cases for it, tinkered with it in the Linux Kernel, learned about OpenWrt and LibreMesh and more importantly met with incredible and very passionate people.
I’m very thankful to have been able to work on such a project during this summer, and would like to thank very fondly my mentor Javier Jorge for his support throughout this adventure.
Thank you also to Freifunk for allowing this to happen, it’s really a fantastic opportunity for everyone involved.
I will definitely continue to contribute to LibreMesh and OpenWrt and hope to meet with you in person at BattleMeshv18!
Userspace programs fires a command that interacts with wifi : programs such as `iw`, `hostapd`, `wpa_supplicant` etc.
Command is passed to the kernel through _nl80211_ over the netlink protocol, in openwrt it is usually handled by [tiny-libnl](https://git.openwrt.org/?p=project/libnl-tiny.git)
_cfg80211_ is here to bridge the userpace and the drivers so that with nl80211 they provide a consistent API, it’s also here that parts of the regulatory spectrum use is enforced depending on country specific legislation.
_mac80211_ then provides a software implementation of wifi behaviors such as queuing, frame reordering, aggregation, mesh support etc.
The driver (ath9k or *mac80211_hwsim*) then handles hardware specificities
Why is this important for our project
This layered approach is essential to our project, as it will enable us to create virtual tests beds that should be almost transparent to a real world experiment.
By just simulating the last brick – mac80211_hwsim – we’ll be able to recreate the whole wifi stack. We will still see the same exact path consisting of : userspace configuration -> nl80211 -> cfg80211 -> mac80211
Which means that without the need for expensive and complicated set up, we achieve the same possible tests for configuring the different interfaces, and in our case with the added reproducibility : setting up the infrastructure will only require a computer able to launch qemu-system, and if we decide to reproduce it with real hardware, we should observe an almost 1:1 reproducibility of the tests.
Virtualizing wifi : many tools, troubling setup
So we now that we have a clearer understanding on how wifi is handled in the Linux Kernel, and the existence of a tool to simulate wifi hardware, let’s see what is possible to do with it !
mac80211_hwsim in LibreMesh ?
Since LibreMesh is built on OpenWRT, our first task will be to bring mac80211_hwsim to OpenWRT.
Thankfully, this tool is known and already used by the OpenWRT community, and it is delightfully provided as a package that you can install in your system through opkg : opkg install kmod-mac80211-hwsim Which means, no need for custom kernel setup and compilation – and that’s good news.
Installation methods :
If your machine has an AMD/Intel CPU, simply go get the combined (squashfs) of the Generic x86/64 through the firmware selector.
unzip the image : gunzip openwrt-*-x86-64-generic-squashfs-combined.img.gz
You should then end up with something like that :
openwrt-24.10.2-x86-64-generic-squashfs-combined.img Simply put, this is a kernel+root file system (that’s what combined means), using a compressed read only filesytem (squashfs).
Now we need to instantiate our virtual machine, using qemu it can be done like this :
Just wait a bit for the boot to finish, you should see a Please press Enter to activate this console.
Inside the vm you’ll then have to run : uci set network.lan.proto='dhcp'
uci commit network
service network restart
Inside the vm you’ll then have to run : uci set network.lan.proto='dhcp' uci commit network service network restart
This convert the LAN to a DHCP client and allow the VM to grab the 10.0.2.x lease from QEMU, Which will then enable you to run : opkg update
and finally : opkg install kmod-mac80211-hwsim
By default, mac80211_module is loaded with 2 radios, but the behavior can be changed with this command : insmod mac80211_hwsim radios=X` with X the number of radios you want to have in your VM.
Let’s also not forget to include the right packages since we want to test wifi : Since we’re not constrained by flash space on our laptop/computer, we’ll use wpad : opkg install wpad
Congratulation, you now have an OpenWRT based virtual machine with a working virtual wifi ! Actually, not so fast…
One of the classical example when searching for the documentation regarding mac80211_hwsim module is the access point/station association using two different virtual radios (on the same host). 12 So let’s be original, and recreate this example (but in this case in OpenWRT !).
Virtual AP/Station association in a OpenWRT virtual machine :
When we install mac80211_hwsim/boot the VM, it should auto load the module with 2 radios. You can check the presence of the 2 radios with this command :
As for the wifi devices, so far, nothing : iw dev won’t return anything at this point. We now need to configure these two (virtual) physical radios in order to have : an AP and a station. Let’s check the default configuration of the wireless in our image :
As we can see, both of our wifi-device are disabled, and also both in ap mode. So the easy way out of this would be to do : uci set wireless.radio0.disabled=0
uci set wireless.radio1.disabled=1
uci set wireless.radio1.mode=sta
uci commit
wifi reload
With all that we should be set ? No ? Still nothing. This was a real mystery for me, but after some digging, it appears that when using the 6g band, wpa3 is mandatory. This is defined by the IEEE 802.11ax standard, and in our case the wifi 6E extension. Since encryption testing isn’t on the scope of this project so far, let’s be conservative and try some true and tested wifi bands (2g) and see what happens.
In the end your /etc/config/wireless should look something like that :
config wifi-device ‘radio0’ option type ‘mac80211’ option phy ‘phy0’ option band ‘2g’ option channel ‘1’
With this configuration you still need to wifi reload or reboot if you don’t see any changes happening. We finally have our prized AP/station association :
daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->ENABLED daemon.notice hostapd: phy0-ap0: AP-ENABLED daemon.notice wpa_supplicant[1825]: phy1-sta0: SME: Trying to authenticate with 02:00:00:00:00:00 (SSID=’OpenWrt’ freq=2412 MHz) daemon.info hostapd: phy0-ap0: STA 02:00:00:00:01:00 IEEE 802.11: authenticated daemon.notice wpa_supplicant[1825]: phy1-sta0: Trying to associate with 02:00:00:00:00:00 (SSID=’OpenWrt’ freq=2412 MHz) daemon.info hostapd: phy0-ap0: STA 02:00:00:00:01:00 IEEE 802.11: associated (aid 1) daemon.notice hostapd: phy0-ap0: AP-STA-CONNECTED 02:00:00:00:01:00 auth_alg=open daemon.info hostapd: phy0-ap0: STA 02:00:00:00:01:00 RADIUS: starting accounting session 2E622F6D18713536 daemon.notice wpa_supplicant[1825]: phy1-sta0: Associated with 02:00:00:00:00:00 daemon.notice wpa_supplicant[1825]: phy1-sta0: CTRL-EVENT-CONNECTED – Connection to 02:00:00:00:00:00 completed [id=1 id_str=] daemon.notice wpa_supplicant[1825]: phy1-sta0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Let’s check what iw is reporting :
iw dev phy#1 Interface phy1-sta0 ifindex 7 wdev 0x100000002 addr 02:00:00:00:01:00 type managed channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz txpower 20.00 dBm multicast TXQ: qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets 0 0 0 0 0 0 0 0 0 phy#0 Interface phy0-ap0 ifindex 8 wdev 0x2 addr 02:00:00:00:00:00 ssid OpenWrt type AP channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz txpower 20.00 dBm multicast TXQ: qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets 0 0 11 0 0 0 0 1358 11 And finally : iw dev phy0-ap0 station dump Station 02:00:00:00:01:00 (on phy0-ap0) inactive time: 4950 ms rx bytes: 2077 rx packets: 50 tx bytes: 131 tx packets: 2 tx retries: 0 tx failed: 0 rx drop misc: 0 signal: -30 dBm signal avg: -30 dBm tx duration: 0 us rx bitrate: 54.0 MBit/s rx duration: 0 us authorized: yes authenticated: yes associated: yes preamble: short WMM/WME: yes MFP: no TDLS peer: no DTIM period: 2 beacon interval:100 short preamble: yes short slot time:yes connected time: 1232 seconds associated at [boottime]: 59.854s associated at: 1752513660712 ms current time: 1752514892128 ms
All in all, lots of troubleshooting, qemu-system network was a bit novel for me and I spent a lot of time on it figuring it out why some things worked on others didn’t. Also having mac80211_hwsim fully working in a OpenWRT qemu vm was definitely not easy at first : some documentation for the setting it up in a regular Linux environment, but didn’t find much regarding OpenWRT ?
Enabling mac80211_hwsim in LibreMesh
Now that we have a proof of concept of virtual wifi working in OpenWRT, let’s port it to LibreMesh.
‘kmod-mac80211-hwsim wpad` to the firmware selector (getting opkg to work in a Libremesh vm is a bit tricky – doing like so is a lot easier)
request a build
then you’ll be able to recreate the steps from the last section to have AP and mesh radios (You should be able to see the mesh interfaces connect to each other if put on the same channels)
On a custom build
Now that we mostly have figured out mac80211_hwsim with a generic image, let’s enable it in a custom LibreMesh build.
By following these instructions you should be able to get mostly there.
using make menuconfig, you will need to select these targets :
Target System : x86 Subtarget : x86_64
Then it will simply selecting the specific libremesh packages, and lastly :
Save your config in .config, compile it make -j$(nproc) and then you’ll find your different images in bin/targets/x86/64.
Setting up mac80211_hwsim will require the same steps as the last two (setting the right band/channels/radio)
Conclusion of mac80211_hwsim in Libremesh
In the end mac80211_hwsim provides an excellent tool to test different wifi configuration, enabling it in a LibreMesh build is pretty straight forward, but as for OpenWRT stock image t requires a bit of manual work to set everything right.
My trials and errors for enabling mac80211_hwsim in Libremesh led me to discover some undefined behavior in LibreMesh when the firmware interacts with a wifi 6E able radios, which I will need to provide a patch for in order to continue my integration of qemu wifi testing to LibreMesh in the next half of my GSOC.
VM to VM communication using wifi
I’m proud to announce that I’ve finally managed to recreate the AP-STA scenario using two differents QEMU virtual machines ! OpenWRT <-> OpenWRT as well as LibreMesh <-> OpenWRT was possible. Once I’m able to fully control it and document it, I will provide a libremesh-profile with and easy setup.
This experiment relies on the vwifi project which comes in two part :
vwifi-server which will run on the host and is here to provide a medium for our wifi : in its default config, it will broadcast the wifi frames of the client connected to it to the other clients.
vwifi-client that will run on the guest : it basically relies on mac80211_hwsim to create real wifi frames, then relay them to the vwifi-server it is connected to. It also receives wifi frame from the others clients through the server, and manage to inject them in the VM wifi stack, so they get treated correctly and connection is possible.
Building the project is well documented in the README, and one advantages of this project is that it is OpenWRT compatible if we follow closely the instructions.
I struggled a lot a first, thinking I should cross compile it against my custom LibreMesh build, but it seems that as long as you get the right SDK you shouldn’t encounter any issues, aside from the usual qemu troubleshooting.It is also possible to build vwifi-client in order for it to work with vhost-vsock instead of TCP, but I so far didn’t manage to do that/didn’t test it right.
Caveats
run the vwifi-server like this : vwifi-server -u this will prevent overlapping in the mac address when relaying to the other clients, and save you some time figuring out what’s really happening.
When copying the vwifi-client file to the guest, use these options : scp -O -p <forwarded port> root@127.0.0.1 since otherwise it will try to rely on sftp, which might not be installed on the OpenWRT guest VM.
vwifi-client needs to connect to the host : use the IP from hostname -I. Inside the VM you need to run something like that : `vwifi-client -n –mac
If you don’t want to set it up as a service, remember that you need to remove the mac80211_hwsim module, then insert it again but with 0 radios : insmod mac80211_hwsim radios=0
In LibreMesh, the current default wireless config is broken, a patch is coming very soon that will allow a seamless integration with the testing, but so far lime-config will put each radios advertised by mac80211_hwsim in the 6g band channel 48 : this won’t work, you need to manually change it to have (modify the /etc/config/wireless)
I still need to provide a full guide and scripts on how to recreate the experiment, but with this picture you should see what it is expected to have :
You can see on the top the LibreMesh VM acting as the access point, with on the left the serial interface running vwifi-client and on the right an ssh connection to this VM used to manage it. At the bottom of the image it is the same setup but using a different VM, this time with a regular OpenWRT image, acting as the station. We can clearly see the station being connected to the AP from a the other VM.
Integration with LibreMesh testing ?
My initial tests and discoveries with virtualized wifi in a QEMU environment and the different tools that this kind of setup enables makes me more and more confident in the usefullness of adopting this approach for future development in LibreMesh and OpenWRT. From this 6 weeks coding period that were mostly troubleshooting and figuring why things don’t work I’ve managed to find an undefined behavior in the way LibreMesh sets itself up on newer hardware without the need to acquire the said hardware, it also seems that it’s not even been discovered yet by an user : fixing bugs before they even show up.
Now for integrating this kind of qemu testing, the LibreMesh community have decided to use the openwrt-tests framework, a framework based on labgrid aimed at providing ways to write and run tests for OpenWRT devices, being real hardware or virtual one (in our case).
I’ve already made some preliminary work for enabling LibreMesh to integrate with this framework. So far the framework provide satisfaction with my goals, the only real issues I’ve encountered were actually the divergence between OpenWRT and LibreMesh in some areas, meaning all the demos tests need some integration before being part of the testing pipeline.
Conclusion
I’ve mostly met my goal of having a working virtualized LibreMesh wifi mesh using a qemu infrastructure, I’m a bit behind regarding documentation as well as automation, but my plan is still well defined and I hope now mostly trouble free.
I now should be able in the coming weeks to :
Provide ample documentation for future work in this area
Leverage the new testing framework to provide reproducible and automated testing scenario, portable to real hardware
Fully integrate the project with LibreMesh testing pipeline, with documentation for extension
Port the current Docker based test to the new QEMU environment.
Bonus
I’ve had the pleasure to meet with the Freifunk/OpenWRT/LibreMesh community over the BattlemeshV17 organized in Sundhausen and I must say it was a very nice experience, learned a lot, flashed my first router with LibreMesh and more than everything felt very welcomed ! Thank you very much to the organizators and the participants, hope to see you again very soon.
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
