packet_out is incorrectly blocked with partially overlapping flow space

[billsnow]

In a packet out, the in_port is typically OFPP_NONE or OFPP_ALL, etc. The FV ignores that value when testing whether a given controller is allowed to send a packet_out's embedded packet, and assumes it's OFPP_ALL. This incorrectly matches all of the slices with the same port, so, for example: if Alice and Bob has overlapping flowspace (e.g., both match all packets), but where partitioned by port, e.g., Alice has ports 1-4 and Bob has ports 5-8, and Bob had priority over Alice, then alice should be able to send any packet as long as it is output to ports 1-4. But, in the current code, she is prevented from doing so, because the way the match is constructed also matches Bob's rules, and Bob's is higher priority. The fix is, rather than rewrite the match logic (yuck!), to ignore match rules that don't fit Alice's slice. So, the code is now: [FVPacketOut.java line ~50] { match.loadFromPacket(this.getPacketData(), this.getInPort()); // TODO : for efficiency, do this lookup on the slice flowspace, // not the switch List<FlowEntry> flowEntries = fvClassifier.getSwitchFlowMap() .matches(fvClassifier.getSwitchInfo().getDatapathId(), match); if ((flowEntries == null) // got no response || (flowEntries.size() < 1) // nothing matched has write permissions || (!flowEntries.get(0).hasPermissions( fvSlicer.getSliceName(), SliceAction.WRITE)) } So, the line flowEntries.get(0).hasPermissions() only looks at the highest priority entry. Instead, it should go through entries 0...n until it finds the first entry that contains a slice from alice's slice, i.e., fvSlicer.getPorts().contains(port);

Original issue information: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-130