In the first blog, some problems that users were running into when trying LibreMesh were mentioned. In short, they consisted of:
- When you wanted to shut down a node that had been run previously, you left an interface up on the host.
- When you wanted to start a node to change internet access, this was not possible since the port required by the qemu_dev_start script was always occupied by the systemd_resolved process.
- When the node cloud was brought up, it had called ifconfig, and since this functionality is not installed in versions later than Ubuntu 18.04, the user could not run the node cloud.
To solve these problems, the strategy that was chosen was to modify the files already created, also creating detailed documentation to facilitate virtualization for anyone who wanted to try LibreMesh.
Milestones accoplished
1. Improvement of the environment:
All the problems mentioned meant obstacles when testing LibreMesh, thus causing users to decline in the knowledge of the tools that LibreMesh proposes. So, identifying and correcting them would offer any user a cleaner testing environment, free from any obstacles that depend on the LibreMesh code.
1.1 Close interface on the host
The solution to this was to modify the qemu_dev_stop script. The interface that was raised is called lime_br0, so the line was placed inside this file:
lime_br0 ip link
In this way, the interface on the host will stop the execution of the node.
1. 2. Collision in port
In this case, the solution was to change the port occupied by the DHCP service for the wan interface:
dnsmasq -F 172.99.0.100,172.99.0.100 –dhcp-option=3,172.99.0.1 -i “$WAN_IFC” –dhcp- authorized –log-dhcp –port=5353 –bind-dynamic
1. 3. Calls to ifconfig
In this case, the files that were modified were two:
– linux_bridge.py
– linux_bridge_port.py
which are located inside the lime-packages/tools/ansible/modules directory.
Where there were ifconfig calls, ip was used.
In linux_bridge.py the changes were the following:
– def brctl (self, cmd) :
– return self.module.run_command ([‘brctl’] + cmd)
– def ifconfig (self, cmd) :
– return self.module.run_command ([‘ifconfig’] + cmd)
+ def ip(self, cmd) :
+ return self.module.run_command ([‘ip’] + cmd)
– (rc, out, err) = self.brctl ([‘addbr’, self.bridge])
+ (rc, out, err) = self.ip ([‘link’, ‘add’, ‘name’, self.bridge, ‘type’, ‘bridge’])
– self.ifconfig ([self.bridge, ‘up’])
+ self.ip([‘link’,’set’,’up’, self.bridge])
– self.ifconfig ([self.bridge, ‘down’])
– (rc, out, err) = self.brctl ([‘delbr’, self.bridge])
+ self.ip([‘link’,’set’, ‘down’, self.bridge])
+ (rc, out, err) = self.ip ([‘link’, ‘del’, self.bridge])
In linux_bridge_port.py the changes were:
– def brctl (self, cmd) :
– return self.module.run_command ([‘brctl’] + cmd)
+ def ip(self, cmd) :
+ return self.module.run_command ([‘ip’] + cmd)
– (rc, out, err) = self.brctl ([‘addif’, self.bridge, self.port])
+ (rc, out, err) = self.ip ([‘link’, ‘set’, self.port,’master’,self.bridge])
– (rc, out, err) = self.brctl ([‘delif’, self.bridge, self.port])
+ (rc, out, err) = self.ip ([‘link’, ‘del’, self.port,’dev’,self.bridge])
qemu_cloud_start.yml was also modified:
+ enable_wan_param: “{{ (‘–enable-wan ‘ + enable_wan ) if enable_wan is defined else ” }}”
– shell: (../qemu_dev_start –node-id {{ node_id }} –eth0 {{ lm_ifname }}_0 –eth2 {{ lm_ifname }}_2 {{ rootfs }} {{ ramfs }} &)
+ shell: (../qemu_dev_start –node-id {{ node_id }} –eth0 {{ lm_ifname }}_0 –eth2 {{ lm_ifname }}_2 {{ enable_wan_param }} {{ rootfs }} {{ ramfs }} &)
– linklocal: “fe80::5000:ff:feab:c0{{ node_id }}%lm_cloud{{cloud}}”
+ linklocals: “{{ linklocals | default([]) | union([ hostvars[item].linklocal | default() ]) }}”
Conclusion:
The solutions that were given to the different problems and everything documented to be able to use LibreMesh greatly contribute to anyone who doesn’t even know what LibreMesh is and who wants to try it for the first time.
When a person is not knowledgeable about something and there are multiple problems they run into, and no help to clarify the picture, that person is more likely to stop spending effort on domain knowledge and look for other similar options, which you can understand and access more easily.
That is why the fact of not encountering the problems raised and of having documentation that guides this testing process means that users do not decline so easily and want to use mesh networks, which were the objectives pursued from the beginning.
The development of this whole project was very challenging for me. From the use of tools that I did not know like ansible-playbook, network management with which I was not so familiar, the use of virtual machines, the familiarization with the LibreMesh community to the management of a project itself, there were many things that I learned and what I take away from this project.
I am enormously grateful to my mentor Germán Ferrero, a great person, who has been able to guide me along the way I have traveled, always encouraging me to move forward and being there to answer any questions.
I also thank my advisor Tomas Assenza, other great person, who encouraged me to carry out this project from the beginning and who was faithfully present throughout its duration.
I am very happy about everything I learned in this beautiful experience.
Thank you very much for reading and following this tour!