hostapd crash (due to unaligned access)

[M. Grabert]

On Mon, 15 Mar 2004, Jouni Malinen wrote:

> > Protocol 3 is something that the driver doesn't ever pass to hostapd.
> > The real problem is that you are getting such frames.  See what happens
> > with fc in hostap_ap_tx_cb().
> >
> > Try the old hostapd with the new driver and vice versa to see where the
> > bug was introduced.

Tried that (hostapd version 0.1.2 and CVS hostap driver) and it worked fine!

I also realized you have changed the specific code in the latest CVS,
and the CVS hostapd now works fine, too!

> > You can set debug=3 and daemonize=0 in hostapd.conf and see frames dumps.
> > Look at the frames with the first byte having bits 0 and 1 set.  You can
> > post one to the list.
>
> Yes, it would be interesting to find out why this was happening, so full
> debug dump of that frame would indeed be interesting.

Will do that when I have time :-/

I only saw this problem everytime I use a wlan client, right after I the
client tried to connect the hostapd access point (and then when
connected, every couple of minutes), so it is definitely triggered by my
wlan clients.

Btw, I just only use Prism cards (all using PRI 1.1.1 and STA 1.8.0), but
the problem was also there with STA 1.7.4 (everything below that was not
really stable on my 'odd' machine).

And no matter what kind of client - whether Linux (hostap driver) or
Windows (Linksys Prism driver that comes with Win XP -, I always got the
"unaligned access" messages, ie. those protocol 3 frames.

So even using hostap drivers only (for both AP and client) it was/is
causing these frames ...


> > As for that line, it should probably be changed to "elen = (u16 *) (buf +
> > len - 2);" but it shouldn't matter - this code should not be run at all!
>
> Oops.. It should be quite obvisous by now that this code has never
> really been tested (since it is not used) ;-). I fixed the offset and in
> addition, I fixed the potentially unaligned read of that length. hostapd
> is not supposed to cause unaligned accesses, so this kind of code is
> considered a bug. There may be couple of those lurking around somewhere,
> but I will fix them whenever they are reported. I'm mostly using x86, so
> I do not notice these that easily.

As I said before, your latest changes in CVS seem to have fixed the
alignment!

I'm now using the latest CVS driver and will report back whether there
are still stability problems (and when I have time I'll also try to
figure out what causes these protocol 3 frames).


Thanks alot,
   Max