Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Mar 2003 18:50:20 -0500
From:      "Aaron Daubman" <daubma@rpi.edu>
To:        "'John Fitzgibbon'" <fitz@jfitz.com>, "'Giorgos Keramidas'" <keramida@ceid.upatras.gr>
Cc:        <freebsd-questions@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG>
Subject:   AirportExtreme with FreeBSD HostAP
Message-ID:  <000001c2f197$0bfa8b80$cd00a8c0@grievous>
In-Reply-To: <200303231333.17886.fitz@jfitz.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Hi,

I have done a bit of research on the topic, and I've only been able to =
find
sporadic postings to several newsgroups (mostly Open/Net BSD related)
hinting at the fact that Apple's AirportExtreme (talking 802.11b, not g
here) drivers are incompatible with Free/Net/Open BSD HostAP mode APs =
with
WEP enabled...=20

From my experiences, I cannot get my PowerBook to connect to my FreeBSD
4-Stable (built 2 nights ago) HostAP, WinXP clients work fine.

The PowerBook returns invalid password (128bit wep Key entered in Hex)
supplied.

Has anybody had experience getting an AirportExtreme client to work with =
a
FreeBSD HostAP? Any Pointers? (Must I disable WEP (as useless as it may
be...)?)

Thank you,
	~Aaron

-----Original Message-----
From: owner-freebsd-net@FreeBSD.ORG =
[mailto:owner-freebsd-net@FreeBSD.ORG]
On Behalf Of John Fitzgibbon
Sent: Sunday, March 23, 2003 4:33 PM
To: Giorgos Keramidas
Cc: freebsd-questions@FreeBSD.ORG; freebsd-net@FreeBSD.ORG
Subject: Re: Repeated ACKs - possible DoS?

Note to "freebsd-net" readers: I'm cc'ing this email because this seems =
like
a=20
"net" issue - full thread is in freebsd-questions.


I've been looking at the code in sys/netinet/tcp_input.c.

The behavior seems consistent with inducing tcp_input() to jump to the=20
"dropafterack" label for every incoming ACK.

The most promising way to do this seems to be to set the T/TCP options =
when=20
initializing the connection, then just stop using them on some =
subsequent=20
ACK, (or give the wrong CC value). The code is around line 1420:

/*
 * T/TCP mechanism
 *   If T/TCP was negotiated and the segment doesn't have CC,
 *   or if its CC is wrong then drop the segment.
 *   RST segments do not have to comply with this.
 */
if ((tp->t_flags & (TF_REQ_CC|TF_RCVD_CC)) =3D=3D (TF_REQ_CC|TF_RCVD_CC) =
&&
    ((to.to_flags & TOF_CC) =3D=3D 0 || tp->cc_recv !=3D to.to_cc))
        goto dropafterack;

It may also be possible to cause the jump to "dropafterack" with the
timestamp=20
option, (RFC 1323 - the code is just above the previous T/TCP code). =
This=20
would "jive" with the fact that the client connection seemed to be a =
Windows

98 machine, (from the Apache logs), and apparently the Windows 98=20
implementation of RFC 1323 is flawed. However, I'm less sure what kind =
of=20
invalid options scenario would be required.

In any case, I haven't done enough research to be 100% sure that either =
of=20
these approaches can cause the behavior I observed. All I AM sure of is =
that

I observed the repeated ACK situation, and it was a pretty darn =
effective=20
DoS. I'm also sure that banging ACKs back and forth at full speed is NOT =
how

TCP/IP is supposed to work.

Hopefully this might be enough of a lead to get someone's thought =
processes=20
going.
Fitz.


On Thursday 20 March 2003 06:02 pm, Giorgos Keramidas wrote:
> On 2003-03-20 17:15, John Fitzgibbon <fitz@jfitz.com> wrote:
> >On Thursday 20 March 2003 04:43 pm, Giorgos Keramidas wrote:
> >>> X is remote. Y is server, (FreeBSD 4.7-STABLE, built 2003/01/06)
> >>>
> >>> tcpdump shows 2 remote connections repeatedly sending "ack 1":
> >>>
> >>> 09:16:10.236812 X.64670 > Y.http: . ack 1 win 32589
> >>> 09:16:10.236879 Y.http > X.64670: . ack 489 win 58400 (DF)
> >>
> >> Hmmm, is this repeatable?  Can you try to grab the output of the
> >> following command in a log file while it happens?
> >>
> >> 	# tcpdump -n -v -s 128 -XX port 80
> >
> > I haven't seen this behavior before, and I don't know how to =
recreate it
> > :(
>
> Damn :(
>
> If this is a bug that you've hit upon, please note that command and
> run it if it ever happens to appear again.  The log file is going to
> be large, but I'll help a lot to have it around when trying to find
> out what happens.
>
> - Giorgos


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?000001c2f197$0bfa8b80$cd00a8c0>