I'd like to apologize to everyone for dropping the ball on this. I came
down with a cold on Monday evening, and was pretty out of it until
Thursday. By the time I had caught back up on everything I needed to, we
had already missed the window for 4.11. I'll get back into this in a few
days.
On 10 Jan, Mike Silbersack wrote:
>
> On Mon, 10 Jan 2005, Don Lewis wrote:
>
>> Now that I've looked at the above case, it looks to me like your
>> suggested patch might affect the response to a legitimate duplicate SYN.
>> It will definitely follow a different code path.
>
> You're right, I ne
On Mon, 10 Jan 2005, Mike Silbersack wrote:
We could do something there like
if (th->th_seq != tp->irs) {
goto dropafterack; /* Or however we handle these bad syns */
} else {
thflags &= ~TH_SYN;
th->th_seq++;
if (th->th_urp > 1)
th->th_urp--;
else
thflags &= ~TH_URG;
todrop
On Mon, 10 Jan 2005, Don Lewis wrote:
Now that I've looked at the above case, it looks to me like your
suggested patch might affect the response to a legitimate duplicate SYN.
It will definitely follow a different code path.
You're right, I neglected to handle the duplicate SYN case.
Couldn't we ce
After a bit more thinking ...
On 10 Jan, Don Lewis wrote:
> and then after the dropafterack label add the code:
>
> + if (thflags & TH_SYN) {
> + if (tp->t_state == TCPS_ESTABLISHED &&
> + tcp_insecure_syn == 0) {
> + if (badport_bandlim(BANDLI
On 9 Jan, Mike Silbersack wrote:
>
> Ok, here's an updated patch for the SYN case. I've included the patch
> relative to 6.x, and some text from a tcpdump showing it in action.
>
> It responds to each SYN with an ACK like the latest tcpsecure document
> states, but it uses a global counter to
Ok, here's an updated patch for the SYN case. I've included the patch
relative to 6.x, and some text from a tcpdump showing it in action.
It responds to each SYN with an ACK like the latest tcpsecure document
states, but it uses a global counter to rate limit the number of ACKs of
this type th
