[Prism54-devel] handle mgmt timeouts by resetting hardware
Margit Schubert-While
margitsw at t-online.de
Tue Aug 10 16:27:48 UTC 2004
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 ?
>> 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.
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.
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.
Margit
Margit
Margit
More information about the Prism54-devel
mailing list