OK. I think your code has a bug.
On Mon, Aug 15, 2016 at 04:15:26PM -0400, Nikolai Snow wrote: > As I explained it before, our intent is to create a new label, construct a > flow with that label and apply actions on packets matching that label. So > far we have succeeded in creating new OF labels and creating flows that can > contain our custom labels. We are having issues with executing actions > after a match (i.e. setting a field) and we suspect our match logic might > not be working. > > Our motivation on trying to modify in_port is to see if the matching > packets are sent to a different port than their originally intended port. > In our case we are redirecting to a port to which another host is listening > and hence the ping is redirected if things are working as anticipated. > Hence, we check if the packets that are destined for the initial port we > are matching on are in fact being sent to the port we are modifying it with > our flow's set_field by seeing if the pings all respond appropriately when > testing with Mininet and by reading packet captures. We have observed the > expected changes with in_port but not with our new label. The new label > merely displays the hard coded value of our choosing or the wild carded > value of 0 when we attempt to mimic the same code paradigms as other labels > in OVS. > > I might be committing a serious blunder here and your advise is highly > appreciated. > > On Wed, Aug 10, 2016 at 5:54 PM, Ben Pfaff <b...@ovn.org> wrote: > > > On Wed, Aug 10, 2016 at 10:36:03AM -0400, Nikolai Snow wrote: > > > You were correct, the controller was the issue. The field now matches > > > between the controller and the switch as we can see values set manually > > in > > > nx-match.c on the controller when we query for the value. > > > > > > To address the second issue, we have tried created a flow using ovs-ofctl > > > that should match our new field and change the value, but when we send > > > packets between the hosts, the value change does not take effect. > > > We add the new flow as such, > > > > > > ovs-ofctl add-flow s1 SNOW=0,actions=set_field:4"->"SNOW > > > > > > When we dump the flows, it appears. However, when we read a packet > > capture, > > > the value remains 0. > > > We have tested adding flows which change the field in_port and > > successfully > > > tested this by setting the value to 2 whenever we see it is 1 as such, > > > > > > ovs-ofctl add-flow s1 in_port=1,actions=set_field:2"->'in_port > > > > > > The value does in fact get set and whenever a ping is sent to host 1, it > > is > > > not received. When checking the packet capture, we see the flow added and > > > the value of the in_port is changed and host 2 receives more pings. > > > When looking through our modifications we found that when hard coding the > > > value of our new field in nx-match.c, the value is passed to the network > > > and can be seen in captures and on the controller side. > > > We suspect that we are missing a portion of the modification that should > > > pass the value into the struct flow within the struct match which is > > called > > > in nx_put_raw. > > > Can you please share your thoughts on what the problem is with our > > changes? > > > Thanks again. > > > > I guess I don't understand how you'd observe the in_port changing, so I > > don't understand what this demonstrates. > > > > Did you write code to actually modify whatever SNOW is? > > > > Basically, you're saying, "We modified OVS and there's a bug in our > > code. What's the bug?" I don't know how to answer that. > > _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
