On Thu, Mar 24, 2016 at 3:01 PM, Ben Greear <gree...@candelatech.com> wrote: > I have an application that creates two pairs of veth devices. > > a <-> b c <-> d > > b and c have a raw packet socket opened on them and I 'bridge' frames > between b and c to provide network emulation (ie, configurable delay). >
IIUC, you create two raw sockets in order to bridge these two veth pairs? That is, to receive packets on one socket and deliver packets on the other? > > I put IP 1.1.1.1/24 on a, 1.1.1.2/24 on d, and then create a UDP connection > (using policy based routing to ensure frames are sent on the appropriate > interfaces). > > This is user-space only app, and kernel in this case is completely > unmodified. > > The commit below breaks this feature: UDP frames are sniffed on both a and > d ports > (in both directions), but the UDP socket does not receive frames. > > Using normal ethernet ports, this network emulation feature works fine, so > it is > specific to VETH. > > A similar test with just sending UDP between a single veth pair: e <-> f > works fine. Maybe it has something to do with raw packets? > Yeah, I have the same feeling. Could you trace kfree_skb() to see where these packets are dropped? At UDP layer? Thanks.
