Unfortunately pexpect isn't compatible with Python 3 strings
unless you specify unicode encoding, which isn't the default.
With this helper code, you can import pexpect from mininet.util
and get default pexpect.spawn() behavior that works with Python 3
strings.
I'm not a fan of this, but Python 3's subprocess module
complains otherwise.
For now we're only doing this on Python 3. We should probably
quantify the slowdown however.
Looking at trying to minimize code changes for Python 3.
For now we are keeping byte str() in py2 and unicode str()
in py3. It's a pain to rewrite all string code to usee
u'' for py2 compatibility. However we may need to revisit
this for pexpect().
Created compatibility wrappers in util.py:
BaseString (replacement for basestring)
decode() (optionally decode utf-8 for py3)
encode() (optionally encode utf-8 for py3)
Also we've switched from the .iter*() flavors to their
static alternatives for py2 (note they are iterators in py3!)
Changed util.errRun and clean.sh to call decode()
- the original version will caluse the latency to 0 when bandwidth
is bigger than 200;
- the TC command doesn't allow use the 0.00ms as input for latency field
Signed-off-by: hwchiu <sppsorrg@gmail.com>
Although the walkthrough doesn't specify waiting, it is a race
condition that we occasionally hit in tests. Adding a 2 second
delay seems realistic (for when a human is doing the walkthrough)
and should reduce the likelihood of hitting the race condition.
Without waiting for mn to exit, OVS keeps listening on the
static listening port, which prevents UserSwitch from listening
on it (and starting up) in the next test.
For some time, UserSwitch has suffered from abysmal performance due
to rx and tx offload settings. In the latest Ubuntu 16.04/Linux 4.4
kernel, it simply doesn't work with the default settings, since
packets with bad TCP checksums are generated at one end, passed through
the user switch, and dropped at the other. It doesn't seem to be
something we can fix in UserSwitch itself although it may be possible
to do something in the C code of the Stanford reference switch and
CPqD switch.
Presumably daemons, race conditions, or ephemeral processes
can cause the ps output to vary slightly. We allow up to
two differing lines to account for this.
Fixes#651
The version string changed in tshark 2.0.2 in Ubuntu 16.
Perhaps we should just check for the version string itself
to be more robust but this is probably OK for now.
Bob Lantz
Matthieu Coudron
Felician Nemeth
hwchiu
akoshibe
Brian O'Connor
Felix Konstantin Maurer
Jon Hall