Jesse and Pravin, can you comment on the best way to deal with this long-standing bug?
On Tue, May 26, 2015 at 09:18:30PM -0700, Jon Gainsley wrote: > Hi Ben, > > Thanks for your response. Yeah, that's exactly it. I tracked it down to > pop_vlan(), which was not popping the vlan because skb->protocol was set to > ETH_P_ALL, rather than ETH_P_8021Q. The reason it works on the first few > packets is without a rule, the packet is upcalled, which clones skb and > properly assigns skb->protocol by parsing the packet. > > If it's a kernel bug, it's not fixed in 3.16. I've modified > datapath/actions.c:pop_vlan to check the packet's eth proto and set > skb->protocol to ETH_P_8021Q if that's what's in the packet, so the vlan > gets popped correctly. I don't know if you have any comments on if that's a > valid workaround, but it's what I'm going to try for now and see how it > goes. > > Thanks! > -Jon > > > > On Tue, May 26, 2015 at 6:22 PM, Ben Pfaff <[email protected]> wrote: > > > On Wed, May 20, 2015 at 01:45:37PM -0700, Jon Gainsley wrote: > > > Hi, > > > > > > I'm wondering if anyone can help me with this. I am having trouble > > > inserting raw vlan tagged packets into the vswitch using an AF_PACKET > > > socket. I have the following simple bridge: > > > > This kind of sounds like this kernel bug described in the thread here: > > http://openvswitch.org/pipermail/dev/2011-December/013948.html > > > > I don't know whether it's been fixed. > > _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
