On 25/09/2015, at 9:33 PM, Stuart Henderson wrote: > > [snip comment; I completely agree] > >> Another (home) router I administer was seeing IIRC five [bad TCP checksums] a >> day on average over 42 days, something we expect of a globe-spanning >> internetwork. >> Passing one of these damaged segments to the user sufficies to break MACs >> and drop >> secure connections. > > While I do generally support this diff as long as it doesn't have > a big negative impact on performance, the implication of mentioning > this is that these are packets which PF would pass on to other > hosts with a re-calculated checksum if the packets were modified > (nat, scrub etc). But that's not the case because they would be > checked on input to PF so wouldn't make it that far.
If I implied PF would mask these damaged packets I didn't mean to. As you say, PF would drop them when it tried to alter them (nat, scrub, etc). Rather, the stats show that router faults can't be dismissed as irrelevant in practice. And just one passed to the user in a secure stream will have a significant impact, independently of its payload, by breaking the connection. As to the patch, I have edited it for length and coherence but will hold off posting it for a week or two, as I hear there's much work going on elsewhere in the network stack. If anyone would like a copy in the meantime please contact me privately. I don't expect a big performance hit, if any, as it works the same way as 5.3 did plus or minus a few function calls. Nor could I measure a difference netcatting a largish file over 100BaseT via my Alix 2d2 running PF doing nat, scrub, etc. I'd appreciate more data or reports, positive or negative, though. best, Richard. P.S. I earlier recommended EWD1023 from memory, that should have been EWD1036.
