found 154367 30~pre9-8
tags 154367 + patch
quit
Seems this issue had been noticed long before I was worrying about the
situation. In my case I'm dealing with a device that has multiple
drivers which implement slightly varying interfaces and so having both
sets of tools available is kind of useful (until one or more of them
completely supports this hardware).
May I suggest the following patch to the wireless-tools ifupdown script:
--- wireless-tools.orig 2016-03-23 13:01:11.000000000 -0700
+++ wireless-tools 2016-03-23 13:07:44.000000000 -0700
@@ -6,6 +6,23 @@
exit 0
fi
+# check if this is a 802.11 device we're supposed to be effecting
+case "${IF_WIRELESS:-enable}" in
+ wireless-tools|iwconfig)
+ # *we* and not some other 802.11 tool should be used
+ ;;
+ true|yes|enable|1)
+ # 802.11 should be used on this device, check for extensions
+ $IWCONFIG $IFACE >/dev/null 2>&1 || exit 0
+ ;;
+ *)
+ exit 0
+ ;;
+esac
+
# The wireless driver madness:
#
# - Some drivers want everything to be configured before bringing the
interface up
This is similar to what Joey Hess was originally suggesting, but knowing
some devices may not readily distinguished in a scriptable way, simply
allow choosing the tool with a command. Since wireless-tools is the
elder tool, default to using iwconfig if the wireless extensions are
present. If a device had multiple tools, allow explicit selection in the
configuration.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | [email protected] PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
