add P4 Switches/APs

[ramonfontes]

Mininet-WiFi should support classes for P4 Switches. This project (https://github.com/ANTLab-polimi/FOP4) seems to be a great kick-off. Since it works with Containernet we can also consider https://github.com/ramonfontes/containernet

[davidcawork]

Hi @ramonfontes 😄 ,

Right now I was trying to get something similar. My idea was to try to port the BMV2 to Mininet-Wifi. Only for my own requirements I needed to manage directly with the wifi headers (802.11). The "problem" I had is that in Mininet-Wifi, the interfaces that are created, are the physical emulated card (mn00sXX) from you can hang virtual interfaces, and those virtual interfaces which operate with ethernet.

These virtual interfaces that hang are generally of the Ethernet type, therefore in the reception of a wifi data packet, these are received by the physical emulated card, then the 802.11 to 802.3 headers are parsed and delivered to the virtual interface.

The only virtual interfaces that handle wifi headers are those in monitor mode. But the monitor mode is intended exclusively for listening, not for transmitting. But it is possible to do a packet injection, as long as those packets already have the wifi header built in, open a raw socket with the virtual interface in monitor mode and send it.

My idea was to try to make this integration between BMV2 and Mininet-Wifi, and give the softswitch the capacity to handle wireless headers. What do you think? How viable do you think it is?

Thank you very much for your time!

[ramonfontes]

Hi @davidcawork ;) ,

Are you doing something similar to the tutorials I've added in https://github.com/ramonfontes/tutorials/tree/master/exercises by any chance?

Could you clarify this -> the interfaces that are created, are the physical emulated card (mn00sXX) from you can hang virtual interfaces, and those virtual interfaces which operate with ethernet.

In my opinion and I can be wrong the only way to handle 802.11 headers is through the monitor interfaces. Most of the P4 tutorials use scapy and we can use it with the monitor interfaces in order to handle 802.11 headers.

The idea around BMV2 is very interesting. I was looking for a virtual switch (like ofsoftswitch) that allows us to run them in their own NS. Do you know if we can make BMV2 run in its NS? I just found p4lang/behavioral-model#672 and I was thinking to have a full control over adhoc scenarios. Unfortunately, we cannot do this if all the nodes are running in the root NS.

[davidcawork]

Hi @ramonfontes ☺️ !

First of all, feel free to correct me at any time, I still have a lot to learn and you probably went through this learning curve a long time ago! I'm going to go in parts to organize the answer and make it all more clear.

---

Let's go with the first part:

Are you doing something similar to the tutorials I've added in https://github.com/ramonfontes/tutorials/tree/master/exercises by any chance?

Yes! exactly, I usually always collect information and developments already made so as not to try to re-invent the wheel. Inspecting your code I saw that none of the p4 programs parse wifi headers, so I didn't know to what extent this was due to a limitation by Mininet-Wifi or a design decision.

Currently, my plan was to thoroughly analyze the interface that the P4Lang organization has set up between Mininet and P4 ( P4Switch, PI, P4Runtime..), analyze Mininet-Wifi and understand in depth its internal workings, and finally, try to integrate it in such a way that the BMV2 could handle the wifi headers (I planned to do this by using the interfaces in monitor mode).

So I decided to use the P4 tutorials that you created for the last step or make a new integration depending on the possible limitations that I found. Everything I've just explained here is explained in this repository, where I mention and reference everything you've created (Thanks a lot!). It's a pity since it's all written in Spanish and not in English, but it was mandatory for me since in my end of degree project all the documentation must be in my native language.

---

Let's go with the second part:

Could you clarify this -> the interfaces that are created, are the physical emulated card (mn00sXX) from you can hang virtual interfaces, and those virtual interfaces which operate with ethernet.

Yes, of course, I'm sorry for not explaining myself properly. As far as I could find out, Mininet-Wifi always ends up using the module mac80211_hwsim of the Kernel to create the wireless interfaces.

This is usually done by making use of the module itself by loading it with insmod - modprobe, or through the hwsim_mgmt tool. Besides, reading this thesis, he affirms that wmediumd also makes use of the mac80211_hwsim module ( I would like to learn better how wmediumd really works ☺️). In the wireless subsystem of Linux a difference is made between the physical layer, and the layer two (Access to the medium). For example:

$ hwsim_mgmt -c -n mn00s00

This would create an emulated wifi card, physical layer, with the name mn00s00, and also, it would create a virtual interface (vif) with the name wlan0, layer two, which would be associated to that emulated wifi card. The idea behind this is that you can have N virtual interfaces associated to the same emulated wifi card, what surprised me is that the virtual interfaces operate with Ethernet mostly ( leaving aside those in monitor mode).

If I don't explain myself correctly, I will try again!

---

Let's go with the third part:

In my opinion and I can be wrong the only way to handle 802.11 headers is through the monitor interfaces. Most of the P4 tutorials use scapy and we can use it with the monitor interfaces in order to handle 802.11 headers.

I completely agree! That would be the way to receive the packets with the 802.11 headers. To get the transmission going I thought I would do a packet injection into the interfaces in monitor mode. I do this by using scpay, where I form the Wifi + RadioTap headers, open a raw socket with the monitor interface and send it. Here I have a tool that I made just to check the operation of the packet injection. What do you think?

---

Let's go with the final part 😄

The idea around BMV2 is very interesting. I was looking for a virtual switch (like ofsoftswitch) that allows us to run them in their own NS. Do you know if we can make BMV2 run in its NS? I just found p4lang/behavioral-model#672 and I was thinking to have a full control over adhoc scenarios. Unfortunately, we cannot do this if all the nodes are running in the root NS.

I managed to run the BMV2 in their own Network namespaces some time ago. As I have the code in a VM I'm going to fork the P4 tutorials, modify it and upload it so you can see it. I will post again in this issue when everything is ready, explaining the changes that had to be made! I hope it will help to solve the problems with the by-passes of the Ad-Hoc scenarios.

Again, thank you very much for your time!

[davidcawork]

Hi again @ramonfontes 😄 !

As I told you, here I am again with the repository mounted and ready! The repository can be found here: github.com/davidcawork/P4Tutorial

You can see the changes better in this commit, 2545c3 , now I will justify why I had to make them in order to get the support of the BMV2 to run in an NS.

1. Since P4Switch inherits from Mininet's Switch class, the first thing that was done was to pass the flag from inNamespace to True in Mininet's object builder.

2. Since the inNamespace parameter forces a control plane configuration, a Mininet child class had to be created to redefine the configureControlNetworkmethod. In this method I simply make sure that the loopback interface is up.

3. Previously the configuration of the switches was done by leaving a listening port on the root netns, and running a gRPC server that would send the configuration information to it. Now the configuration of each switch must be executed on its own netns. To do this, the switch configuration via p4runtime method was extracted to a new script, called program_p4runtime_switch.py, which will be executed "inside" each NS of each switch (this will be done using the cmd method).

4. Finally, a new function has been added to check that the BMV2 has the listening port correctly opened. You can see it here, check_listening_on_port_pid. This is due to since the psutil module did not allow me to check the ports of another NS. I did it this way but I'm sure there are better ways to do it 😄.

nsenter -t {PID} -n netstat -altun | grep {gRPC_port}  

Things I'd like to improve on in the future:

• Adding argparse module in the script that programs the BMV2 (program_p4runtime_switch.py), making it more parameterized and adding default values.

• Get rid of the path dependency on the script, program_p4runtime_switch.py, here.

• Get the configuration of eachBMV2 to be given by a real connection from the NS of the "controller", or the NS root, to each Netowork namespace of each BMV2. To do this, numerous changes must be made in the configureControlNetworkmethod method. Currently we take advantage of the fact that we can "enter" the NS of each BMV2 and apply the same configuration that was applied in the P4Lang tutorials.

Best,

[ramonfontes]

So I decided to use the P4 tutorials that you created for the last step or make a new integration depending on the possible limitations that I found. Everything I've just explained here is explained in this repository, where I mention and reference everything you've created (Thanks a lot!).

You're welcome! I have to say thanks a lot too! I'm really happy to hear about this work. I was feeling let's say like a fish out of water when it comes to the P4lang-wireless Implementation. 😄. It's great to know that I'm not alone.

Besides, reading this thesis, he affirms that wmediumd also makes use of the mac80211_hwsim
module ( I would like to learn better how wmediumd really works relaxed)

Wmediumd can process frames coming from the kernel via Netlink and mac80211_hwsim has many functions developed especially for it. Try to look for the wmediumd word at https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c.

You can see the changes better in this commit, 2545c3 , now I will justify why I had to make them in order to get the support of the BMV2 to run in an NS.

Got it! While you were doing that I was playing with P4 in Mininet-WiFi ;). P4 APs (and P4Switches) are supported right now. Please take a look at the p4 branch, in particular 5e688aa. A simple topology (examples/p4/p4.py) with 2 APs, 2 Stations and 2 Hosts has been added. You can find the rules at commands_ap1.txt and commands_ap2.txt. I was wondering if you cannot apply your solution for NS in this branch. What do you think?

Things I'd like to improve on in the future

Not sure, but perhaps the p4 branch can make your life easier.

From my side I'm thinking about automating the P4 installation. My concern is that the P4 installation has not been so trivial. It sucks when there are package dependency issues. How has your experience been with this?

[ramonfontes]

From my side I'm thinking about automating the P4 installation.

P4 dependencies can be installed with util/install.sh -P (75dc947)

[davidcawork]

Wmediumd can process frames coming from the kernel via Netlink and mac80211_hwsim has many functions developed especially for it. Try to look for the wmediumd word at https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mac80211_hwsim.c.

Thank you very much for the resource! I'll take a look at future 😄

Got it! While you were doing that I was playing with P4 in Mininet-WiFi ;). P4 APs (and P4Switches) are supported right now. Please take a look at the p4 branch, in particular 5e688aa. A simple topology (examples/p4/p4.py) with 2 APs, 2 Stations and 2 Hosts has been added. You can find the rules at commands_ap1.txt and commands_ap2.txt. I was wondering if you cannot apply your solution for NS in this branch. What do you think?

Amazing work, @ramonfontes . From what I've been seeing and analyzing the implementation, it's based on github.com/ANTLab-polimi/FOP4 work in part. I've only had time to look at the code, but I'd like to play with it these days!

What it is true, and there is a thing that doesn't convince me completely, is the hierarchy of classes that they have made. Since class ONOSBmv2Switch inherits directly from Mininet's Switch class. In my opinion, that specific target where you configure the ONOS controller would be a class inherited from a base class of the BMV2. For example, in the implementation of the Mininet-P4env API a class was created, a P4Switch base class from which two extra classes were inherited, depending on whether the configuration was going to be via gRPC server or thrift port. What do you think Ramon?

Of course, i will try to carry out the implementation to supportrunning BMV2 into NS. To do this, I would like to ask you a question, as probably the years you have been maintaining this repository would have a clearer opinion.

Doubt:

Where would be possible to add a class to manage the NS? I had thought of creating a netns.py file in the path mn_wifi/, or if not, a util.py file in that same path. The motivation of this class comes from the need (At the moment of configuring via gRPC server the BMV2), in this way it is not necessary to know the path of a particular file to complete the configuration. Since this configuration would be described in RUNTIME itself.

As for the installation process, if it's quite annoying, I'm glad you already found a solution I also had to make my own for my own machine, since the two shellscript provided from the P4 Tutorials repository were choking me...

[ramonfontes]

Actually I think that the FOP4 guys are reusing bmv2.py from ONOS. As I didn't want to re-invent the wheel too I opted to consider the same bmv2.py file. However, I agree that a P4Switch class makes sense and I would be grateful if you can contribute to us too. BTW, I just removed the addP4Switch and addP4AP attributes. It doesn't make sense to add new attributes for such P4 nodes if we are actually importing their classes - so let's considering the current approach - we are already doing this with OVS and ofsoftswitch13.

Regarding NS, in my opinion you can either create the class in util.py or put it in node.py. Depending of the code (e.g. davidcawork/P4Tutorial@2545c3f) I'd prefer to put it in node.py, because we will certainly use it only with the P4 stuff.

As for the installation process, if it's quite annoying, I'm glad you already found a solution I also had to make my own for my own machine, since the two shellscript provided from the P4 Tutorials repository were choking me...

https://github.com/jafingerhut/p4-guide works fine for Ubuntu 16.04 and 18.04. However, I had to create a patch because it installs mininet at the end of installation process. Well, tested and working so far. ;)

[davidcawork]

Hello @ramonfontes ,

I'm sorry for my absence these days I was quite sick, today I will take up where I was going.. thank you very much for your work. I'll start testing the code to handle the NS!

I will make a Mininet-Wifi fork and pull-request as much as possible every time I have something consistent and valuable. Stay safe 😄!

[ramonfontes]

Hi @davidcawork,

I'm excited to see this feature. I've added Stratum in bmv2.py and ONOS is working too. I released a video yesterday (audio: pt / text: eng) where ONOS is being used - including the mobility application for handover purposes. Nowadays, the need to keep in touch with my students has become even more important.

[ramonfontes]

Hi @davidcawork,

666b66e enables inNamespace ;)

[davidcawork]

Cool! Thank you so much for your work! 😄

[davidcawork]

Hi @ramonfontes ,

I have just made a pull-request #302 with two new generic classes to control the BMv2 with support for execution in Network namespaces. I hope they are useful 😃

Stay safe!