Mininet 2.3.0 Release Notes
Pages 69
Clone this wiki locally
Welcome to Mininet 2.3.0!
Please read these Release Notes carefully, and enjoy using Mininet!
Python 3 Support
Mininet 2.3.0 brings Python 3 support to Mininet!
Python 2 is still supported by Mininet 2.3.0, but it may become harder to use over time because of official deprecation by the CPython project as well as eroding support from Linux distributions such as Ubuntu. Nonetheless it should be possible to install both Python 2 and Python 3 versions of Mininet in Ubuntu 20.04 LTS, and the Mininet 2.3.0 VMs include both Python 2 and Python 3. In the future we may wish to explore running under pypy
for Python 2 as it may be better supported.
To install a Python 2 mn
command:
PYTHON=python2 mininet/util/install.sh -n
To install Python 3 mn
:
PYTHON=python3 mininet/util/install.sh -n
Note that -n
just installs mn
and the base Mininet dependencies. Typically for a minimal usable Mininet
you might want -nfv
for Mininet, the (OpenFlow 1.0) user switch and controller, and Open vSwitch.
To run mn
using Python 3 explicitly:
sudo python3 `which mn`
To run mn
using Python 2 explicitly:
sudo python2 `which mn`
To find out which version of Python mn
is using by default:
echo py sys.version_info | sudo mn -v output
or
sudo mn
...
mininet> py sys.version_info
Other Features and Changes
-
RyuController
has been simplified and updated for the current RyuThe
Ryu()
constructor has changed slightly. We still add--ofp-tcp-listen-port %s
to the end ofcargs
to makeController()
happy.command
is nowryu run
so it includes therun
command but can be specified explicitly as needed.You should be able to run Ryu's simple_switch by using:
mn --controller ryu
and pass alternate modules such as
simple_switch_13
:mn --controller ryu,ryu.app.simple_switch_13
-
Mininet continuous integration (CI) testing has switched from Travis to Github Actions. Thanks to Travis.org for years of helpful CI support for Mininet and other open source projects.
-
Mininet CI testing currently tests Mininet 2.3.0 on Ubuntu 20.04, 18.04, 16.04 for 64-bit/amd64 and 16.04 for 32-bit/i386.
-
Premade Mininet VMs are currently being built on an experimental basis using Github Actions at https://github.com/mininet/vm-build/actions .
-
Many scripts in the Mininet source tree now start with
#!/usr/bin/env python
to facilitate use withvirtualenv
. See below for important security information.
Security Warnings and Advisories
-
Scripts included in Mininet 2.3.0 (such as
mn
andexamples/*
now use#!/usr/bin/env python
to facilitate direct use withvirtualenv
. This seems like the right thing to do to make it easier to use Mininet withvirtualenv
(and potentially Python IDEs that usevirtualenv
.)However, it is worth noting that this could open up a security hole or reliability issue if you end up executing an unexpected Python interpreter in your path.
Note when
mn
is installed (for example usinginstall.sh -n
orPYTHON=python sudo make install
this#!
line will be changed to refer to the interpreter used for the installation. -
Note that Mininet in general runs as
root
(at least until we change it to use more granular capabilities) so for safety we recommend running it in a virtual (or other) machine that you don't mind destroying accidentally. If you run it in your main OS, you should be careful to avoid running unexpected or undesired code withroot
privileges. Note that VM execution isn't 100% secure; virtual drivers often contain bugs that can enable VM escape or privilege escalation. -
Official Mininet 2.3.0 VMs do not include any SSH (server or client) keys; instead they are regenerated in
/etc/rc.local
. Please do not distribute Mininet (or other) VM images that include SSH server server or client keys (as some people have done for courses, tutorials, etc.) since using identical, publicly visible SSH keys compromises SSH privacy and also allows the VM image to be impersonated or MITMed. -
An unofficial
pypi
repo has been created by third parties; we do not currently recommend its use because:- It may not contain the specific released code from the Mininet repo
- Mininet cannot currently be fully installed using
pip
orpip3
(it requiresmnexec
, which must be compiled for the particular architecture such asarm64
,i386
,armhf
, etc.)
Errata
-
Although Mininet 2.3.0 uses
pip
andpip3
to install itself from source, this does not currently install all of the base requirements for running Mininet (notablymnexec
and its documentation), and uninstalling it only removes the Python components. Note thatmnexec
must be compiled for the appropriate architecture (arm64
,i386
,armhf
etc..) In the future we may be able to create apip
package that includes binaries for a variety of architectures, or we may include a pure Python version ofmnexec
which would work across architectures. As noted above, we do not currently recommend the third-party, unofficialpip
packages frompypi
. -
install.sh -3f
currently fails on Ubuntu 20 due to the https://github.com/CPqD/ofsoftswitch13 build being broken. Hopefully this can be resolved in the upstream project. -
net.waitConnected()
currently hangs withofsoftswitch13
due todpctl
not working as expected. As a workaround, please specify a timeout (e.g.--twait 5
). -
Some tests dump their output to
stdout
; this was changed to help diagnose some test failures seen running on GitHub Actions CI but not when run locally. -
To generate the API documentation, we are still using the older
doxypy
and installing it usingpip
. We may switch fromdoxypy
todoxypypy
in the future, butpython3-doxypypy
seems to be broken in Ubuntu 20.04. Hopefully this will be fixed in the future and we may be able to switch todoxypypy
. -
Installation on {Fedora, RHEL, OpenSUSE, Raspbian, etc.} has not been fully tested and may be revised at a future date. Ubuntu is tested in CI, and Debian 10 passed all tests in manual testing.
-
install.sh -fnv
on Fedora 33 does not appear to install all dependencies, andmake test
currently has many test failures, some of them apparently related to performance modeling (e.g.CPULimitedHost
andTCIntf
.) We welcome pull requests to enable all of the tests to pass on Fedora and other distributions. -
VM Images should have the correct 2.3.0 final installation, but the active branch may be
master
rather than a branch corresponding to2.3.0
. To check out a specific 2.3.0 branch, usecd ~/mininet; git checkout -b v2.3.0 2.3.0
-
Wireshark in Ubuntu doesn't work out of the box with XQuartz (macOS), resulting in the error
Could not load the Qt platform plugin "xcb"…
. This seems to be due tolibdouble-conversion
being broken. To fix it in Ubuntu 20.04:$ dpkg -l | grep libdouble-conversion # to see which version you have $ sudo apt remove libdouble-conversion3 # be sure to specify the right version $ sudo apt autoremove # get rid of things that depend on library, including wireshark $ sudo apt install wireshark # reinstall wireshark
-
mnexec -v
for Mininet 2.3.0 prints a blank line rather than the correct version number #1052 (fixed inmaster
) -
MiniEdit might not save or load topologies properly when running under Python 3, and may have other issues #1049 (fixed in
master
) -
Debian packaging in the Mininet github repo is not up to date but may be updated in the future.
-
By default,
Ryu
uses fairly verbose and slow logging. Unfortunately it is hard to turn this off since thecargs
parameter is expected to contain%d
and aTypeError
will be raised otherwise. As a workaround in 2.3.0 you can may be able to use--user-flags
:sudo mn --controller ryu,cargs='ryu.app.simple_switch --default-log-level=30 --user-flags=%d' -w ...
Acknowledgments
Thanks to Tomasz Buchert and Santiago Ruano Rincón for packaging and release support in Debian 11 Bullseye!
Thanks to the FAUCET project and Google for supporting the Python 3 work.
Thanks to all of the Mininet users and contributors!