also sprach Enrico Zini <[EMAIL PROTECTED]> [2006.09.23.1703 +0200]: > I'm now hiding those warnings unless guessnet is run with --verbose. > What is needed, is a better handling of the return value of the > function, to distinguish between inavailability of the feature or link > beat status.
Absolutely. I'd claim that in the presence of only true/false,
missing-cable should "fail" (thus pretending that there's a link) in
case the feature is not supported.
Also:
< enrico> madduck: I'll tell you again: missing-cable IS supported
in your case
< madduck> aha.
< enrico> madduck: it is supported using the wlan test, which checks
if you're associated with an AP
< enrico> madduck: that's what I found a few minutes ago
< madduck> but i am *not* yet associated. don't forget that
wpasupplicant took a 180 degree turn
< madduck> also, wireless-tools ifupdown integration will only
associate *after* guessnet.
< madduck> which wlan test do you mean? the guessnet wlan test, or
the link beat wlan test?
< madduck> i store the wlan parameters like essid and psk in the
configuration stanza
< madduck> so i cannot be associated before guessnet identifies
which stanza to use
< madduck> using iwlist scan and pattern matching
< madduck> now i read you...
< madduck> in this case i'd go as far as claiming that the wlan link
beat test is doing the wrong thing when guessnet+ifupdown
is used on debian.
< madduck> because in all constellations that i know, the
association happens as part of the ifup post-processing.
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
