At Mon, 3 Jan 2005 01:31:29 -0600 (CST),
Mike Silbersack wrote:
> For the life of me, I can't figure out why SYN packets (other than delayed
> retransmissions of the original SYN) would ever show up once a connection
> is in the ESTABLISHED state.
They "shouldn't" and I think ignoring them mak
Current FreeBSD problem reports
Critical problems
Serious problems
S Submitted Tracker Resp. Description
---
o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap
o [2003/10/14] kern
Synopsis: [patch] Missing splx in ether_output_frame (-stable)
Responsible-Changed-From-To: freebsd-net->rwatson
Responsible-Changed-By: rwatson
Responsible-Changed-When: Mon Jan 3 12:25:48 GMT 2005
Responsible-Changed-Why:
Grab ownership of this PR.
http://www.freebsd.org/cgi/query-pr.cgi?pr=5
On Jan 3, 2005, at 2:31 AM, Mike Silbersack wrote:
For the life of me, I can't figure out why SYN packets (other than
delayed retransmissions of the original SYN) would ever show up once a
connection is in the ESTABLISHED state. So, I'm proposing the
attached patch, which simply ignores any pac
> The SYN side of the equation, however, is a bit more tricky. The
> proposed RFC recommends ACKing SYN packets in the window, just like
> we do to SYN packets to the left of the window right now.
>
> For the life of me, I can't figure out why SYN packets (other than
> delayed retransmissions of
On 3 Jan, Mike Silbersack wrote:
>
> With re's permission, I'm going to commit FreeBSD's fix for the RST part
> of the slipping in the window attack to 4.11 in the next few days. That's
> not a big deal, we seem to have an acceptable solution there. (See
> tcp_input.c rev 1.235 for more info
On 3 Jan, Don Lewis wrote:
> /*
> * If a SYN is in the window, then this is an
> * error and we send an RST and drop the connection.
> */
> if (thflags & TH_SYN) {
> if (tcp_insecure_syn == 0)
> goto drop;
>
Hello,
I posted this question to freebsd-arch earlier. Stefan Bethke suggested
that I try freebsd-net instead.
We are building a network appliance running FreeBSD 5.3 and under very
heavy network traffic the user processes don't get scheduled for an
unacceptable period of time. Marking the
On Mon, 3 Jan 2005, Charles Swiger wrote:
Are you relying on the IPID or the connection tuple of
srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated
with an already established connection?
Connection tuple.
This means that SYN packets left of the window will no longer rec
On Mon, 3 Jan 2005, Don Lewis wrote:
For the life of me, I can't figure out why SYN packets (other than delayed
retransmissions of the original SYN) would ever show up once a connection
is in the ESTABLISHED state.
It can happen if one side of the connection crashes and tries to
reconnect using the
On 3 Jan, Mike Silbersack wrote:
>
> On Mon, 3 Jan 2005, Don Lewis wrote:
>
>>> For the life of me, I can't figure out why SYN packets (other than delayed
>>> retransmissions of the original SYN) would ever show up once a connection
>>> is in the ESTABLISHED state.
>>
>> It can happen if one sid
On Mon, 3 Jan 2005, Don Lewis wrote:
That's pretty much what previous versions of the draft suggested. The
earlier versions made some suggestions about how to deal with the corner
case by adjusting the sequence number in ACK, but these schemes added a
bunch of complexity and had some fatal flaws.
I
On 4 Jan, Mike Silbersack wrote:
>
> On Mon, 3 Jan 2005, Don Lewis wrote:
>> I'm not sure that it makes sense to rate limit the ACKs in this special
>> case. If an attacker has enough information to trigger an ACK response
>> flood from the hardened stack, he could still produce a flood by turn
13 matches
Mail list logo
