> I'm not fond of the -wifi thing -- scanning, connecting, disconnecting
> and displaying current status are all fairly generic sounding tasks. I
> could see connect/disconnect/show being applicable to point-to-point
> interfaces, for example, but also for some future wired technology that
> requires login to the network at the link-layer, through EAP, say.
This is true -- and we discussed this internally. However, while the
"verbs" are the same:
* The options will be different and often non-overlapping for
the different scenarios. For instance, the -e, -i, -a, -b,
and -m options to connect are WiFi-specific.
* The behavior will often be quite different. For instance,
would we expect a sequence of "discovery -> filtering ->
prioritization -> association" make sense for "connect" on
a wired link?
* The above two bullets mean that the documentation (especially
the manpages) will necessarily grow in complexity. We need
to introduce such complexity with care.
That said, if it later turns out that it makes sense to generalize these
subcommands, we can do that -- and the *-wifi subcommands would
effectively turn into wrappers around those generalized subcommands.
> > (Nit) can any extant wifi hardware talk to multiple ESSIDs (or, indeed
> > frequencies)?
>
> If so, couldn't/shouldn't multiple ESSIDs be modelled as virtual
> interfaces?
If you mean (IP) logical interface, I don't think that's right. For
instance, in order to track them individually via 802.1x, we'd need to
have them be distinct at the link layer.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
