wiconfig(8) and non-wi(4) 802.11 drivers

[Taylor R Campbell]

Hello! I'd like to use some of the functionality offered by
wiconfig(8), but for drivers other than wi(4). (More specifically,
I'd like to implement some of its knobs in bwi(4).) I examined the
implementation of wiconfig(8), and it seems awfully specific to the
design of the wi(4) hardware. Is it worth my time to emulate the way
that wi(4) looks, implementing the SIOCGIFGENERIC and SIOCSIFGENERIC
ioctls with struct wi_req buffers; or will this be changing to
something more generic in the kernel's 802.11 support?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Taylor R Campbell
Hello! I'd like to use some of the functionality offered by
wiconfig(8), but for drivers other than wi(4). (More specifically,
I'd like to implement some of its knobs in bwi(4).) I examined the
implementation of wiconfig(8), and it seems awfully specific to the
design of the wi(4) hardware. Is it worth my time to emulate the way
that wi(4) looks, implementing the SIOCGIFGENERIC and SIOCSIFGENERIC
ioctls with struct wi_req buffers; or will this be changing to
something more generic in the kernel's 802.11 support?

It is not worth your time to emulate wi(4). wiconfig(8) is overdue to
be deleted. Some people depended on it to do some thing that ifconfig(8)
now does, such as change the MAC address. (Perhaps people still use it
to fiddle with the "authentication mode", too? It should be easy enough
to support that in ifconfig(8).)

What wiconfig(8) functions do you need for bwi(4)?

Dave

[der Mouse]

Post by David Young
It is not worth your time to emulate wi(4). wiconfig(8) is overdue
to be deleted. Some people depended on it to do some thing that
ifconfig(8) now does, such as change the MAC address. (Perhaps
people still use it to fiddle with the "authentication mode", too?
It should be easy enough to support that in ifconfig(8).)

Surely we should be moving things _out of_, not _into_ ifconfig? It
already has way too many special cases that belong in per-device config
programs (eg, the vlan and vlanif keywords, which exist solely for
vlan(4) and which really belong in a vlanconfig of some sort).

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Taylor R Campbell]

Sorry, I forgot to mention: I'm not subscribed to this list, so
please cc me in replies.

Initially I wanted to use the microwave oven mode to tweak some flags
in bwi(4), but I realize now that that wouldn't make much sense. I
don't think there's anything remaining of interest to me for bwi(4),
but this does bring up the question of what should substitute for
wiconfig(8), whether the ioctl/wi_req interface should change, and
whether NetBSD is waiting for someone to do the substitution and
changes. It might be ifconfig(8), still using the same ioctl/wi_req
interface; any other thoughts?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Barrett]

Post by der Mouse
Surely we should be moving things _out of_, not _into_ ifconfig? It
already has way too many special cases that belong in per-device config
programs (eg, the vlan and vlanif keywords, which exist solely for
vlan(4) and which really belong in a vlanconfig of some sort).

I believe that the current thinking is along the lines of "If it has
anything to do with configuring a network interface, then ifconfig
should do it". So ifconfig can tell a vlan what physical interface to
use, can tell various tunnel interfaces what outer addresses and/or
ports to use, can tell various radio interfaces what channels and/or
ssids to use, etc.

I rather like being able to use "ifconfig ${ifname} ssid ${ssid}"
regardless of whether my radio interface is wi, wpi, ipw, iwi, etc.

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Taylor R Campbell
Sorry, I forgot to mention: I'm not subscribed to this list, so
please cc me in replies.
Initially I wanted to use the microwave oven mode to tweak some flags
in bwi(4), but I realize now that that wouldn't make much sense. I
don't think there's anything remaining of interest to me for bwi(4),
but this does bring up the question of what should substitute for
wiconfig(8), whether the ioctl/wi_req interface should change, and
whether NetBSD is waiting for someone to do the substitution and
changes. It might be ifconfig(8), still using the same ioctl/wi_req
interface; any other thoughts?

Taylor,

For getting/setting IEEE 802.11 parameters, you should use the
SIOC[SG]80211* ioctls, exclusively.

I may be able to help you better if you say more about what you want
to accomplish. For example, what are the bwi(4) parameters that you
want to adjust?

ifconfig(8) should substitute for wiconfig(8). Where ifconfig(8) is
lacking in the 802.11 department, we are still waiting for somebody to
make the changes.

Dave

[Roy Marples]

Post by Alan Barrett

Post by der Mouse
Surely we should be moving things _out of_, not _into_ ifconfig? It
already has way too many special cases that belong in per-device config
programs (eg, the vlan and vlanif keywords, which exist solely for
vlan(4) and which really belong in a vlanconfig of some sort).

I believe that the current thinking is along the lines of "If it has
anything to do with configuring a network interface, then ifconfig
should do it". So ifconfig can tell a vlan what physical interface to
use, can tell various tunnel interfaces what outer addresses and/or
ports to use, can tell various radio interfaces what channels and/or
ssids to use, etc.
I rather like being able to use "ifconfig ${ifname} ssid ${ssid}"
regardless of whether my radio interface is wi, wpi, ipw, iwi, etc.

One of the main attraction of BSD is that ifconfig does everything -
it's all in the man page nicely documention.

On Linux you have to play "guess the tool" to get the right man page.
Even then, you are lost as the new bridging configuration is done by
toggling stuff in /sys (sysfs) which has no man page so eventually
you'll just have kernel documentation.

However, the ifconfig tool should be modular enough to add and remove
stuff from it.

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Roy Marples
However, the ifconfig tool should be modular enough to add and remove
stuff from it.

Not too long ago, I did a lot of work to make it modular.

Dave