UPDATED: DoS on hostap

[M. Grabert]

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 ...


Thanks,
   Max