James Carlson wrote: > Bart Smaalders writes: >>> So, what's the plan for snoop? Does it get removed eventually? >>> >> That's a possibility. The maintainers of snoop can make that choice. >> It might make more sense to enhance wireshark rather than to expend the >> effort needed to update snoop periodically. > > It would make a lot more sense to enhance wireshark ... but it also > means we have an at best confused approach to our own system > architecture because we don't have an agreement about what we're > actually doing. >
Well, depriving our customers of the better tool while we go on about architectural direction doesn't exactly enhance Solaris. Some degree of duplication/competition between tools is useful. I realize that this can confuse customers somewhat... but introducing this into Nevada seems to be a useful first step in making a decision. Wireshark/Ethereal has been around for year. >>> It doesn't seem good for users to be bounced back and forth between >>> two different tools to do the same job. >>> >> There's really more of a conflict between tshark and snoop; both are >> cmdline network packet analyzers. Wireshark is a pretty complete, >> functional GUI. The wireshark set of tools seems more complete to >> me, but I'm no networking expert. > > No, there's a conflict in both. > > Tshark and snoop conflict because they're both command line tools that > extract packet data. Wireshark conflicts because, although it decodes > most protocols you'd want to see, nobody's actually looked to see > whether it decodes all the odd things we've added to snoop over the > years, or if it should. We're potentially forcing users to jump back > and forth, rather than just committing to a good answer. > > For instance, does it decode labels for TX? (Last I looked, the > answer was "no," but that someone at HP was trying to work on a patch > for it.) > I'm hard pressed to find the list of decoded protocols in the snoop documentation. >>>> There are two private libraries delivered into /usr/lib. >>> I don't see libpcap. Where does that come from? >>> >> I'm statically linking that into wireshark; it doesn't really want >> (eg easily) build a dynamic version OOB. Until such time as we have >> additional clients, static linking saves effort. > > That's odd. Blastwave didn't seem to have a problem with it. > > It's likely an interesting issue because the Clearview team intends to > contribute changes to libpcap to make it work with their /dev/ipnet/ > interfaces. See PSARC 2006/475. > > It'd be a shame if the wireshark we ship doesn't work right with the > brand new monitoring interfaces we ship. > When libpcap gets updated, we'll grab a newer copy. We have to do that whether or not it gets statically or dynamically linked. If someone else introduces a dynamic libpcap, we can use that easily enough. Right now w/ only one client it really doesn't add any value. >>> I see a seriously large number of libraries used by blastwave's >>> ethereal. Are the same ones dragged in here? If so, where are they? >>> If not, then is there functionality missing from the Solaris SFW >>> version? Any features disabled? >>> >> Here's the DTNEEDED entries from /usr/sbin/wireshark: > > Have you tried to figure out what things are stable? For instance, > libkstat itself is stable, but the kstats themselves often are not. > > In other words, what guarantees do we have (if any) that this software > will continue to operate as the system changes? We'll have to debug any problems that arise. It turns out the kstat dependencies went away after I used the -zignore option; they were introduced by libtool (bletch). > OK. Should we just not support developers, or would those bits be > more effective as separate packages? > My thoughts are that anyone wishing to add to wireshark in the form of plugins, etc, will probably grab the source and compile it themselves, so shipping the development tools is probably not terribly useful. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
