> - You mention upcoming wireless technologies (e.g. WiMAX).
> Is it wise to nail the explicit word "wifi" into the subcommand
> names {scan,connect,show,disconnect}-wifi?
We spent quite a few hours discussing internally, and ultimately decided
that there really wasn't anything better. Suggestions welcome -- but note
that it must satisfy the following requirements:
* Easy to type (e.g., "connect-802.11" is painful)
* Obvious (e.g., "connect-11" is too obscure)
* Accurate (e.g. "connect-wireless" is too general and too long)
> Could the project be used, e.g. for access to data-networking on
> cable?
Not the *-wifi subcommands. The rest of the subcommands are intended to
be general.
> - It seems that you're conflating the concepts of the device used
> to access the channel, and the data-link channel itself, by
> modeling the selection of the channel (wifi channel number plus
> ESSID) as properties attached to the major identifier used by
> dladm (the link name).
>
> I'm concerned that the implied semantics of "a data link" which in
> the wifi case, to me, means the channel defined by [frequency, ESSID]
> are being obscured. The labeling confusion might give rise
> to higher support costs. There are potentially multiple data-links
> available at one time.
I don't follow. A data link is defined by its name, and may optionally be
connected one network. The binding of a data link to a specific channel
and ESSID occurs at connect-wifi time, and is not persistent.
> (Nit) can any extant wifi hardware talk to multiple ESSIDs (or, indeed
> frequencies)?
If the hardware supported such a thing, then the driver would create
multiple dev_info_t's and end up with multiple links names, each of which
could be separately connected.
> Was any consideration given to alternate models?
The one that we discussed the most was the existing wificonfig model --
section 2.9 summarizes the differences and rationale.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
