[ovs-discuss] In 'OVS Faucet Tutorial', router does not work as expected at 'Step 4: Router Broadcasts ARP Request'

[Brad Cowie]

We've had a bit of a think about this, variable length probably isn't too
important (static 64b is probably fine), but yes, being able to set those
64 bytes will be quite useful with say with an extra "payload=0xC0FEFE"
argument on ofproto/trace.

Brad

On 18 January 2018 at 07:17, Ben Pfaff <blp at ovn.org> wrote:

> OK, sounds good.
>
> Do you think you need the ability to inject payloads of a specific
> length or content?  It's easy to, for example, always generate 64 bytes
> of payload, but it would be a little more challenging to plumb through
> extra data or metadata.
>
> On Mon, Jan 15, 2018 at 01:48:10PM +1300, Brad Cowie wrote:
> > Hi Ben,
> >
> > We looked a bit closer at this problem, and turns out the packet header
> > size we were getting back from Ryu wasn't what we were expecting. We're
> now
> > calculating this correctly ourselves (instead of relying on Ryu) which
> > removes the need for disabling the IP header length check in the tutorial
> > (I've send another patch towards dev at openvswitch.org that does this).
> >
> > As for being able to inject payload into ofproto/trace generated packets
> I
> > think this would be quite useful for folks like us. We are looking at
> > moving our test suite to using ofproto/trace to generate packets (instead
> > of scapy) for throwing at test scenarios because it's considerably more
> > lightweight and we are already using openvswitch as the core of our test
> > suite.
> >
> > Brad
> >
> > On 9 January 2018 at 05:51, Ben Pfaff <blp at ovn.org> wrote:
> >
> > > [dropping OP, who probably doesn't care]
> > >
> > > On Sat, Jan 06, 2018 at 12:07:09PM +1300, Brad Cowie wrote:
> > > > What happened is that in faucet 1.6.12 we added a bunch of new packet
> > > > handling sanity checks to help improve security of faucet's packet
> > > > handling. Packets made by ofproto/trace -generate will have a
> zero-length
> > > > payload which trips some of our sanity checks which will cause us to
> drop
> > > > the packet.
> > >
> > > If OVS generated a packet with some nonzero size payload, would that
> fix
> > > the problem?  It's easy for us to change the details, we would just add
> > > some code to flow_compose_l4() in lib/flow.c to put some L7 data into
> > > the UDP packet.
> > >
> > > I suspect that changing the tutorial from using UDP to TCP might also
> > > work around the issue?  After all, TCP packets with empty payloads are
> > > pretty common, at least (off the top of my head) if they have SYN or
> FIN
> > > or RST attached.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180118/045c46f6/attachment.html>