Oops, I think my last email didn't go through due to an inadvertent html attachment from my phone mail client.
Can you send us a copy of a packet you're sending and/or confirm that the IP and UDP4 checksums are set correctly in the packet? If those are set right, I think we need to read through the networking code again to see why this is broken... On Thu, Mar 24, 2016 at 9:13 PM, Ben Greear <gree...@candelatech.com> wrote: > On 03/24/2016 06:11 PM, Ben Greear wrote: >> >> On 03/24/2016 05:06 PM, Ben Greear wrote: >>> >>> On 03/24/2016 04:56 PM, Cong Wang wrote: >>>> >>>> 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? >>> >>> >>> Yes. >>> >>>>> 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? >>> >>> >>> Since reverting the patch fixes this, it almost certainly has to be due >>> to some >>> checksum checking logic. Since UDP sockets (between single veth pair) >>> works, it would appear to be related to my packet bridge, so maybe >>> it is specific to raw packets and/or sendmmsg api. >>> >>> I'll investigate it better tomorrow. >> >> >> So, I found time to poke at it this evening: >> >> Sending between two veth pairs, no packet bridge involved. > > > Errrr, to be clear: I mean sending between two ends of a single veth pair > here. > >> >> UDP: ip_summed is 3 (CHECKSUM_PARTIAL) # Works fine. >> raw packet frames, custom ether protocol (0x1111 type): ip_summed is 0 >> (NONE) # Works fine. >> >> When I try to send UDP through the veth pairs & pkt bridge, I see this: > > > Thanks, > Ben > > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com >
