On 6/8/12 5:01 PM, Kazuaki ODA wrote: > Hi all, > > Recently I received a e-mail from our customer that he could not browse > our web site. I thought that was strange at first because we and most > people could browse without problems, but he could not...umm, why? > > After some investigation I've found that our web server ignores SYN > packet he sent because that has invalid TCP checksum, and his original > packet has correct checksum but that is broken after passing our > firewall using PF packet filter on 7.4-RELASE. And further more, I've > noticed that such a invalid packet is made when original packet has TCP > timestamp option and the option does not start at 16-bit word boundary > like a packet that has TCP options <mss,wscale,sackOK,timestamp,eol>. > > After all, disabling "scrub reassemble tcp" rule resolved this problem. > But I have some questions: > > Is this a bug in PF code, or original packet violates RFC? As far as I > know, last TCP option must end at 32-bit boundary but there is no > restriction for each options about position, order etc. So I think this > is a bug. Correct? > > How many systems in the world that create such a SYN packet? I think > that many OSes add NOP options before timestamp option to adjust the > starting position, but the one our customer has does not. Unfortunately > I cannot get information from him about his network environment... > > -- > Kazuaki ODA
Oh god, that font... Anyway, Reporting that we experience a problem that looks very much the same here on, at least, 8.1-RELEASE, 8.2-RELEASE. Unconfirmed on 8.3-RELEASE and 8-STABLE as we have not tested. We've also had to disabled tcp reassembly in scrubbing as it incorrectly caused packets to be dropped. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
