PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation
- From: Kazuaki ODA <kazuaki@xxxxxxxxxxxx>
- Date: Sat, 09 Jun 2012 00:01:46 +0900
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...
freebsd-net@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: FreeBSD 8.2-STABLE sending FIN no ACK packets.
- Next by Date: Re: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation
- Previous by thread: recommended 10g cards
- Next by thread: Re: PF "scrub reassemble tcp" makes a packet with invalid TCP checksum depending on the situation