Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1391679
| From | Ben Greear <greearb@candelatech.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. |
| Date | 2016-04-30 23:00 +0200 |
| Message-ID | <rtK9A-5Lq-19@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <rsHQu-23g-1@gated-at.bofh.it> <rsRwv-1zl-65@gated-at.bofh.it> <rtIKu-4Aw-19@gated-at.bofh.it> <rtJ3Q-4Mc-3@gated-at.bofh.it> <rtJdw-4RV-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 04/30/2016 12:54 PM, Tom Herbert wrote: > We've put considerable effort into cleaning up the checksum interface > to make it as unambiguous as possible, please be very careful to > follow it. Broken checksum processing is really hard to detect and > debug. > > CHECKSUM_UNNECESSARY means that some number of _specific_ checksums > (indicated by csum_level) have been verified to be correct in a > packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is > never right. If CHECKSUM_UNNECESSARY is set in such a manner but the > checksum it would refer to has not been verified and is incorrect this > is a major bug. Suppose I know that the packet received on a packet-socket has already been verified by a NIC that supports hardware checksumming. Then, I want to transmit it on a veth interface using a second packet socket. I do not want veth to recalculate the checksum on transmit, nor to validate it on the peer veth on receive, because I do not want to waste the CPU cycles. I am assuming that my app is not accidentally corrupting frames, so the checksum can never be bad. How should the checksumming be configured for the packets going into the packet-socket from user-space? Also, I might want to send raw frames that do have broken checksums (lets assume a real NIC, not veth), and I want them to hit the wire with those bad checksums. How do I configure the checksumming in this case? Thanks, Ben > > Tom > > On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear <greearb@candelatech.com> wrote: >> >> >> On 04/30/2016 11:33 AM, Ben Hutchings wrote: >>> >>> On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote: >>>> >>>> Hello, >> >> >>>>> >>>>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a >>>> >>>> Actually, no, this is not really a regression. >>> >>> [...] >>> >>> It really is. Even though the old behaviour was a bug (raw packets >>> should not be changed), if there are real applications that depend on >>> that then we have to keep those applications working somehow. >> >> >> To be honest, I fail to see why the old behaviour is a bug when sending >> raw packets from user-space. If raw packets should not be changed, then >> we need some way to specify what the checksum setting is to begin with, >> otherwise, user-space has not enough control. >> >> A socket option for new programs, and sysctl configurable defaults for raw >> sockets >> for old binary programs would be sufficient I think. >> >> >> Thanks, >> Ben >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Sabrina Dubroca <sd@queasysnail.net> - 2016-04-28 12:40 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Greear <greearb@candelatech.com> - 2016-04-28 15:50 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Hutchings <ben@decadent.org.uk> - 2016-04-30 21:30 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Hutchings <ben@decadent.org.uk> - 2016-04-30 21:30 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Greear <greearb@candelatech.com> - 2016-04-30 21:50 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Tom Herbert <tom@herbertland.com> - 2016-04-30 22:00 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Greear <greearb@candelatech.com> - 2016-04-30 23:00 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Vijay Pandurangan <vijayp@vijayp.ca> - 2016-04-30 23:20 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Greear <greearb@candelatech.com> - 2016-04-30 23:40 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Vijay Pandurangan <vijayp@vijayp.ca> - 2016-04-30 23:40 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Greear <greearb@candelatech.com> - 2016-05-01 00:00 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Vijay Pandurangan <vijayp@vijayp.ca> - 2016-05-01 00:10 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Ben Greear <greearb@candelatech.com> - 2016-05-01 00:50 +0200
Re: [PATCH 3.2 085/115] veth: don???t modify ip_summed; doing so treats packets with bad checksums as good. Willy Tarreau <w@1wt.eu> - 2016-05-01 07:40 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Tom Herbert <tom@herbertland.com> - 2016-05-01 00:50 +0200
Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. Vijay Pandurangan <vijayp@vijayp.ca> - 2016-04-30 22:20 +0200
csiph-web