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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c2f197$0bfa8b80$cd00a8c0>