On Wed, 11 Jan 2006 10:05:19 -0500, Mike Kershaw wrote:
> > - 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.
The card should not send any frame when it is down. So the initial mode
doesn't matter.
> 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:
See below.
> > (*) 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.
Because all of frames need to go through the master device. So frames
will be transmitted/received only when the master device is up. You have
two possibilities:
1. To have a "physical" master device with no functionality (like you
proposed). It's just hanging there and its purpose is obscure for an
user. It's confusing for him - the master device is not usable at all,
it is just present in list produced by ifconfig and it gets up and down
randomly by itself (or, the worst case, you have to up it manually to
let your wifi work).
2. To have one special device that cannot be removed. It acts exactly
like devices in my proposal, but you can't remove it. It doesn't work -
you have to have this device up, otherwise your wifi device won't
send/receive anything (imagine this situation: add_new_iface wlan0 wlan1
; iwconfig wlan1 mode managed ; ifconfig wlan1 up -- oops, I have my
card configured properly but it doesn't work).
In the second case you still need to select master device dynamically.
It has the "advantage" that you can pass struct net_device to a driver
(because you have one that cannot be removed). But if you look closer,
it is not an advantage at all - the driver is still not allowed to do
anything useful with that net_device (because most operations need to be
performed on several net_devices so you need ieee80211 to do this for
you anyway).
Regarding your comment about "control" interface moving around: there is
nothing like control iterface. You can issue any command on any
interface. When the command is a "local" one, it gets applied to that
interface only, when it is a "global" one, it gets applied to all
interfaces. In fact, every interface is a control interface. Migration
of master device is not visible to userspace.
> Tracking down what interface is still mapped to
> what phy in a multicard situation seems like it would make a much bigger
> hassle.
I think some userspace helper (small program that just nicely presents
information from sysfs) that outputs which device is related to which
device will solve this.
> So long as the driver can do client-mode bridging with fake associations
> for all the clients.
Or the stack perhaps?
> 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. :)
I think radiotap headers should be included when the interface is in
monitor mode.
Thanks a lot for your comments,
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
