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. > > 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.) > >> 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. > > 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? > [9] NEEDED 0xfd9b libadm.so.1 Really? That's weird. > [10] NEEDED 0xfda7 libcrypto.so.0.9.8 OpenSSL, I think. > [16] NEEDED 0xfe09 libmlib.so.2 That one is pretty weird, too. > [23] NEEDED 0xfcd1 libpthread.so.1 > [24] NEEDED 0xfcea libthread.so.1 I don't think those do anything. > [11] NEEDED 0xfdba libgtk-x11-2.0.so.0 > [12] NEEDED 0xfdce libgdk-x11-2.0.so.0 > [13] NEEDED 0xfde2 libatk-1.0.so.0 > [14] NEEDED 0xfdf2 libgdk_pixbuf-2.0.so.0 > [17] NEEDED 0xfe16 libpangocairo-1.0.so.0 > [18] NEEDED 0xfe2d libpango-1.0.so.0 > [19] NEEDED 0xfe3f libcairo.so.2 > [20] NEEDED 0xfe4d libgobject-2.0.so.0 > [21] NEEDED 0xfe61 libgmodule-2.0.so.0 > [22] NEEDED 0xfe75 libgthread-2.0.so.0 > [25] NEEDED 0xfe89 libglib-2.0.so.0 > [26] NEEDED 0xfe9a libgnutls.so.12 > [27] NEEDED 0xfeaa libgcrypt.so.11 > [28] NEEDED 0xfeba libgpg-error.so.0 No idea about those. > I'm going over the list w/ Dermot; there are a couple for which I'll > need contracts. When libpcre integrates, that will appear in the above > list as well. I also need contracts w/ Darrin for the crypto libraries. > I've disabled building 3 components (dftest, randpkt, and idl2wrs) as > these are better suited to Wireshark plugin developers than to a general > purpose tool. OK. Should we just not support developers, or would those bits be more effective as separate packages? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
