From jw137282@sac.sfbay.sun.com Tue Mar 3 01:28:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n239SIpT011725 for ; Tue, 3 Mar 2009 01:28:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n239SBlh031411; Tue, 3 Mar 2009 02:28:18 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFX0081LBN48J00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Mar 2009 01:28:16 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFX00HW1BN43E50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Mar 2009 01:28:16 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n239SFhZ037473; Tue, 03 Mar 2009 01:28:15 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n239SEiv011719; Tue, 03 Mar 2009 01:28:14 -0800 (PST) Received: (from jw137282@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n239SEdc011715; Tue, 03 Mar 2009 01:28:14 -0800 (PST) Date: Tue, 03 Mar 2009 01:28:14 -0800 (PST) From: James Walker Subject: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] To: PSARC-ext@sun.com Cc: robin.guo@sun.com Message-id: <200903030928.n239SEdc011715@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 12575 I'm sponsoring this familiarity case for Robin Guo. The requested release binding is minor. The man page has been posted in the materials directory. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: tcpdump 1.2. Name of Document Author/Supplier: Author: Robin Guo 1.3 Date of This Document: 03 March, 2009 4. Technical Description 1.0 Project Information 1.1 Name of project/component tcpdump 1.2 Author of document robin.guo@sun.com 2.0 Project Summary 2.1 Project Description Tcpdump is a common packet sniffer that runs under the command line. It allows the user to intercept and display TCP/IP and other packets being transmitted or received over a network to which the computer is attached. Tcpdump works on most Unix-like OS, and uses libpcap library to capture packets. tcpdump 4.0.0 will be integrated into the SFW consolidation as part of this proposal, and will be installed as SUNWtcpdump. A minor release binding is being requested. 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [*] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Type of project Is this case a Linux Familiarity project? [*] Yes [ ] No 2.4 Originating Community 2.4.1 Community Name tcpdump.org 2.4.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [*] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [*] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [*] No 3.0 Technical Description 3.1 Installation & Sharable 3.1.1S Solaris Installation - section only required for Solaris Software (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [*] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [*] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [*] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [*] No or N/A Do any of the components of this project conflict with anything under /usr? (see http://opensolaris.org/os/community/arc/caselog/2007/047/ for details) [ ] Yes - explain below [*] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [*] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [*] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) Does this project install software into a :\Program Files\Sun\ or :\Sun\ directory? [ ] Yes [ ] No - ARC review required Does the project use the Windows registry? [ ] Yes [ ] No - ARC review required Does the project use HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ for the registry key? [ ] Yes [ ] No - ARC review required Is the project's stored location HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? [ ] Yes [ ] No - ARC review required 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [*] No If yes are these components packaged to be shared with the other FOSS? [ ] Yes [ ] No - ARC review required [*] N/A Are these components already in the Solaris WOS? [ ] Yes [*] No - continue with next section (section 3.2) If yes are these newer versions being delivered? [ ] Yes [ ] No - ARC review required If yes are the newer versions replacing the existing versions? [ ] Yes [ ] No - ARC review required 3.2 Exported Libraries Are libraries being delivered by this project? [ ] Yes [*] No - continue with next section (section 3.3) Are 64-bit versions of the libraries being delivered? [ ] Yes [ ] No - ARC review required Are static versions of the libraries being delivered? [ ] Yes - ARC review required [ ] No 3.3 Services and the /etc Directory (see http://opensolaris.org/os/community/arc/policies/SMF-policy/) Does the project integrate anything into /etc/init.d or /etc/rc?.d? [ ] Yes - ARC review required [*] No Does the project integrate any new entries into /etc/inittab or /etc/inetd.conf? [ ] Yes - ARC review required [*] No Does the project integrate any private non-public files into /etc/default or /etc/ configuration files? [ ] Yes - ARC review required [*] No Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [*] No 3.4 Security 3.4.1 Secure By Default (see http://opensolaris.org/os/community/arc/policies/secure-by-default/ for details) (see http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ for details) (see parts of http://opensolaris.org/os/community/arc/policies/SMF-policy/ for addtional details) Are there any network services provided by this project? [ ] Yes [*] No - continue with the next section (section 3.4.2) Are network services enabled by default? [ ] Yes - ARC review required [ ] No [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [ ] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [ ] N/A 3.4.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes - ARC review required [*] No - continue with next section (section 3.4.3) If yes then are the setuid/setgid privileges handled by the use of roles? [ ] Yes [ ] No - ARC review required 3.4.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Does this component contain administrative or security enforcing software? [ ] Yes - ARC review required [*] No - continue to next section (section 3.4.4) (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes - ARC contract and Audit project team review required [ ] No - ARC review required 3.4.4 Authentication (see http://opensolaris.org/os/community/arc/policies/PAM/) Do the components contain any authentication code? [ ] Yes [*] No - continue to next section (section 3.4.5) If yes do the components use PAM (plugable authentication modules) for authentication? [ ] Yes [ ] No - ARC review required If yes is a single PAM session maintained during authentication? [ ] Yes [ ] No - ARC review required If yes are the components sufficiently privileged to allow the requested operations (authentication, password change, process credential manipulation, audit state initialization)? [ ] Yes - briefly describe below [ ] No - ARC review required 3.4.5 Passwords (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details) Do any of the components for the project deal with passwords? [ ] Yes [*] No - continue to next section (section 3.4.6) If yes are these passwords entered via the CLI or environment? [ ] Yes - ARC review required [ ] No Are passwords stored within the file system for the component? [ ] Yes [ ] No - continue to next section (section 3.4.6) If yes are the permissions on the file such to protect exposing the password(s)? [ ] Yes [ ] No - ARC review required 3.4.6 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Are there any network protocols used by this project? [*] Yes [ ] No - continue with the next section (section 3.5) Do the components use standard network protocols? [*] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [ ] No [*] N/A Do the components make use of secret information during authentication and/or authorization? [ ] Yes - explain below [ ] No [*] N/A 3.5 Networking Do the components access the network? [*] Yes [ ] No - continue with the next section (section 3.6) If yes do the components support IPv6? [*] Yes [ ] No - ARC review required 3.6 Core Solaris Components Do the components of this project compete with or duplicate core Solaris components? [ ] Yes - ARC review required [*] No Examples of Core Solaris Components include but are not limited to: Secure By Default Authorizations PAM -- Plugable Authentication Module Privilege PRM -- Process Rights Management -- Privilege Audit xVm -- Virtualization zones / Solaris Containers PRM -- Process Rights Management RBAC -- Role Based Access Control TX / Trusted Extensions ZFS SMF -- Service Management Facility FMA -- Fault Management Architecture SCF -- Smart Card Facility IPsec 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments --------------------------- -------------- ----------------------- SUNWtcpdump Uncommitted Package /usr/bin/tcpdump Uncommitted Executable binary file 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- --------------- -------------------------- SUNWlibpcap Uncommitted Package SUNWlibsasl Committed Package SUNWpr Committed Package SUNWtls Uncommitted Package SUNWlibmsr Committed Package Appendix A - References [1] http://www.tcpdump.org OSR ID# 9923 RFE ID# 6808014 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From ro@techfak.uni-bielefeld.de Tue Mar 3 04:53:41 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23CrfDQ006664 for ; Tue, 3 Mar 2009 04:53:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n23CrcJb023280; Tue, 3 Mar 2009 04:53:39 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFX00M0TL5EXT00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 04:53:38 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFX00DNVL5E9290@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 04:53:38 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23Cpus5007450; Tue, 03 Mar 2009 12:53:37 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-1026035; Tue, 03 Mar 2009 12:53:37 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-176664; Tue, 03 Mar 2009 12:53:34 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-13578430; Tue, 03 Mar 2009 12:53:34 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 28BF048309; Tue, 03 Mar 2009 13:53:34 +0100 (CET) Date: Tue, 03 Mar 2009 13:53:33 +0100 From: Rainer Orth Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: James Walker's message of "Tue, 03 Mar 2009 01:28:14 -0800 (PST)" Sender: ro@techfak.uni-bielefeld.de To: James Walker Cc: PSARC-ext@sun.com, robin.guo@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.130sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 23 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> Status: RO Content-Length: 913 James Walker writes: > 3.4.2 Authorization > (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and > http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ > for details) > Are there any setuid/setgid privileged binaries in the project? > [ ] Yes - ARC review required > [*] No - continue with next section (section 3.4.3) > > If yes then are the setuid/setgid privileges handled by the use of roles? > [ ] Yes > [ ] No - ARC review required Shouldn't tcpdump be added to the Network Management profile in /etc/security/exec_attr, just like snoop is? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From carlsonj@phorcys.east.sun.com Tue Mar 3 05:01:58 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23D1w3K007495 for ; Tue, 3 Mar 2009 05:01:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n23D1tZD026495; Tue, 3 Mar 2009 05:01:56 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFX0021HLJ74200@brm-avmta-1.central.sun.com>; Tue, 03 Mar 2009 06:01:55 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFX00LC7LJ50N30@brm-avmta-1.central.sun.com>; Tue, 03 Mar 2009 06:01:53 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n23D1nux027642; Tue, 03 Mar 2009 08:01:49 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n23D1naL027639; Tue, 03 Mar 2009 08:01:49 -0500 (EST) Date: Tue, 03 Mar 2009 08:01:49 -0500 From: James Carlson Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <200903030928.n239SEdc011715@sac.sfbay.sun.com> To: James Walker Cc: PSARC-ext@sun.com, robin.guo@sun.com Message-id: <18861.10813.92364.822255@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> Status: RO Content-Length: 1111 James Walker writes: > Tcpdump is a common packet sniffer that runs under the command line. > It allows the user to intercept and display TCP/IP and other packets > being transmitted or received over a network to which the computer is > attached. Tcpdump works on most Unix-like OS, and uses libpcap library > to capture packets. What's the point? tcpdump is enough like snoop that it seems to me that there's not a great reason to do this. Instead, it'd be much nicer to see wireshark integrated (which includes a command line tool that's more powerful than either tcpdump *or* snoop), and also have snoop yanked from the product. The time spent here could be better spent elsewhere. > /usr/bin/tcpdump Uncommitted Executable binary file If this just _has to_ be integrated, I think it belongs in /usr/sbin, just like snoop. It's administrative in nature. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Sebastien.Roy@sun.com Tue Mar 3 05:21:01 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23DL0Mx007660 for ; Tue, 3 Mar 2009 05:21:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n23DKwpU007542 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Mar 2009 21:20:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFX0060BMEYWC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 05:20:58 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFX006CUMEWKV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 05:20:56 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23DKuii009414 for ; Tue, 03 Mar 2009 13:20:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFX00300M8WQ100@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 06:20:56 -0700 (MST) Received: from [192.168.1.6] ([unknown] [173.76.18.185]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFX009UEMEVMB60@mail-amer.sun.com>; Tue, 03 Mar 2009 06:20:56 -0700 (MST) Date: Tue, 03 Mar 2009 08:20:54 -0500 From: Sebastien Roy Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <200903030928.n239SEdc011715@sac.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: James Walker Cc: PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <1236086454.1423.38.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> Status: RO Content-Length: 786 On Tue, 2009-03-03 at 01:28 -0800, James Walker wrote: > tcpdump 4.0.0 will be integrated into the SFW consolidation as part of > this proposal, and will be installed as SUNWtcpdump. Doesn't tcpdump 4.0.0 require libpcap 1.0.0? SFW has 0.9.8. As an aside, beware that 1.0.0 doesn't compile on Solaris; I submitted a fix for that upstream that was integrated into the source a few weeks ago, so the next release will be usable. If tcpdump 4.0.0 is in fact dependent on libpcap 1.0.0, then I suspect that this case will either need to have a case dependency on an as-yet-to-be-submitted case to upgrade libpcap to 1.0.x, or include the libpcap 1.0.x in this case. If it's not dependent on libpcap 1.0.0, then please ignore my ramblings. :-) Please specify either way. -Seb From James.Walker@sun.com Tue Mar 3 17:01:27 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2411RXf027317 for ; Tue, 3 Mar 2009 17:01:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2411NM6029744 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Mar 2009 17:01:27 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY0012VIUEKO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 18:01:26 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00H1XIUDYR50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 18:01:25 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2411PwZ026532 for ; Wed, 04 Mar 2009 01:01:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00B00IS28O00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 18:01:24 -0700 (MST) Received: from [172.20.25.153] ([unknown] [172.20.25.153]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY00LEDIUCX1B0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 18:01:24 -0700 (MST) Date: Tue, 03 Mar 2009 18:03:38 -0700 From: Jim Walker Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18861.10813.92364.822255@gargle.gargle.HOWL> Sender: James.Walker@sun.com To: James Carlson Cc: PSARC-ext@sun.com, Robin.Guo@sun.com Reply-to: James.Walker@sun.com Message-id: <49ADD36A.3060708@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 825 James Carlson wrote: > What's the point? > > tcpdump is enough like snoop that it seems to me that there's not a > great reason to do this. Instead, it'd be much nicer to see wireshark > integrated (which includes a command line tool that's more powerful > than either tcpdump *or* snoop), and also have snoop yanked from the > product. > > The time spent here could be better spent elsewhere. > >> /usr/bin/tcpdump Uncommitted Executable binary file > > If this just _has to_ be integrated, I think it belongs in /usr/sbin, > just like snoop. It's administrative in nature. tcpdump is on the top 25 miss list, so I guess someone wants it. The project team will reconsider the target directory and it back to you. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado From Robin.Guo@Sun.COM Tue Mar 3 19:04:01 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24341X8006026 for ; Tue, 3 Mar 2009 19:04:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24341mT020456 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Mar 2009 19:04:01 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY0001ROIOK500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 19:04:00 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00NSOOIL5700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 19:03:58 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2433vuc014210 for ; Wed, 04 Mar 2009 03:03:57 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00G00OAIOE00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:03:57 +0800 (SGT) Received: from [129.158.219.19] ([unknown] [129.158.219.19]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY00G79OIKOA00@mail-apac.sun.com>; Wed, 04 Mar 2009 11:03:57 +0800 (SGT) Date: Wed, 04 Mar 2009 11:03:01 +0800 From: Robin Guo Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <1236086454.1423.38.camel@seb> Sender: Robin.Guo@Sun.COM To: Sebastien Roy Cc: James Walker , PSARC-ext@Sun.COM Message-id: <49ADEF65.40504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <1236086454.1423.38.camel@seb> User-Agent: Thunderbird 2.0.0.18 (X11/20090209) Status: RO Content-Length: 1443 Hi, Sebastien Yes, it should require libpcap 1.0.0 instead, I just checked the changelog of tcpdump 4.0.0, it "Use newer libpcap API's" which refer to libpcap 1.0.0 But I simply not hit problem upon 0.9.8, (maybe not with fully functional testing on libpcap 0.9.8)... Anyway, I agree with the point to use libpcap 1.0.0 Thanks for point out this issue. - Regards, Robin Guo Sebastien Roy wrote: > On Tue, 2009-03-03 at 01:28 -0800, James Walker wrote: >> tcpdump 4.0.0 will be integrated into the SFW consolidation as part of >> this proposal, and will be installed as SUNWtcpdump. > > Doesn't tcpdump 4.0.0 require libpcap 1.0.0? SFW has 0.9.8. > > As an aside, beware that 1.0.0 doesn't compile on Solaris; I submitted a > fix for that upstream that was integrated into the source a few weeks > ago, so the next release will be usable. If tcpdump 4.0.0 is in fact > dependent on libpcap 1.0.0, then I suspect that this case will either > need to have a case dependency on an as-yet-to-be-submitted case to > upgrade libpcap to 1.0.x, or include the libpcap 1.0.x in this case. If > it's not dependent on libpcap 1.0.0, then please ignore my > ramblings. :-) Please specify either way. > > -Seb > > -- Regards, Robin Guo, Xue-Bin Guo Solaris Kernel and Data Service QE, Sun China Engineering and Reserch Institute Phone: +86 10 82618200 +82296 Email: robin.guo@sun.com Blog: http://blogs.sun.com/robinguo From Robin.Guo@sun.com Tue Mar 3 19:16:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n243G5XQ007170 for ; Tue, 3 Mar 2009 19:16:05 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n243G5Oi026766 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Mar 2009 19:16:05 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00M03P2RYK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 19:16:03 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00GOBP2PUY70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 19:16:02 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n243G1aG000187 for ; Wed, 04 Mar 2009 03:16:01 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00700OXNFL00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:16:01 +0800 (SGT) Received: from [129.158.219.19] ([unknown] [129.158.219.19]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY00GP4P2OOA00@mail-apac.sun.com>; Wed, 04 Mar 2009 11:16:01 +0800 (SGT) Date: Wed, 04 Mar 2009 11:15:05 +0800 From: Robin Guo Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18861.10813.92364.822255@gargle.gargle.HOWL> Sender: Robin.Guo@sun.com To: James Carlson Cc: James Walker , PSARC-ext@sun.com Message-id: <49ADF239.70209@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20090209) Status: RO Content-Length: 1557 Hi, James, Sure, I just picked the package porting from the list that not be ported before. That's a good idea about wireshare that I may have interest to take a look in the future. But anyway, the porting for tcpdump had last for a while and I would like to integrate it firstly, the /usr/sbin directory sounds a good idea, and I'll change the install path to there. Thanks. Robin Guo James Carlson wrote: > James Walker writes: >> Tcpdump is a common packet sniffer that runs under the command line. >> It allows the user to intercept and display TCP/IP and other packets >> being transmitted or received over a network to which the computer is >> attached. Tcpdump works on most Unix-like OS, and uses libpcap library >> to capture packets. > > What's the point? > > tcpdump is enough like snoop that it seems to me that there's not a > great reason to do this. Instead, it'd be much nicer to see wireshark > integrated (which includes a command line tool that's more powerful > than either tcpdump *or* snoop), and also have snoop yanked from the > product. > > The time spent here could be better spent elsewhere. > >> /usr/bin/tcpdump Uncommitted Executable binary file > > If this just _has to_ be integrated, I think it belongs in /usr/sbin, > just like snoop. It's administrative in nature. > -- Regards, Robin Guo, Xue-Bin Guo Solaris Kernel and Data Service QE, Sun China Engineering and Reserch Institute Phone: +86 10 82618200 +82296 Email: robin.guo@sun.com Blog: http://blogs.sun.com/robinguo From Robin.Guo@sun.com Tue Mar 3 19:54:52 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n243sp4U009492 for ; Tue, 3 Mar 2009 19:54:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n243slq9007519 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 11:54:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY0070FQVBN100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 19:54:47 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00GXPQV4V1E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 19:54:47 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n243seYQ017954 for ; Wed, 04 Mar 2009 03:54:40 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00J00QT3KB00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:54:40 +0800 (SGT) Received: from [129.158.219.19] ([unknown] [129.158.219.19]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY00J2XQV3K800@mail-apac.sun.com>; Wed, 04 Mar 2009 11:54:40 +0800 (SGT) Date: Wed, 04 Mar 2009 11:53:44 +0800 From: Robin Guo Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: Sender: Robin.Guo@sun.com To: Rainer Orth Cc: James Walker , PSARC-ext@sun.com Message-id: <49ADFB48.1050505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090209) Status: RO Content-Length: 2976 Hi, Rainer, I recall to add an entry of Network Management profile need to file a CR to solaris/rbac/library? But tcpdump now support '-Z username' and has setuid/setgid call in the tcpdump.c, may I need to update this section for further discussion? -Z Drops privileges (if root) and changes user ID to user and the group ID to the primary group of user. This behavior can also be enabled by default at compile time. #ifndef WIN32 /* * We cannot do this earlier, because we want to be able to open * the file (if done) for writing before giving up permissions. */ if (getuid() == 0 || geteuid() == 0) { if (username || chroot_dir) droproot(username, chroot_dir); } #endif /* WIN32 */ #ifndef WIN32 /* Drop root privileges and chroot if necessary */ static void droproot(const char *username, const char *chroot_dir) { struct passwd *pw = NULL; if (chroot_dir && !username) { fprintf(stderr, "tcpdump: Chroot without dropping root is insecure\n"); exit(1); } pw = getpwnam(username); if (pw) { if (chroot_dir) { if (chroot(chroot_dir) != 0 || chdir ("/") != 0) { fprintf(stderr, "tcpdump: Couldn't chroot/chdir to '%.64s': %s\n", chroot_dir, pcap_strerror(errno)); exit(1); } } if (initgroups(pw->pw_name, pw->pw_gid) != 0 || setgid(pw->pw_gid) != 0 || setuid(pw->pw_uid) != 0) { fprintf(stderr, "tcpdump: Couldn't change to '%.32s' uid=%lu gid=%lu: %s\n", username, (unsigned long)pw->pw_uid, (unsigned long)pw->pw_gid, pcap_strerror(errno)); exit(1); } } else { fprintf(stderr, "tcpdump: Couldn't find user '%.32s'\n", username); exit(1); } } #endif /* WIN32 */ Rainer Orth wrote: > James Walker writes: > >> 3.4.2 Authorization >> (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and >> http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ >> for details) >> Are there any setuid/setgid privileged binaries in the project? >> [ ] Yes - ARC review required >> [*] No - continue with next section (section 3.4.3) >> >> If yes then are the setuid/setgid privileges handled by the use of roles? >> [ ] Yes >> [ ] No - ARC review required > > Shouldn't tcpdump be added to the Network Management profile in > /etc/security/exec_attr, just like snoop is? > > Rainer > -- Regards, Robin Guo, Xue-Bin Guo Solaris Kernel and Data Service QE, Sun China Engineering and Reserch Institute Phone: +86 10 82618200 +82296 Email: robin.guo@sun.com Blog: http://blogs.sun.com/robinguo From casper@holland.sun.com Wed Mar 4 00:20:25 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n248KP6w000470 for ; Wed, 4 Mar 2009 00:20:25 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n248KOIa015676 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 4 Mar 2009 00:20:24 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00K0J360KK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 04 Mar 2009 00:20:24 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00JWA35ZA6C0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 04 Mar 2009 00:20:24 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n248KJaC030482; Wed, 04 Mar 2009 08:20:19 +0000 (GMT) Date: Wed, 04 Mar 2009 09:20:19 +0100 From: Casper.Dik@sun.com Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <49ADFB48.1050505@sun.com> Sender: casper@holland.sun.com To: Robin Guo Cc: Rainer Orth , James Walker , PSARC-ext@sun.com Message-id: <200903040820.n248KJaC030482@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <49ADFB48.1050505@sun.com> Status: RO Content-Length: 566 >Hi, Rainer, > > I recall to add an entry of Network Management profile >need to file a CR to solaris/rbac/library? > > But tcpdump now support '-Z username' and has setuid/setgid >call in the tcpdump.c, may I need to update this section for further >discussion? Note that on Solaris, snoop *always* runs as user nobody when started as root and actually sniffing. Typically this means that it can write to the file it opened when it started up but it can't do much else. I'd suggest we do the same with tcpdump (makes this the default behaviour). Casper From carlsonj@phorcys.east.sun.com Wed Mar 4 05:41:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24DfFj3023914 for ; Wed, 4 Mar 2009 05:41:15 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24Df1RU030963; Wed, 4 Mar 2009 06:41:12 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00737I0N8P00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Mar 2009 05:41:11 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ006ISI0L2C00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Mar 2009 05:41:09 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n24Df3qk002713; Wed, 04 Mar 2009 08:41:03 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n24Df3tl002710; Wed, 04 Mar 2009 08:41:03 -0500 (EST) Date: Wed, 04 Mar 2009 08:41:03 -0500 From: James Carlson Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <49ADD36A.3060708@sun.com> To: James.Walker@sun.com Cc: PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <18862.34031.819948.365324@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> Status: RO Content-Length: 1566 Jim Walker writes: > James Carlson wrote: > > What's the point? > > > > tcpdump is enough like snoop that it seems to me that there's not a > > great reason to do this. Instead, it'd be much nicer to see wireshark > > integrated (which includes a command line tool that's more powerful > > than either tcpdump *or* snoop), and also have snoop yanked from the > > product. > > > > The time spent here could be better spent elsewhere. > > tcpdump is on the top 25 miss list, so I guess someone wants it. I think I might have been unclear on the point I was making. Is it on that list _because_ we still lack wireshark? Or is it on that list because there are folks that just have to have the kitchen sink tossed in? This entire area has police tape around it. We're still updating the moldy and poorly-designed "snoop" application. We approved the integration of wireshark years ago (see PSARC 2007/334), with advice to remove snoop. And now we're proposing to integrate tcpdump -- an application that has fewer features than wireshark, and that essentially duplicates snoop in functionality. So I have to ask: what thought is being put into these integrations? They can't just be random, can they? At a minimum, I think the ARC should consider whether this project actually conforms to the advice given. I don't believe it does. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Joep.Vesseur@sun.com Wed Mar 4 07:58:22 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24FwMVQ021989 for ; Wed, 4 Mar 2009 07:58:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24FwJdQ005915 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 07:58:21 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00M0LOD7RE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 07:58:19 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00LODOD5N710@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 07:58:18 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n24FwGPn006179 for ; Wed, 04 Mar 2009 15:58:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00D00O35N900@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 15:58:11 +0000 (GMT) Received: from appel.vesseur.org ([unknown] [62.177.247.60]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFZ0053POCR6D00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 15:58:03 +0000 (GMT) Date: Wed, 04 Mar 2009 16:58:05 +0100 From: Joep Vesseur Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18862.34031.819948.365324@gargle.gargle.HOWL> Sender: Joep.Vesseur@sun.com To: James Carlson Cc: James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <49AEA50D.3090109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 602 James Carlson wrote: > So I have to ask: what thought is being put into these integrations? > They can't just be random, can they? I think tcpdump helps Solaris pass the "warm fuzzy feeling"-test that people take when they take their first steps on a new platform. As such, it is a good thing to have, even though there might be better alternatives. Of course, this applies to a lot of programs, but I think for many administrators, tcpdump is on the top of their lists. Also, even though wireshark might be the preferred open source candidate for us, tcpdump is here to stay for a long time. Joep From carlsonj@phorcys.east.sun.com Wed Mar 4 08:22:32 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24GMWr3015725 for ; Wed, 4 Mar 2009 08:22:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24GMQIh022112; Wed, 4 Mar 2009 08:22:28 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ0036BPHFFH00@brm-avmta-1.central.sun.com>; Wed, 04 Mar 2009 09:22:27 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00ICDPHAYG60@brm-avmta-1.central.sun.com>; Wed, 04 Mar 2009 09:22:22 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n24GMHa1003850; Wed, 04 Mar 2009 11:22:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n24GMG7I003847; Wed, 04 Mar 2009 11:22:16 -0500 (EST) Date: Wed, 04 Mar 2009 11:22:16 -0500 From: James Carlson Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <49AEA50D.3090109@Sun.COM> To: Joep Vesseur Cc: James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <18862.43704.884212.889058@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> Status: RO Content-Length: 1693 Joep Vesseur writes: > Of course, this applies to a lot of programs, but I think for > many administrators, tcpdump is on the top of their lists. > > Also, even though wireshark might be the preferred open source candidate > for us, tcpdump is here to stay for a long time. Pity the poor folks who write protocols for a living. Which one of these tools -- snoop, wireshark, tcpdump -- should we attempt to update to support our projects? Should we try to update them all? Should we pick one because we think it's nifty? Worse still, if you look at tcpdump carefully, you'll see that it's essentially a subset of tshark, the command-line version of wireshark, including the same default file format, and even the same capture filters. But wireshark is far more capable and includes an extended filter syntax, more file formats, and a highly functional GUI (reminiscent of the old Network General Sniffer). This is an architectural mess, and this sort of unnecessary "choice" has serious costs associated with it. It affects many others, and not just those people who are building these random packages and delivering them. Plus, it's a waste of time: we should be delivering wireshark, but we haven't, even though the skids have been properly greased. I'm making a plea for some thought to be put into the process. Can we please do that? Or have we just completely given up on system architecture and the effects that one random project can have on another? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Joep.Vesseur@sun.com Wed Mar 4 08:39:30 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24GdUjr016796 for ; Wed, 4 Mar 2009 08:39:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24GdNLL012574 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 08:39:29 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ0011PQ9RQ000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:39:27 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00LX4Q9PN850@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:39:26 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe2.eu.sun.com [192.18.6.8] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n24GdPEO011712 for ; Wed, 04 Mar 2009 16:39:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00D00O35N900@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 16:39:24 +0000 (GMT) Received: from appel.vesseur.org ([unknown] [62.177.247.60]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFZ0087JQ9FQU70@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 16:39:15 +0000 (GMT) Date: Wed, 04 Mar 2009 17:39:17 +0100 From: Joep Vesseur Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18862.43704.884212.889058@gargle.gargle.HOWL> Sender: Joep.Vesseur@sun.com To: James Carlson Cc: James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <49AEAEB5.70106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1529 James Carlson wrote: > Joep Vesseur writes: >> Of course, this applies to a lot of programs, but I think for >> many administrators, tcpdump is on the top of their lists. >> >> Also, even though wireshark might be the preferred open source candidate >> for us, tcpdump is here to stay for a long time. > > Pity the poor folks who write protocols for a living. Which one of > these tools -- snoop, wireshark, tcpdump -- should we attempt to > update to support our projects? Should we try to update them all? > Should we pick one because we think it's nifty? Nobody will ask me, well, you just did... drop snoop, choose wireshark for what we want to work best, and provide tcpdump (either through the contrib repository or ON, I don't really care... I think contrib is best). > This is an architectural mess, and this sort of unnecessary "choice" > has serious costs associated with it. It affects many others, and not > just those people who are building these random packages and > delivering them. Plus, it's a waste of time: we should be delivering > wireshark, but we haven't, even though the skids have been properly > greased. > > I'm making a plea for some thought to be put into the process. Can we > please do that? Or have we just completely given up on system > architecture and the effects that one random project can have on > another? I think that, at the time we decided we wanted to provide a familiar OS, we let some of the architectural cleanliness slip, as much as I personally dislike that. Joep From Peter.Dennis@sun.com Wed Mar 4 08:40:29 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24GeT3b016867 for ; Wed, 4 Mar 2009 08:40:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24GeSM2027807 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 09:40:29 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ0014PQBGSM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:40:28 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00LV5QBEN160@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:40:27 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n24GeQZG012081 for ; Wed, 04 Mar 2009 16:40:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00D00O35N900@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 16:40:12 +0000 (GMT) Received: from [192.168.1.100] ([unknown] [86.151.58.230]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFZ008IQQAJQU70@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 16:39:55 +0000 (GMT) Date: Wed, 04 Mar 2009 16:39:55 +0000 From: petede Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18862.43704.884212.889058@gargle.gargle.HOWL> Sender: Peter.Dennis@sun.com To: James Carlson Cc: Joep Vesseur , PSARC-ext@sun.com, Robin.Guo@sun.com Reply-to: Peter.Dennis@sun.com Message-id: <49AEAEDB.9080803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20090113) Status: RO Content-Length: 1760 James Carlson wrote: > Joep Vesseur writes: >> Of course, this applies to a lot of programs, but I think for >> many administrators, tcpdump is on the top of their lists. Maybe off topic but tcpdump for OpenSolaris is available and can be downloaded from the contrib repo (http://pkg.opensolaris.org/contrib) Admittedly 3.9.8 as opposed to 4.0 - worth getting it up rev'ed there. >> >> Also, even though wireshark might be the preferred open source candidate >> for us, tcpdump is here to stay for a long time. > > Pity the poor folks who write protocols for a living. Which one of > these tools -- snoop, wireshark, tcpdump -- should we attempt to > update to support our projects? Should we try to update them all? > Should we pick one because we think it's nifty? > > Worse still, if you look at tcpdump carefully, you'll see that it's > essentially a subset of tshark, the command-line version of wireshark, > including the same default file format, and even the same capture > filters. But wireshark is far more capable and includes an extended > filter syntax, more file formats, and a highly functional GUI > (reminiscent of the old Network General Sniffer). > > This is an architectural mess, and this sort of unnecessary "choice" > has serious costs associated with it. It affects many others, and not > just those people who are building these random packages and > delivering them. Plus, it's a waste of time: we should be delivering > wireshark, but we haven't, even though the skids have been properly > greased. > > I'm making a plea for some thought to be put into the process. Can we > please do that? Or have we just completely given up on system > architecture and the effects that one random project can have on > another? > From carlsonj@phorcys.east.sun.com Wed Mar 4 08:53:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24Grpi4018433 for ; Wed, 4 Mar 2009 08:53:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n24GrbpR010327; Wed, 4 Mar 2009 16:53:47 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00G1PQXMXB00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Mar 2009 08:53:46 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00DTWQXKT720@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Mar 2009 08:53:45 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n24GrdF0004165; Wed, 04 Mar 2009 11:53:39 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n24GrddJ004162; Wed, 04 Mar 2009 11:53:39 -0500 (EST) Date: Wed, 04 Mar 2009 11:53:39 -0500 From: James Carlson Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <49AEAEDB.9080803@sun.com> To: Peter.Dennis@sun.com Cc: Joep Vesseur , PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <18862.45587.622044.35176@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> <49AEAEDB.9080803@sun.com> Status: RO Content-Length: 1040 petede writes: > > > James Carlson wrote: > > Joep Vesseur writes: > >> Of course, this applies to a lot of programs, but I think for > >> many administrators, tcpdump is on the top of their lists. > > Maybe off topic but tcpdump for OpenSolaris is available and can > be downloaded from the contrib repo (http://pkg.opensolaris.org/contrib) > Admittedly 3.9.8 as opposed to 4.0 - worth getting it up rev'ed there. As a "wild west" contribution, something that nobody has a right to expect will work in any integrated fashion with the rest of Solaris, I've got no problem with that. Heck, I don't even want to hear about it in the ARC. As something asking to deliver with the OS as an integrated component, I've got a problem. It does need to fit in, and we cannot ignore the effect it has on other projects. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Garrett.Damore@sun.com Wed Mar 4 08:54:58 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24GswmC018743 for ; Wed, 4 Mar 2009 08:54:58 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24Gsotk036600 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 09:54:58 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ0022VQZJIS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:54:55 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00L8OQZGN870@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:54:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n24GsqXl010635 for ; Wed, 04 Mar 2009 08:54:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00800PWQ1O00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:54:52 -0800 (PST) Received: from [129.153.2.8] ([unknown] [129.153.2.8]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFZ00LCQQZ81XA0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 08:54:45 -0800 (PST) Date: Wed, 04 Mar 2009 08:54:44 -0800 From: "Garrett D'Amore" Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18862.43704.884212.889058@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Joep Vesseur , James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <49AEB254.2000804@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_llJg+PjOvC8R4z6T8jl5Ew)" X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 4674 This is a multi-part message in MIME format. --Boundary_(ID_llJg+PjOvC8R4z6T8jl5Ew) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 03/04/09 08:22, James Carlson wrote: > Joep Vesseur writes: > >> Of course, this applies to a lot of programs, but I think for >> many administrators, tcpdump is on the top of their lists. >> >> Also, even though wireshark might be the preferred open source candidate >> for us, tcpdump is here to stay for a long time. >> > > Pity the poor folks who write protocols for a living. Which one of > these tools -- snoop, wireshark, tcpdump -- should we attempt to > update to support our projects? Should we try to update them all? > Should we pick one because we think it's nifty? > ISTR, as part of the arc case for wireshark itself, that we had decided that wireshark was the tool we were going to support. Other tools (snoop especially) seemed to be more or less devolving into planned obsolescence. I *thought* tcpdump was the precursor to wireshark anyway. Do I misunderstand? -- Garrett > Worse still, if you look at tcpdump carefully, you'll see that it's > essentially a subset of tshark, the command-line version of wireshark, > including the same default file format, and even the same capture > filters. But wireshark is far more capable and includes an extended > filter syntax, more file formats, and a highly functional GUI > (reminiscent of the old Network General Sniffer). > > This is an architectural mess, and this sort of unnecessary "choice" > has serious costs associated with it. It affects many others, and not > just those people who are building these random packages and > delivering them. Plus, it's a waste of time: we should be delivering > wireshark, but we haven't, even though the skids have been properly > greased. > > I'm making a plea for some thought to be put into the process. Can we > please do that? Or have we just completely given up on system > architecture and the effects that one random project can have on > another? > > --Boundary_(ID_llJg+PjOvC8R4z6T8jl5Ew) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 03/04/09 08:22, James Carlson wrote: 
Joep Vesseur writes:
  
Of course, this applies to a lot of programs, but I think for
many administrators, tcpdump is on the top of their lists.

Also, even though wireshark might be the preferred open source candidate
for us, tcpdump is here to stay for a long time.
    

Pity the poor folks who write protocols for a living.  Which one of
these tools -- snoop, wireshark, tcpdump -- should we attempt to
update to support our projects?  Should we try to update them all?
Should we pick one because we think it's nifty?

ISTR, as part of the arc case for wireshark itself, that we had decided that wireshark was the tool we were going to support.  Other tools (snoop especially) seemed to be more or less devolving into planned obsolescence.

I *thought* tcpdump was the precursor to wireshark anyway.  Do I misunderstand?

    -- Garrett
Worse still, if you look at tcpdump carefully, you'll see that it's
essentially a subset of tshark, the command-line version of wireshark,
including the same default file format, and even the same capture
filters.  But wireshark is far more capable and includes an extended
filter syntax, more file formats, and a highly functional GUI
(reminiscent of the old Network General Sniffer).

This is an architectural mess, and this sort of unnecessary "choice"
has serious costs associated with it.  It affects many others, and not
just those people who are building these random packages and
delivering them.  Plus, it's a waste of time: we should be delivering
wireshark, but we haven't, even though the skids have been properly
greased.

I'm making a plea for some thought to be put into the process.  Can we
please do that?  Or have we just completely given up on system
architecture and the effects that one random project can have on
another?

--Boundary_(ID_llJg+PjOvC8R4z6T8jl5Ew)-- From Gordon.Ross@sun.com Wed Mar 4 10:37:33 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24IbXFA002072 for ; Wed, 4 Mar 2009 10:37:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n24IbXDo043088 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 11:37:33 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00G0DVQJVA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:37:31 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ00EXZVQJHD10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:37:31 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n24IbVEh016388 for ; Wed, 04 Mar 2009 18:37:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00800UPJ7100@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:37:31 -0700 (MST) Received: from [129.148.168.96] ([unknown] [129.148.168.96]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFZ00E7OVQDK560@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 11:37:26 -0700 (MST) Date: Wed, 04 Mar 2009 13:37:28 -0500 From: Gordon Ross Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <18862.43704.884212.889058@gargle.gargle.HOWL> Sender: Gordon.Ross@sun.com To: James Carlson Cc: Joep Vesseur , James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <1236191848.1085.4.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> Status: RO Content-Length: 325 James Carlson wrote: > [...] we should be delivering wireshark, but we haven't, > even though the skids have been properly greased. > [...] There is work underway to get wireshark integrated. It was stalled for a while due to staffing, but has someone working on it now. (I'll let him speak up if he wants - BCC) Gordon From bart.smaalders@sun.com Wed Mar 4 10:37:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24Ibbce002084 for ; Wed, 4 Mar 2009 10:37:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n24IbN2e022486; Wed, 4 Mar 2009 18:37:32 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFZ00C05VQH0800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Mar 2009 10:37:29 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFZ005ATVQHK160@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Mar 2009 10:37:29 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n24IbTHF006281; Wed, 04 Mar 2009 18:37:29 +0000 (GMT) Date: Wed, 04 Mar 2009 10:37:27 -0800 From: Bart Smaalders Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <49AEB254.2000804@sun.com> To: "Garrett D'Amore" Cc: James Carlson , Joep Vesseur , James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <49AECA67.7070504@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> <49AEB254.2000804@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090113) Status: RO Content-Length: 292 FWIW, Petr is in code review w/ Wireshark; I've not had time to finish as IPS has been taking rather a lot of time. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Garrett.Damore@sun.com Wed Mar 4 12:33:56 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24KXtLn003932 for ; Wed, 4 Mar 2009 12:33:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n24KXmrr016662 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 5 Mar 2009 04:33:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KG0009BJ14HUG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 12:33:53 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KG000MLZ14FBSB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 12:33:51 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n24KXpt8024928 for ; Wed, 04 Mar 2009 12:33:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFZ00B00ZKM8C00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 12:33:51 -0800 (PST) Received: from [129.153.2.8] ([unknown] [129.153.2.8]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KG000CLD13ZNND0@fe-sfbay-09.sun.com>; Wed, 04 Mar 2009 12:33:36 -0800 (PST) Date: Wed, 04 Mar 2009 12:33:35 -0800 From: "Garrett D'Amore" Subject: Re: tcpdump [PSARC/2009/147 FastTrack timeout 03/10/2009] In-reply-to: <49AECA67.7070504@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: James Carlson , Joep Vesseur , James.Walker@sun.com, PSARC-ext@sun.com, Robin.Guo@sun.com Message-id: <49AEE59F.1080008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903030928.n239SEdc011715@sac.sfbay.sun.com> <18861.10813.92364.822255@gargle.gargle.HOWL> <49ADD36A.3060708@sun.com> <18862.34031.819948.365324@gargle.gargle.HOWL> <49AEA50D.3090109@Sun.COM> <18862.43704.884212.889058@gargle.gargle.HOWL> <49AEB254.2000804@sun.com> <49AECA67.7070504@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 223 On 03/04/09 10:37, Bart Smaalders wrote: > > FWIW, Petr is in code review w/ Wireshark; I've not had time to > finish as IPS has been taking rather a lot of time. > > - Bart > > Okay, thanks for the update. -- Garrett From carlsonj@phorcys.east.sun.com Wed Mar 11 14:47:54 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2BLlrOF020570 for ; Wed, 11 Mar 2009 14:47:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2BLljTh004802 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 12 Mar 2009 05:47:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGD00D0Z37R7G00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 11 Mar 2009 14:47:51 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGD008KB37Q1YD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 11 Mar 2009 14:47:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2BLlgeC013260 for ; Wed, 11 Mar 2009 17:47:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2BLlg5a013257; Wed, 11 Mar 2009 17:47:42 -0400 (EDT) Date: Wed, 11 Mar 2009 17:47:42 -0400 From: James Carlson Subject: Opinion for review: PSARC 2009/147 tcpdump To: psarc-ext@sun.com Message-id: <18872.12670.58955.307974@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6613 ARC members: please review and submit any comments by 03/18/2009. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: tcpdump Submitted by: Robin Guo File: PSARC/2009/147/opinion.ms Date: March 4th, 2009 Committee: James Carlson, Mark Carlson, Garrett D'Amore, Richard Matthews, Sebastien Roy, Glenn Skinner, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The open source tcpdump (packet tracing) utility is to be shipped with OpenSolaris, delivering via the SFW consolida- tion. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a Minor release of Solaris or OpenSolaris. The project depends on an upgraded (verison 1.0.0 or better) libpcap in SFW, and may not be delivered until this library is updated. 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |_________________|________________|______________________| |Interface | Classification| Comments | |_________________|________________|______________________| |/usr/sbin/tcpdump| Uncommitted | Binary location | |SUNWtcpdump | Uncommitted | Package name | |_________________|________________|______________________| PSARC/2009/147 Copyright 2009 Sun Microsystems - 2 - ___________________________________________________________ | Interfaces Exported | |_________________|________________|______________________| |Interface | Classification| Comments | |_________________|________________|______________________| |tcpdump | Uncommitted | Command line options| |files | Uncommitted | File formats | |output | Volatile | Output format | |_________________|________________|______________________| The project imports the following interfaces. _____________________________________________ | Interfaces Imported | |_________|________________|________________| |Interface| Classification| Comments | |_________|________________|________________| |libpcap | Committed | PSARC 2008/288| |_________|________________|________________| 4. Opinion 4.1. Tcpdump, Wireshark, and Snoop An ARC member noted that tcpdump's functionality is essen- tially similar to the existing snoop utility and that the wireshark/tshark utility is a superset of both and accepts much of the tcpdump packet filtering syntax. The project team responded that tcpdump is being offered as an option, and might be useful for those with scripts that are dependent on the exact behavior of tcpdump. The ARC members agreed that this was a useful reason for the duplication, and that trying to provide a wrapper for tshark is likely not a productive activity. 4.2. What Direction Are We Headed? Several ARC members noted that we approved wireshark (PSARC 2007/334) quite some time ago, and that it was approved with the understanding that it would replace snoop and be the primary packet capture and display system on Solaris and OpenSolaris, but that wireshark, though in common use on Solaris, has not yet delivered, and that our direction is thus unclear. Is the plan still current? Further, this lack of direction is affecting other network- ing projects. As of today, snoop is still the only packet capture service in the system, and projects being developed and reviewed today will need to be directed to update snoop, PSARC/2009/147 Copyright 2009 Sun Microsystems - 3 - even if that effort is not in the long term interest of Solaris or OpenSolaris, because there are no alternatives. To deal fairly with projects that are dependent on common features, where there may be multiple separate implementa- tions of these features, the ARC must have information regarding which one is the "preferred" implementation. In this case, knowing that wireshark is still "preferred" means that networking projects delivering new protocols into Solaris or OpenSolaris will be directed to update wireshark rather than snoop or tcpdump. Customers as well need to know which implementation is "pre- ferred." The preferred implementation is the one that will be expected to be most compatible with the Solaris/OpenSolaris environment, while the others may not necessarily be tailored for that use. The discussion of these issues led to the advice in section 6 below, and to the technical change required. 5. Minority Opinion(s) None 6. Advisory Information When delivering multiple implementations of a single feature, and where an extended period of co-existence rather than eventual replacement is expected, the Solaris PAC and the management of the on-going "familiarity" project are advised that the ARC requires explicit information regarding which of the co-existing implementations is regarded as "preferred." The management teams are also reminded that, as decided in PSARC 2007/334, wireshark is the packet capture and display mechanism of record, and prompt delivery of this feature is highly desirable, and more useful to Solaris and OpenSolaris than is delivery of any other alternative implementation. Failing to deliver wireshark will very likely cause problems for other projects. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The end user documentation delivered must include language pointing the user to the "preferred" packet capture and display mechanism on the sys- tem, so that the user knows which one is intended to decode all supported protocols on the system. PSARC/2009/147 Copyright 2009 Sun Microsystems - 4 - 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/147. 1. Tcpdump Project Proposal File: proposal.txt PSARC/2009/147 Copyright 2009 Sun Microsystems From sac-owner Wed Mar 25 13:25:39 2009 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PKPcwu024855 for ; Wed, 25 Mar 2009 13:25:39 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2PKPPKE014873 for ; Wed, 25 Mar 2009 16:25:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2PKPP2l014870; Wed, 25 Mar 2009 16:25:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18890.37684.986575.86747@gargle.gargle.HOWL> Date: Wed, 25 Mar 2009 16:25:24 -0400 From: James Carlson To: sac-review@sac.sfbay.sun.com Subject: Opinion for review: PSARC 2009/147 tcpdump X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 6653 SAC members: please review and submit any comments by 04/01/2009. (Note: this is an open exposure case.) sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: tcpdump Submitted by: Robin Guo File: PSARC/2009/147/opinion.ms Date: March 4th, 2009 Committee: James Carlson, Mark Carlson, Garrett D'Amore, Richard Matthews, Sebastien Roy, Glenn Skinner, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The open source tcpdump (packet tracing) utility is to be shipped with OpenSolaris, delivering via the SFW consolida- tion. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a Minor release of Solaris or OpenSolaris. The project depends on an upgraded (verison 1.0.0 or better) libpcap in SFW, and may not be delivered until this library is updated. 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |_________________|________________|______________________| |Interface | Classification| Comments | |_________________|________________|______________________| |/usr/sbin/tcpdump| Uncommitted | Binary location | |SUNWtcpdump | Uncommitted | Package name | |_________________|________________|______________________| PSARC/2009/147 Copyright 2009 Sun Microsystems - 2 - ___________________________________________________________ | Interfaces Exported | |_________________|________________|______________________| |Interface | Classification| Comments | |_________________|________________|______________________| |tcpdump | Uncommitted | Command line options| |files | Uncommitted | File formats | |output | Volatile | Output format | |_________________|________________|______________________| The project imports the following interfaces. _____________________________________________ | Interfaces Imported | |_________|________________|________________| |Interface| Classification| Comments | |_________|________________|________________| |libpcap | Committed | PSARC 2008/288| |_________|________________|________________| 4. Opinion 4.1. Tcpdump, Wireshark, and Snoop An ARC member noted that tcpdump's functionality is essen- tially similar to the existing snoop utility and that the wireshark/tshark utility is a superset of both and accepts much of the tcpdump packet filtering syntax. The project team responded that tcpdump is being offered as an option, and might be useful for those with scripts that are dependent on the exact behavior of tcpdump. The ARC members agreed that this was a useful reason for the duplication, and that trying to provide a wrapper for tshark is likely not a productive activity. 4.2. What Direction Are We Headed? Several ARC members noted that we approved wireshark (PSARC 2007/334) quite some time ago, and that it was approved with the understanding that it would replace snoop and be the primary packet capture and display system on Solaris and OpenSolaris, but that wireshark, though in common use on Solaris, has not yet delivered, and that our direction is thus unclear. Is the plan still current? Further, this lack of direction is affecting other network- ing projects. As of today, snoop is still the only packet capture service in the system, and projects being developed and reviewed today will need to be directed to update snoop, PSARC/2009/147 Copyright 2009 Sun Microsystems - 3 - even if that effort is not in the long term interest of Solaris or OpenSolaris, because there are no alternatives. To deal fairly with projects that are dependent on common features, where there may be multiple separate implementa- tions of these features, the ARC must have information regarding which one is the "preferred" implementation. In this case, knowing that wireshark is still "preferred" means that networking projects delivering new protocols into Solaris or OpenSolaris will be directed to update wireshark rather than snoop or tcpdump. Customers as well need to know which implementation is "pre- ferred." The preferred implementation is the one that will be expected to be most compatible with the Solaris/OpenSolaris environment, while the others may not necessarily be tailored for that use. The discussion of these issues led to the advice in section 6 below, and to the technical change required. 5. Minority Opinion(s) None 6. Advisory Information When delivering multiple implementations of a single feature, and where an extended period of co-existence rather than eventual replacement is expected, the Solaris PAC and the management of the on-going "familiarity" project are advised that the ARC requires explicit information regarding which of the co-existing implementations is regarded as "preferred." The management teams are also reminded that, as decided in PSARC 2007/334, wireshark is the packet capture and display mechanism of record, and prompt delivery of this feature is highly desirable, and more useful to Solaris and OpenSolaris than is delivery of any other alternative implementation. Failing to deliver wireshark will very likely cause problems for other projects. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The end user documentation delivered must include language pointing the user to the "preferred" packet capture and display mechanism on the sys- tem, so that the user knows which one is intended to decode all supported protocols on the system. PSARC/2009/147 Copyright 2009 Sun Microsystems - 4 - 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/147. 1. Tcpdump Project Proposal File: proposal.txt PSARC/2009/147 Copyright 2009 Sun Microsystems From sac-owner Fri Apr 10 11:47:52 2009 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3AIlp8F002258 for ; Fri, 10 Apr 2009 11:47:52 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3AIlpHZ063972; Fri, 10 Apr 2009 14:47:51 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n3AIlONV006935; Fri, 10 Apr 2009 14:47:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n3AIlOcd006932; Fri, 10 Apr 2009 14:47:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18911.37948.745398.508403@gargle.gargle.HOWL> Date: Fri, 10 Apr 2009 14:47:24 -0400 From: James Carlson To: sac-opinion@sac.sfbay.sun.com cc: solaris-pac@sun.com Subject: SAC Opinion: PSARC 2009/147 tcpdump X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 6546 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: tcpdump Submitted by: Robin Guo File: PSARC/2009/147/opinion.ms Date: March 4th, 2009 Committee: James Carlson, Mark Carlson, Garrett D'Amore, Richard Matthews, Sebastien Roy, Glenn Skinner, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac@sun.com 1. Summary The open source tcpdump (packet tracing) utility is to be shipped with OpenSolaris, delivering via the SFW consolida- tion. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a Minor release of Solaris or OpenSolaris. The project depends on an upgraded (verison 1.0.0 or better) libpcap in SFW, and may not be delivered until this library is updated. 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |_________________|________________|______________________| |Interface | Classification| Comments | |_________________|________________|______________________| |/usr/sbin/tcpdump| Uncommitted | Binary location | |SUNWtcpdump | Uncommitted | Package name | |_________________|________________|______________________| PSARC/2009/147 Copyright 2009 Sun Microsystems - 2 - ___________________________________________________________ | Interfaces Exported | |_________________|________________|______________________| |Interface | Classification| Comments | |_________________|________________|______________________| |tcpdump | Uncommitted | Command line options| |files | Uncommitted | File formats | |output | Volatile | Output format | |_________________|________________|______________________| The project imports the following interfaces. _____________________________________________ | Interfaces Imported | |_________|________________|________________| |Interface| Classification| Comments | |_________|________________|________________| |libpcap | Committed | PSARC 2008/288| |_________|________________|________________| 4. Opinion 4.1. Tcpdump, Wireshark, and Snoop An ARC member noted that tcpdump's functionality is essen- tially similar to the existing snoop utility and that the wireshark/tshark utility is a superset of both and accepts much of the tcpdump packet filtering syntax. The project team responded that tcpdump is being offered as an option, and might be useful for those with scripts that are dependent on the exact behavior of tcpdump. The ARC members agreed that this was a useful reason for the duplication, and that trying to provide a wrapper for tshark is likely not a productive activity. 4.2. What Direction Are We Headed? Several ARC members noted that we approved wireshark (PSARC 2007/334) quite some time ago, and that it was approved with the understanding that it would replace snoop and be the primary packet capture and display system on Solaris and OpenSolaris, but that wireshark, though in common use on Solaris, has not yet delivered, and that our direction is thus unclear. Is the plan still current? Further, this lack of direction is affecting other network- ing projects. As of today, snoop is still the only packet capture service in the system, and projects being developed and reviewed today will need to be directed to update snoop, PSARC/2009/147 Copyright 2009 Sun Microsystems - 3 - even if that effort is not in the long term interest of Solaris or OpenSolaris, because there are no alternatives. To deal fairly with projects that are dependent on common features, where there may be multiple separate implementa- tions of these features, the ARC must have information regarding which one is the "preferred" implementation. In this case, knowing that wireshark is still "preferred" means that networking projects delivering new protocols into Solaris or OpenSolaris will be directed to update wireshark rather than snoop or tcpdump. Customers as well need to know which implementation is "pre- ferred." The preferred implementation is the one that will be expected to be most compatible with the Solaris/OpenSolaris environment, while the others may not necessarily be tailored for that use. The discussion of these issues led to the advice in section 6 below, and to the technical change required. 5. Minority Opinion(s) None 6. Advisory Information When delivering multiple implementations of a single feature, and where an extended period of co-existence rather than eventual replacement is expected, the Solaris PAC and the management of the on-going "familiarity" project are advised that the ARC requires explicit information regarding which of the co-existing implementations is regarded as "preferred." The management teams are also reminded that, as decided in PSARC 2007/334, wireshark is the packet capture and display mechanism of record, and prompt delivery of this feature is highly desirable, and more useful to Solaris and OpenSolaris than is delivery of any other alternative implementation. Failing to deliver wireshark will very likely cause problems for other projects. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The end user documentation delivered must include language pointing the user to the "preferred" packet capture and display mechanism on the sys- tem, so that the user knows which one is intended to decode all supported protocols on the system. PSARC/2009/147 Copyright 2009 Sun Microsystems - 4 - 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/147. 1. Tcpdump Project Proposal File: proposal.txt PSARC/2009/147 Copyright 2009 Sun Microsystems