Nicolas Williams wrote:
> On Wed, May 30, 2007 at 12:30:47AM +0200, Casper.Dik at Sun.COM wrote:
>
>>> For 802.11 (mac_wifi type devices), its not entirely clear what is most
>>> desirable. We have SSID, security information (WEP/WPA, open/shared-key
>>> auth -- though nobody should ever use shared-key), 802.11 "mode"
>>> (802.11b/802.11g, 802.11a), Infrastructure vs. Adhoc, frequency/channel,
>>> current rate (though that can change at any time). Additionally, even
>>> the notion of associated/authenticated is a bit muddied by 802.11.
>>>
>>> What I'd like to do is leave the other non-802.3 messages as just "link
>>> up", with no further details.
>>>
>> What I found usable when working on wifi drivers were message of
>> the form:
>>
>> linkup, X% signal strange, ESSID="XXXX"
>>
>> each type of link has its own significant information.
>>
>
> Agreed. But presumably the log message for wireless NIC state change
> shouldn't be issued for every signal strength change! Just when signal
> strength goes aboe zero (link up) or down to zero (link down).
>
> And NWAM might not want to try to do things just because the link on a
> wireless interface went down -- I may be walking somewhere and be back
> within range of a base station soon.
>
> I agree that the base station ID is useful to have in these messages.
>
> OT:
>
> What about the little button that some systems (laptops, mostly?) have
> to enable/disable wireless? How should Solaris deal with that? Because
> if I turn off wireless then I definitely want NWAM to do something about
> that, but if signal strength temporarily falls to zero then I probably
> don't want NWAM to do anything about that. So mapping both, that button
> and signal strength to link up/down status is probably a bad idea.
>
OMG. This whole conversation degenerates into a rathole into which I
never desired descend.
Currently, in my gate, I _only_ log to syslog when a link state
transitions as reported to the mac layer (and ultimately to the layers
above it.) This means those transitions that _might_ trigger an
upstream action (say, NWAM or IPMP actions) are logged. Change of
speed/duplex settings, WEP keys, BSSIDs, etc. are all simply not
interesting to most of those tools. And if they are, then they should
darn well not be using syslog to get at it.
I'm now wishing that I'd never ever undertaken to clean any of this up.
As always, one cannot make everyone happy; and in this case I'm not even
sure that I can make _anyone_ happy. One of these days I'll learn to
quit tilting at windmills....
I wanted to clean up all the inconsistencies, wasteful logging, and
simplify device drivers. Instead we've degenerated into conversations
about politics at customer sites, commitment levels, and what is worthy
of logging.
The fact is that syslogs are HUMAN consumable. NOBODY should be
depending upon their contents. Especially since we've had reasonable
kstats and ndd for this stuff since at least Solaris 8. The very fact
that a message is logged at all is just a courtesy, which is useful for
the cases where someone plugs/unplugs a network, etc. I agree
wholeheartedly with a link state change message.
Anyway, I'm done arguing about this.
Right now, the whole case was intended to be a volunteer effort to clean
this crap up. Apparently some folks prefer to actually have the
inconsistent crap, rather than use a real programmatic interface.
I am going to flatly refuse to implement any of the 802.11 extended link
information, or even consider anything except up/down in the logs for
802.11. If someone else wants to do it, they can take over the case
and the effort ... its not worth my effort.
I'll leave the PSARC case as it stands for now. If I get some kind of
consensus from PSARC that it is worth doing then I'll commit what I
have. Otherwise I give up.
-- Garrett
