[Prism54-devel] handle mgmt timeouts by resetting hardware

Denis Vlasenko vda at port.imtp.ilyichevsk.odessa.ua
Tue Aug 10 20:46:50 UTC 2004


On Tuesday 10 August 2004 19:27, Margit Schubert-While wrote:
> Denis scribeth:
>  >> setrate - User parameter parsing in kernel? - No way.
>  >> This stuff belongs in user space ie. wireless tools.
>  >
>  >Care to explain why?
>
> Buffer Overflow attacks ?

Yes, that's possible. This requires buggy parser, tho.
You might as easily have bugs in code which parse binary data.

>  >> Define with Jean some conceivable method of passing
>  >> the info. (Assuming .5Mbps increments and that Gigabit WLAN
>  >>
>  > >is coming, maybe something like a 256-byte bitmap, eeek)
>  >
>  > I disagree. Parsing binary data will be as difficult,
>  > plus you get all the headaches of binary data being
>  > less extendable and less readable. So, why painfully parse
>  > ASCII into binary format in wireless tools and then _again_
>  > painfully parse 'generic wireless' binary format
>  > into one understood by particular hardware?
>  > However, I will promptly change my mind as soon as you
>  > will describe at least semi-sane binary format for it.
>  > No, 256-bit bitmap is not sane (will crash and burn
>
> I said 256 BYTE = 2048 bits
> So, (parsed input * 2) as direct index into bit table.
> That caters for .5 to Gigabit.

What about different modulations? My set_rates code can specify that:
"set_rates 5p,11p 22p,33p" = 5.5 and 11Mbit/s PBCC basic rate,
22 and 33Mbit/s PBCC operational. (Generic example, won't work
on prism54 - not supported by hardware).

> I'm not saying this is the best way, it's one way.
> The wireless tools have (at least partially) input parsing.

> I think a bit more thought is necessary for the setting of
> basic and extended rates. For instance, check what
> happens to basic/extended rates when setting the profile
> to the various values 0 - 7; interesting.

I will experiment with it.

> As an aside, I don't think the current set_rate in the driver
> is correct. To lock on to a fixed rate, it appears we should be
> doing something with DOT11_OID_ALOFT_FIXEDRATE;
> I haven't worked out how to manipulate that oid yet.

Heh. There's tons of those oids, and no docs...
What _ALOFT_ means, btw?

> Margit
>
> Margit
>
> Margit

Oh no, multiple Margits ;)
--
vda



More information about the Prism54-devel mailing list