tree 3a8e6a1e4b80753f6403cd4c81f545613e1328b5
parent 5b8b39c6f6c6d754d52e04342a11df13cadff564
author Zsolt Haraszti <zharaszt@ciena.com> 1456988529 -0800
committer Zsolt Haraszti <zharaszt@ciena.com> 1457394975 -0800

Completed 2nd complex testcase with 2 ONUs

For details of the two completed scenarios, please read the Python
file (see class doc strings).

Change-Id: I84edc5c26be3816e9b670a5c97feb072286f0070

Use flow_delete_strict and fake dataplane mode

Two changes in this request:

1. I noticed that the installEapolRule() method in install=False mode
   uses the flow_delete message instead of the flow_delete_strict.
   However, the way the message is constructed, this should never have
   the intended effect, because the out_port is left to 0. Per the
   OpenFlow spec, this will match only flows that has the output
   action pointing to port 0. The flow_delete would work only if
   out_port is set to OFPP_ANY (4294967295). Alternatively, the
   flow_delete_strict should be used, in which case the out_port
   attribute is ignored. I decided that the latter makes more sense
   in this use-case.

2. Introduced a "fake-dataplane" mode in which mode all verify_packet
   and verify_packet_in calls automatically pass. This allows the
   tests to manage flows and groups on an OF agent, without actually
   testing packet forwarding, which is useful if the goal is to
   review what flow command the OLT use-case rely on.

Change-Id: I3d39953c39d39a386802c44c5a84aac7560f9c09

Create a pair of isolated Eapol tests

These are extracts from the complex usecase. They differ from the
olt.py Eapol out/in tests in that they really target the ONU port
and not all ports, hence they are more realistic. The main reason
I created them is that on the Tibit OLT Eapol forwarding is not
setup on the OLT port, only on the ONU ports. This is correct behavior
but the original tests would fail with it.

Change-Id: I340c5798c806277ce51b758b6a35f5c9b560a91e