Garrett D'Amore wrote:
> Bart Smaalders wrote:
>> I'm sponsoring the attached open fasttrack for myself. I'm
>> looking for minor release binding and the case times out
>> 6/13/2007.
>>
>> - Bart
>>
> I don't have any experience with wireshare, although I used ethereal not
> too long ago.
>
> I have a few questions, though.
>
> 1) a lot of files seem to be needed for /usr/sbin {wireshark, editcap,
> capinfos, text2pcap, tshark, mergecap, dumpcap}. Is it likely that an
> admin is going to want to use all of these? I'm just wondering about
> "pollution" of the namespace in /usr/sbin. Are these separate programs,
> or just hardlinks to the same file? Would it make sense to either
> deliver some of these in a different directory (/usr/lib?
> /usr/wireshark? I don't know) or (if they are all hardlinks to the same
> file activated by switching on argv[0]) rely on a command line switch to
> select behavior?
>
All of the commands above have man pages and are usable by
administrators. If one primarily uses Wireshark (the gui),
the others may languish used. However, for command line purists and
those writing shell scripts tshark and friends will be useful.
> 2) are all the tools only applicable/useful for system administrators?
> does it make sense to offer the wireshark binary (and maybe tshark) in
> usr/bin instead of /usr/sbin?
>
If someone would like to clearly state the policy, I'll be happy (absent
the sort of technical issues that arose in the nmap case) to follow
it. Last time, the nmap case was derailed into a full review largely
over the /usr/sbin vs /usr/bin controversy. In order to capture
packets, wireshark needs the same privs. as snoop; given the presence of
snoop in /usr/sbin and the strong similarity in functionality it seems
logical to place wireshark in /usr/sbin as well. Basically, I don't
have any strong feelings one way or the other.
> 3) i presume wireshark can deal with files captured by snoop(1m)?
> Either way, it should be called out in the case materials, I think.
>
Yes. From the wireshark man page (page 1):
capture format
* libpcap, tcpdump and various other tools using tcpdump's
* snoop and atmsnoop
* Shomiti/Finisar Surveyor captures
* Novell LANalyzer captures
* Microsoft Network Monitor captures
* AIX's iptrace captures
* Cinco Networks NetXRay captures
* Network Associates Windows-based Sniffer captures
(compressed or uncompressed) captures
* Network General/Network Associates DOS-based Sniffer
EtherPeek/TokenPeek/AiroPeek/EtherHelp/PacketGrabber captures
* AG Group/WildPackets
* RADCOM's WAN/LAN analyzer captures
* Network Instruments Observer version 9 captures
* Lucent/Ascend router debug output
* files from HP-UX's nettl
* Toshiba's ISDN routers dump output
* the output from i4btrace from the ISDN4BSD project
* traces from the EyeSDN USB S0. Detection System
* the output in IPLog format from the Cisco Secure Intrusion
* pppd logs (pppdump format)
* the output from VMS's TCPIPtrace/TCPtrace/UCX$TRACE utilities
* the text output from the DBS Etherwatch VMS utility
* Visual Networks' Visual UpTime traffic capture
* the output from CoSine L2 debug
* the output from Accellent's 5Views LAN agents
* Endace Measurement Systems' ERF format captures
* Linux Bluez Bluetooth stack hcidump -w traces
* Catapult DCT2000 .out files
There is no need to tell Wireshark what type of file you are
reading; it will determine the file type by itself.
Wireshark is also capable of reading any of these file
formats if they are compressed using gzip. Wireshark
recognizes this directly from the file; the '.gz' extension
is not required for this purpose.
> I don't know what the dominant practice in other FOSS distros, so I'd be
> interested hear about that, too.
>
Wireshark (and friends) install by default into /usr/bin, but will
happily work in /usr/sbin as well. I'll take a look at what other
systems do...
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
