UPDATED: DoS on hostap
xam at cs.ucc.ie
Tue Apr 6 04:15:18 EDT 2004
On Mon, 5 Apr 2004, Jouni Malinen wrote:
> On Sat, Apr 03, 2004 at 06:18:49AM +0100, M. Grabert wrote:
> > Same for me (albeit on a rather 'obscure' platform: Linux/PA-RISC).
> > The entries I see in my kernel logs (of the server) are actually in the form
> > "Could not find STA '00:01:XX:XX:XX:XX' for this TX error (@yyyyyyyy)"
> > whereas the four 'XX' bytes are the first four bytes of the *servers* wlan
> > MAC address (ie. as in XX:XX:XX:XX:xx:xx).
> This is supposed to mean that the driver send a packet to
> 00:01:XX:XX:XX:XX and that frame was not acknowledged. The processing of
> the report failed because the said address was not found from STA table.
> Host AP is supposed to drop the TX frame to not associated addresses,
> show this should not really happen.. The off-by-two offset is somewhat
> odd, though. So maybe this frame was actually to the XX:XX:XX:XX:xx:xx
> address and it was misread from the wlan card.
Yes, would make sense, except that:
- the XX:XX:XX:XX:xx:xx address is the wlan0 (and also br0) MAC address of
the server (which runs hostapd & bridging), not the client.
ifconfig -a, brctl showmacs etc. all report the correct MAC.
- the server (where the error messages are logged) wouldn't have a reason
to send a package to it's own wlan0, at least I don't find any good
reason why the kernel would try to send a frame ...
- the off-by-two offset is consistent (every 2 minutes, every day), even
if there are no clients connected (anymore). However the messages don't
start until a client was connected.
> I would expect this kind of errors with PCI cards and old firmware (PRI
> 1.0.5, STA 1.3.4 or older), but you seem to be using newer versions that
> have some bugs fixed in PCI access.
Yes, I'm using PRI 1.1.0 and STA 1.8.0. I think STA 1.7.4 had the same
problem. I know for sure that older versions (IIRC 0.1.2) didn't produce
these error logs, so I expect a driver issue.
> It might be worthwhile to print out the skb data buffer in
> hostap_handle_sta_tx_exc() to find out what the hardware is trying to
> report. If you are willing to test this, you could use the attached
> patch to change the driver to do this.
Thanks, but I will take me a while to test this, since the machine
is in use most of the time ... I'll test it as soon as I have time
and nobody need to access the machine ;-)
> > Also interesting is that the value for 'yyyyyy' of subsequent log entries
> > is always increased by 12490-12510.
> That value is a timestamp (number of timer tick from the system
> startup). In your case, I would assume that HZ=100, so 12500 difference
> would be 125 second and that matches with what you write below.
Yes, PA-RISC has HZ=100.
> > Another important note: the messages start to appear once a client
> > connects to the server. From then on it never stops (if I disconnect/power off
> > the client, the kernel log messages still continue to appear every 2:05 mins).
> Were you using hostapd or not? Have you changed Host AP inactivity
> timeout (normally 300 seconds)?
Yes, I'm using hostapd (with 128bit WEP shared key), but didn't change
any of the default values, except the SSID.
> Does the STA entry disappear from
> /proc/net/hostap/wlan# within 10 minutes after you disconnect the
> client? Do you get these messages even after that?
I haven't checked whether the STA entry disappears in /proc/net/hostap/wlan0,
but the messages still appear (every 125 seconds), even after
all clients have been disconnected.
If I reboot the machine, and no wireless clients are connected, no
messages appear. However they start to appear as soon as a wireless client
has been authenticated to the server ...
More information about the HostAP