ofproto-dpif: Ignore ECN bits in OFPAT_SET_NW_TOS actions.
OpenFlow 1.0 doesn't say that the ECN bits in OFPAT_SET_NW_TOS actions must
be zero, but Open vSwitch ODP implementations do require that, so mask off
those bits before storing the nw_tos into the flow.
python: Make invalid UTF-8 sequence messages consistent across Python versions.
Given the invalid input <C0 22>, some versions of Python report <C0> as the
invalid sequence and other versions report <C0 22> as the invalid sequence.
Similarly, given input <ED 80 7F>, some report <ED 80> and others report
<ED 80 7F> as the invalid sequence. This caused spurious test failures for
the test "no invalid UTF-8 sequences in strings - Python", so this commit
makes the messages consistent by dropping the extra trailing byte from the
message.
I first noticed the longer sequences <C0 22> and <ED 80 7F> on Ubuntu
10.04 with python version 2.6.5-0ubuntu1, but undoubtedly it exists
elsewhere also.
OVS has two Python tests that have always failed, for reasons not
understood, since they were added to the tree. This commit fixes them.
One problem was that Python was assuming that stdout was encoded in ASCII.
Apparently the only way to "fix" this at runtime is to set PYTHONIOENCODING
to utf_8 in the environment, so this change does that.
Second, it appears that Python really doesn't like to print invalid UTF-8,
so this avoids doing that in python/ovs/json.py, instead just printing
the hexadecimal values of the invalid bytes. For consistency, it makes
the same change to the C version.
Third, the C version of test-ovsdb doesn't check UTF-8 for consistency, it
just sends it blindly to the OVSDB server, but Python does check it and so
it bails out earlier. This commit changes the Python version of the
"no invalid UTF-8 sequences in strings" to allow for the slight difference
in output that occurs for that reason.
Finally, test-ovsdb.py needs to convert error messages to Unicode
explicitly before printing them in the "parse-atoms" function. I don't
really understand why, but now it works.
By default we set the DF bit on tunneled packets because we want to
get path MTU discovery from the underlying network. In turn this
causes Linux to leave the IP ID as 0 because it believes that
fragmentation can never occur. However, with GRE fragmentation is
still possible because we may get a large packet to be encapsulated
and let the local IP stack do fragmentation. As long as packets are
kept in order fragments are not misassociated and everything works fine.
However, if there is reordering in the underlying network then packets
can become corrupted. This forces selection of an IP ID for GRE packets
to avoid misassociation.
