On Wed, Jan 11, 2006 at 03:49:37PM +0100, Jiri Benc wrote: > Here is my proposal: > > - There should be only as few net_devices as needed. I. e. when the card > acts as a client to one AP, only one device is present.
See below...
> - The type of a device (AP, client, WDS link, monitor, etc.) should be
> specified in the usual way (by iwconfig mode or whatever will eventually
> replace it).
Agreed, though there is a benefit to being able to specify the type of
the initial card. Many drivers offer it as a modprobe option, ie, to
initialize the card in rfmon to prevent it from sending any probe req's
before configuration. A bit of a fringe IDS aspect, but I don't know if
we ought to cut them out. Does anyone actually USE this functionality?
I don't, myself, but I know it exists.
> - When you need a new device (e. g. because you want to connect to another
> AP at the same time, or you want to add a new WDS link), you just invoke
> some command and a new device will appear. Then you can configure the new
> device in the usual way (iwconfig mode, etc.)
Sounds good.
> - Devices can be deleted. You can delete any device (including the first one
> that appeared after modprobe/inserting the card (*)). Of course, you
> cannot delete the last device (i. e. at least one device will be always
> present).
I don't know if I concur -- having the "control" interface move around
is confusing. I'd rather have one unique ID for that wireless phy
(however this is presented) and then create dynamic devices from it via
whatever command. Atheros ties this to a master wifiX device that is
uses to spawn dynamic devices. It just seems that, logically, it makes
more sense to have something like:
wlanadddev phy0 dyn0
wlanadddev phy0 dyn1
wlanadddev phy1 dyn2
wlandeldev dyn1
wlandeldev dyn2
wlanmakedev phy1 dyn1
rather than have the 'source' phy change over time.
> - "Global" configuration requests (setting channel etc.) can be performed on
> any device and will affect all devices.
Yup.
> - "Local" configuration requests (setting mode, ESSID, etc.) will affect
> only the device they are called on.
Yup.
> - You can add as many devices as you want and configure them in any way. But
> only devices that are "compatible" (i. e. the hardware permits them to
> operate together) can be brought up.
Sounds good, provided the error is reasonable. Reasonable presentation
of the error is, admittedly, more userspace than kernel space, but since
we're talking about designing new uspace tools...
>
> *snip*
>
> (*) At first, I was thinking that the first device ("master device")
> shouldn't allow to be deleted. But it doesn't solve anything (don't want to
> make this mail longer; ask me if you want to know why) and just confuses
> users.
I'd like to know why. :) See above for my counter-argument about
confusing users. I'd be willing to agree that the control phy "master
device" doesn't need to be a netdev, but I think it ought to be a
constant, unique value. Tracking down what interface is still mapped to
what phy in a multicard situation seems like it would make a much bigger
hassle.
> *snip*
> There are two problems regarding native 802.11 devices:
>
> 1. Bridging between Ethernet and 802.11 device. Ethernet<->802.11 conversion
> can be implemented in the bridging code. There should be no problem with it.
So long as the driver can do client-mode bridging with fake associations
for all the clients. Or the interface is in AP mode.
> ... *snip*
As far as link type, theres no real reason radiotap couldn't be used
internally, but theres also no reason it's needed on anything other than
rfmon if we don't think we'll ever care about per-frame stats in
non-rfmon. I don't think anyone has written any tools to use them,
since it hasn't been an option. I don't know that theres a lot of
demand. Rfmon *definitely* needs standard per-frame headers of radio
data, and I've campaigned for RT previously so i won't bore people with
it again now. :)
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
America is a large, friendly dog in a very small room. Every time it
wags its tail, it knocks over a chair.
-- Arnold Joseph Toynbee
pgpPfHqX9Kh4w.pgp
Description: PGP signature
