-
Notifications
You must be signed in to change notification settings - Fork 336
MPTCP is missing from system parameters inside Mininet hosts #506
Comments
Hi Rasmus, I don't know how mininet works these days: does it create network namespaces per host or is it a VM? Because (out of tree) MPTCP's sysctl knobs are not net namespace aware: you set them on the "host" (the initial netns) but not per netns: they are not visible from the netns. Like other sysctls. If you don't know how to check, maybe try this from a "host" and check if it is not empty
Or simply check if you have MPTCP this file from a "host": (or check |
Thanks for your reply. Mininet works by running the hosts in different namespaces and they aren't separate VM's. Here are some outputs from both the host system and from within a Mininet host. It seems to be the same output regardless of if
I think it's relevant to note that creating hosts with h1 = net.addHost('h1', inNamespace=False) # don't spawn in net namespaces
h2 = net.addHost('h2', inNamespace=False) # don't spawn in net namespaces
r1 = net.addHost('r1', inNamespace=False) # don't spawn in net namespaces results in me being able to see the system parameters from inside a Mininet host by running I think I somehow need to figure out how I can mount the namespace or perhaps the "/proc/sys/net/mptcp" folder. Running
|
OK, good to know. Why do you need to access the sysctl entries from the namespaces? If you change them, they will change the behaviour in all the netns. |
Each Mininet host needs to be able to access the system parameters in order to work properly. |
I don't think you can make them appearing in Can you not dump the parameters in a file and read this file? Or maybe you can try something like as root from a netns:
then from the netns, you might be able to do:
|
Probably too late to do that for this out-of-tree kernel. Maybe time to switch to the upstream one? https://mptcp.dev |
When I do the following from within a Mininet host:
The last command fails with:
|
That might be the way forward. I am also thinking of trying this out from Debian. That might work better but I am just speculating... |
Yes, there might be a way but I never had to do that (and it is not specific to MPTCP). I don't think using Debian will change anything but why not trying. (or maybe they still have a way to use different VMs? I thought it was like that in the past, a long time ago) |
Maybe this? (probably you will get the same error)
|
Unfortunately it doesn't seem to work either:
But anyways. Thanks for the help! I will try my luck with Debian now. |
Hello,
I am having problems with certain system parameters not being accessible from within a Mininet host even though they are accessible from the host system.
After a clean install with the following:
I get the following output when running
sysctl -a | grep mptcp
outside Mininet:which is correct. But when I do the same from within a Mininet host by starting Mininet with the default topology:
sudo mn
and then running the sysctl command on, for instance, the h1 node:
mininet> h1 sysctl -a | grep mptcp
I dont get any output. In other words, the system parameters can't be found by sysctl -a from within a Mininet host.
Expected/Desired Behavior:
mininet> h1 sysctl -a | grep mptcp
=>
Actual Behavior:
mininet> h1 sysctl -a | grep mptcp
=>
Detailed Steps to Reproduce the Behavior
sudo mn
sysctl -a | grep mptcp
Additional Information
The following people seems to have had the same problem:
Best regards, Rasmus
The text was updated successfully, but these errors were encountered: