>>> The appended patch fixes the problem too.
>>> diff -urN linux-2.2.13/net/ipv4/tcp_ipv4.c linux-2.2.13/net/ipv4/tcp_ipv4.c
>>> --- linux-2.2.13/net/ipv4/tcp_ipv4.c Wed Oct 20 02:14:02 1999
>>> +++ linux-2.2.13/net/ipv4/tcp_ipv4.c Mon Nov 1 15:58:04 1999
>>> @@ -1615,7 +1615,8 @@
>>> sk = tcp_check_req(sk, skb, req);
>>> }
>>> #ifdef CONFIG_SYN_COOKIES
>>> - else if (flg == __constant_htonl(0x00120000)) {
>>> + else if ((flg & __constant_htonl(0x00120000))==__constant_htonl(0x00100000))
>>> + {
>>> sk = cookie_v4_check(sk, skb, &(IPCB(skb)->opt));
>>> }
>>> #endif
>> Can I confirm that that patch is correct? The old test required both
>> bits 17 and 20 to be set, whilst the revised test requires bit 17 to
>> be clear instead ???
> No, you're in the wrong byte order. Look at the header picture in RFC793.
8-) I was counting the bits inside the brackets, without reference
elsewhere. No problem there though: As long as you knew which bits I
was referring to, it doesn't matter how they're numbered.
> The test checks for the ACK (bit 12) and the SYN (bit 15) bit.
Nodz.
> The old check checks for SYN and ACK both set, the new one
> checks that ACK is set and SYN isn't (other flags are and'ed out
> earlier) This is because the cookie checks for the third packet
> in the TCP three way exchange, which is supposed to be a plain
> ACK. Check for a syn ack was obviously wrong.
Ah 8-) I'm no expert on TCP so wouldn't've noticed this anyway.
> The code before 2.2.11 just used an unconditional else.
> In 2.3 this mess is replaced by symbolic flags BTW.
Even better...
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/