On Wed, Mar 08, 2006 at 11:39:55AM -0500, [EMAIL PROTECTED] wrote: > > > 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.
But you can always tell from context, from the interface name, which options should apply. > * 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? I think we might, yes. Consider a putative Ethernet + VLAN + EAP technology, and imagine a network that offers two VLANs, one being SWAN and requiring user authentication, and the other being an open connection to the Internet, for guests, say. Then we might have multiple networks to discover. I could see the same for point-to-point links, though that seems much less likely; but at least connect/disconnect/show are applicable to p2p links. Today, of course, these verbs apply only to wireless networking, which also seems to make the -wifi obnoxious: it's obvious and redundant. > * 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. Yes, but the thing I dislike about wificonfig is redundancy in its command-lines, particularly around parameter get/set. I'd hate to see more redundancy here. > > > (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. I meant something fuzzier; I meant "virtual interface" as in having multiple interface names that can be used with ifconfig/dladm but each intended for different ESSIDs/VLANs/whatever logical network notion. So, yes, a virtual interface at the link layer. Or maybe not -- as long as at the IP interface level we can keep separate networks on the same NIC separate. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
