I'm confident that it works, since there's a unit test.
On Fri, May 25, 2012 at 07:28:29AM +0000, Prabina Pattnaik wrote: > Hi Ben, > > This patch is not working with openvswitch-1.4.1 > (ofp_print_nxt_set_controller_id function is not there in lib/ofp-print.c and > file tests/ofp-error.at is not available in openwsitch-1.4.1). > I also tried to verify on unreleased version available on Git (1.7.90) but > could not attach the physical interface and Tap interface with bridge and for > this reason could not start a VM. > > > Regards, > Prabina > > > > > -----Original Message----- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Wednesday, May 23, 2012 10:05 PM > To: Nicholas Bastin > Cc: Prabina Pattnaik; b...@openvswitch.org > Subject: Re: [ovs-discuss] OpenVSwitch - Error packet OFPFMFC_BAD_COMMAND of > code ofp_flow_mod_failed_code coming as malformed. > > On Tue, May 22, 2012 at 11:21:29PM -0700, Nicholas Bastin wrote: > > On Tue, May 22, 2012 at 2:50 AM, Prabina Pattnaik > > <prabina.pattn...@nechclst.in> wrote: > > > We agree that implementation of 'at least 64 bytes' is as per spec (to > > > allow data above 64 bytes depends on vendor specific switch > > > implementation). > > > But in current implementation, when the code (mentioned below) limits the > > > size of data to 64 bytes (if data field of the error packet > > > is more than 64 bytes), a malformed OFPFMFC_BAD_COMMAND error packets > > > gets generated (visible on wireshark with openflow > > > plugin). > > > > The wireshark plugin is (questionably) broken. Or wireshark is > > broken, you pick which you prefer.. :-) The issue is that the > > OpenFlow dissector (arguably properly…certainly I would argue that) > > passes encap'd packet-ins *back* into wireshark for further > > dissection. However, there's no way to tell wireshark "please ignore > > the fact that this packet may be truncated" - something it is capable > > of doing for outer-layer packets, so you end up with giant red > > nonsense that the packet is malformed, and not that you may have a > > truncated packet. Either way, the OVS interpretation may not be what > > you want, but it's not broken. > > I thought that OVS itself did a better job of printing these truncated > OpenFlow messages, but when I tested it I found that I was wrong, so I > sent out a patch to improve the situation: > http://openvswitch.org/pipermail/dev/2012-May/017462.html > > > > DISCLAIMER: > > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended > > for the named recipient(s) only. > > It shall not attach any liability on the originator or NECHCL or its > > affiliates. Any views or opinions presented in > > this email are solely those of the author and may not necessarily reflect the > > opinions of NECHCL or its affiliates. > > Any form of reproduction, dissemination, copying, disclosure, modification, > > distribution and / or publication of > > this message without the prior written consent of the author of this e-mail is > > strictly prohibited. If you have > > received this email in error please delete it and notify the sender > > immediately. . > > ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
