From jw137282@sac.sfbay.sun.com Tue Jan 13 00:32:49 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 n0D8Wm28028749 for ; Tue, 13 Jan 2009 00:32:48 -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 n0D8Wj3w007187; Tue, 13 Jan 2009 16:32:47 +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 <0KDE00E0NIELJT00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Jan 2009 00:32:45 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDE006UCIELMC60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Jan 2009 00:32:45 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0D8WhcA029958; Tue, 13 Jan 2009 00:32:43 -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 n0D8WbnW028743; Tue, 13 Jan 2009 00:32:37 -0800 (PST) Received: (from jw137282@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n0D8Wb1d028739; Tue, 13 Jan 2009 00:32:37 -0800 (PST) Date: Tue, 13 Jan 2009 00:32:37 -0800 (PST) From: James Walker Subject: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] To: PSARC-ext@sun.com Cc: xiang.zhou@sun.com Message-id: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 12533 I'm sponsoring this case for Xiang Zhou, the timeout is set to expire next Tuesday, January 20, 2009. The requested release binding is minor. The man page has been posted in the materials directory. Note. iftop does not currently support IPv6 and there are no resources available to add support at this time. Xiang Zhou will work with the upstream community to provide IPv6 support. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iftop 1.2. Name of Document Author/Supplier: Author: Xiang Zhou 1.3 Date of This Document: 13 January, 2009 4. Technical Description Iftop Check List 1.0 Project Information 1.1 Name of project/component iftop 1.2 Author of document Xiang Zhou 2.0 Project Summary 2.1 Project Description iftop does for network usage what top(1) does for CPU usage. It listens to network traffic on a named interface and displays a table of current bandwidth usage by pairs of hosts. iftop-0.17 will be integrated into the SFW consolidation as part of this proposal, and will be installed as SUNWiftop. 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 iftop - Paul Warren [1] 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 4.1 Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- SUNWiftop Uncommitted Package /usr/sbin/iftop Uncommitted Executable binary file 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- libpcap Uncommitted PSARC/2008/288 ncurses Uncommitted LSARC/2008/524 Appendix A - References [1] http://ex-parrot.com/~pdw/iftop/ OSR ID# 10721 RFE ID# 6782492 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 edward.pilatowicz@sun.com Tue Jan 13 14:04:02 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 n0DM4267013637 for ; Tue, 13 Jan 2009 14:04:02 -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 n0DM3wqC059551; Tue, 13 Jan 2009 15:03:59 -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 <0KDF00J09JYN5P00@brm-avmta-1.central.sun.com>; Tue, 13 Jan 2009 15:03:59 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDF008CMJYLG7A0@brm-avmta-1.central.sun.com>; Tue, 13 Jan 2009 15:03:57 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0DM3uXG447212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 14:03:56 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n0DM3uq3447211; Tue, 13 Jan 2009 14:03:56 -0800 (PST) Date: Tue, 13 Jan 2009 14:03:56 -0800 From: Edward Pilatowicz Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> To: James Walker Cc: PSARC-ext@sun.com, xiang.zhou@sun.com Message-id: <20090113220356.GC436257@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 13364 i'd like to know how iftop interracts with zones. - can it be run inside of a zone (shared stack and/or exclusive stack)? - if it runs inside of a zone, does it only display information for interfaces present in that zone? - if run from the global zone, does it display information for all zones on the system or just the global zone? - if run from the global zone, is there a way to display information for just one specified zone? ed On Tue, Jan 13, 2009 at 12:32:37AM -0800, James Walker wrote: > I'm sponsoring this case for Xiang Zhou, the timeout is set to expire next > Tuesday, January 20, 2009. The requested release binding is minor. The > man page has been posted in the materials directory. > > Note. iftop does not currently support IPv6 and there are no resources > available to add support at this time. Xiang Zhou will work with the > upstream community to provide IPv6 support. > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > iftop > 1.2. Name of Document Author/Supplier: > Author: Xiang Zhou > 1.3 Date of This Document: > 13 January, 2009 > 4. Technical Description > Iftop Check List > 1.0 Project Information > 1.1 Name of project/component > iftop > > 1.2 Author of document > Xiang Zhou > > 2.0 Project Summary > 2.1 Project Description > iftop does for network usage what top(1) does for CPU usage. It listens > to network traffic on a named interface and displays a table of current > bandwidth usage by pairs of hosts. > > iftop-0.17 will be integrated into the SFW consolidation as part of this > proposal, and will be installed as SUNWiftop. > > 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 > iftop - Paul Warren [1] > > 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 > 4.1 Exported Interfaces > > Interface Name Classification Comments > --------------------------- ------------------- --------------------------- > SUNWiftop Uncommitted Package > /usr/sbin/iftop Uncommitted Executable binary file > > > 4.2 Imported Interfaces > > Interface Name Classification Comments > --------------------------- -------------------- -------------------------- > libpcap Uncommitted PSARC/2008/288 > ncurses Uncommitted LSARC/2008/524 > > Appendix A - References > [1] http://ex-parrot.com/~pdw/iftop/ > > OSR ID# 10721 > RFE ID# 6782492 > > > 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 James.Walker@sun.com Tue Jan 13 14:30:09 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 n0DMU8Gh014484 for ; Tue, 13 Jan 2009 14:30:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0DMU7mA027010 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Jan 2009 22:30:08 GMT 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 <0KDF00D21L67X500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Jan 2009 14:30:07 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDF00CVAL651N10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Jan 2009 14:30:05 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0DMU5HB006573 for ; Tue, 13 Jan 2009 22:30:05 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDF00101L4CGK00@mail-amer.sun.com> (original mail from James.Walker@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Jan 2009 15:30:05 -0700 (MST) Received: from [172.20.25.153] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDF000PEL5UCEC0@mail-amer.sun.com>; Tue, 13 Jan 2009 15:29:54 -0700 (MST) Date: Tue, 13 Jan 2009 15:53:46 -0700 From: Jim Walker Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <20090113220356.GC436257@eng.sun.com> Sender: James.Walker@sun.com To: Edward Pilatowicz Cc: PSARC-ext@sun.com, Xiang.Zhou@sun.com Reply-to: James.Walker@sun.com Message-id: <496D1B7A.60404@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: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 611 Ed, We can provide this information. Just to clarify. Does any of this relate to the arc case? Cheers, Jim Edward Pilatowicz wrote: > i'd like to know how iftop interracts with zones. > > - can it be run inside of a zone (shared stack and/or exclusive stack)? > > - if it runs inside of a zone, does it only display information for > interfaces present in that zone? > > - if run from the global zone, does it display information for all zones > on the system or just the global zone? > > - if run from the global zone, is there a way to display information for > just one specified zone? > > ed From edward.pilatowicz@sun.com Tue Jan 13 14:38:05 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 n0DMc4mw014788 for ; Tue, 13 Jan 2009 14:38:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0DMbl6r001464; Tue, 13 Jan 2009 22:37:59 GMT 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 <0KDF00E0NLJ9GJ00@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Jan 2009 14:37:57 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDF00CZULJ51B10@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Jan 2009 14:37:53 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0DMbreL453820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 14:37:53 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n0DMbrgU453819; Tue, 13 Jan 2009 14:37:53 -0800 (PST) Date: Tue, 13 Jan 2009 14:37:52 -0800 From: Edward Pilatowicz Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <496D1B7A.60404@sun.com> To: Jim Walker Cc: PSARC-ext@sun.com, Xiang.Zhou@sun.com Message-id: <20090113223752.GE436257@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 976 imho, yes. if iftop has limitations wrt zones, i'd expect that to be documented. (similar to how lack of ipv6 support is documented.) also, if this is the case i'd like to hear that improved support for zones it being planned. (once again, similar to the ipv6 situation.) ed On Tue, Jan 13, 2009 at 03:53:46PM -0700, Jim Walker wrote: > Ed, > > We can provide this information. > > Just to clarify. Does any of this relate to the arc case? > > Cheers, > Jim > > Edward Pilatowicz wrote: >> i'd like to know how iftop interracts with zones. >> >> - can it be run inside of a zone (shared stack and/or exclusive stack)? >> >> - if it runs inside of a zone, does it only display information for >> interfaces present in that zone? >> >> - if run from the global zone, does it display information for all zones >> on the system or just the global zone? >> >> - if run from the global zone, is there a way to display information for >> just one specified zone? >> >> ed From peter.memishian@sun.com Wed Jan 14 00:09:32 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 n0E89Vbw021959 for ; Wed, 14 Jan 2009 00:09:32 -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 n0E89UNk009590 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 14 Jan 2009 01:09:31 -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 <0KDG00D0NBZUF500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 14 Jan 2009 01:09:30 -0700 (MST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDG00BBXBZTDH10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 14 Jan 2009 01:09:30 -0700 (MST) Received: from zhadum.east.sun.com (zhadum.East.Sun.COM [10.8.57.1]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0E89RSE011141; Wed, 14 Jan 2009 03:09:27 -0500 (EST) Received: from zhadum.east.sun.com (localhost [127.0.0.1]) by zhadum.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0E89RvA585627; Wed, 14 Jan 2009 03:09:27 -0500 (EST) Received: (from meem@localhost) by zhadum.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0E89R5B585624; Wed, 14 Jan 2009 03:09:27 -0500 (EST) Date: Wed, 14 Jan 2009 03:09:27 -0500 From: Peter Memishian Subject: re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] To: PSARC-ext@sun.com, xiang.zhou@sun.com Reply-to: peter.memishian@sun.com Message-id: <18797.40375.475300.25562@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: zhadum.east.sun.com: meem set sender to peter.memishian@sun.com using -f Status: RO Content-Length: 273 Unlike many other Unix variants, Solaris draws a clear separation between an IP interface and a datalink. Which is iftop providing information about? Further, what APIs does it use to get this information? (I don't see any mention in the Interfaces section.) -- meem From Xiang.Zhou@sun.com Thu Jan 15 02:20:40 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 n0FAKeET009669 for ; Thu, 15 Jan 2009 02:20:40 -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 n0FAKbW9065070 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 15 Jan 2009 03:20:40 -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 <0KDI00C0HCQFHR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 02:20:39 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI00033CQDEIA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 02:20:38 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FAKbJU023383 for ; Thu, 15 Jan 2009 10:20:37 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0KDI00401CMCSQ00@mail-apac.sun.com> (original mail from Xiang.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 18:20:37 +0800 (SGT) Received: from [129.158.219.227] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KDI0009RCQA2Z40@mail-apac.sun.com>; Thu, 15 Jan 2009 18:20:35 +0800 (SGT) Date: Thu, 15 Jan 2009 18:20:01 +0800 From: Xiang Zhou Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <20090113223752.GE436257@eng.sun.com> Sender: Xiang.Zhou@sun.com To: Edward Pilatowicz Cc: Jim Walker , PSARC-ext@sun.com Message-id: <496F0DD1.4010301@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: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080407) Status: RO Content-Length: 2148 On 01/14/09 06:37, Edward Pilatowicz wrote: > imho, yes. > > if iftop has limitations wrt zones, i'd expect that to be documented. > (similar to how lack of ipv6 support is documented.) > > also, if this is the case i'd like to hear that improved support for > zones it being planned. (once again, similar to the ipv6 situation.) > Here is the update related solaris zones: Now iftop has limitations with zones. iftop can not work properly in both shared stack zone and exclusive stack zone. Because it invokes DLPI functions. There are no resources available to add support at this time. I will work with the upstream community to provide full support for Solaris zones. > ed > > On Tue, Jan 13, 2009 at 03:53:46PM -0700, Jim Walker wrote: > >> Ed, >> >> We can provide this information. >> >> Just to clarify. Does any of this relate to the arc case? >> >> Cheers, >> Jim >> >> Here are the detail update on these questions: >> Edward Pilatowicz wrote: >> >>> i'd like to know how iftop interracts with zones. >>> >>> - can it be run inside of a zone (shared stack and/or exclusive stack)? >>> No. If it is compiled with HAVE_DLPI, it can not be run in both shared zone and exclusive zone because iftop report dlpi error inside zone. If it is compiled without HAVE_DLPI, it can run but not display any information of traffic on interfaces. >>> - if it runs inside of a zone, does it only display information for >>> interfaces present in that zone? >>> No. None traffic information is displayed. >>> - if run from the global zone, does it display information for all zones >>> on the system or just the global zone? >>> It display only the information in global zone if you do not specify the interface assigned to non-global zone. >>> - if run from the global zone, is there a way to display information for >>> just one specified zone? >>> Yes, from global zone, once you specify the interface assigned to the zone, it will display the traffic from/to the interface of the zone. It works for both shared zone and exclusive zone. Thanks for your comment. -- Best Regards, Xiang From carlsonj@phorcys.east.sun.com Thu Jan 15 04:58:44 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 n0FCwiRV029082 for ; Thu, 15 Jan 2009 04:58:44 -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 n0FCwdEj007736; Thu, 15 Jan 2009 05:58:41 -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 <0KDI00509K1SA700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 04:58:40 -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 <0KDI00EWRK1RGOD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 04:58:39 -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 n0FCwdio008269; Thu, 15 Jan 2009 07:58:39 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0FCwdQC008266; Thu, 15 Jan 2009 07:58:39 -0500 (EST) Date: Thu, 15 Jan 2009 07:58:39 -0500 From: James Carlson Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <496F0DD1.4010301@Sun.COM> To: Xiang Zhou Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker Message-id: <18799.13055.277845.373212@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: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> Status: RO Content-Length: 1230 Xiang Zhou writes: > On 01/14/09 06:37, Edward Pilatowicz wrote: > > imho, yes. > > > > if iftop has limitations wrt zones, i'd expect that to be documented. > > (similar to how lack of ipv6 support is documented.) > > > > also, if this is the case i'd like to hear that improved support for > > zones it being planned. (once again, similar to the ipv6 situation.) > > > Here is the update related solaris zones: > > Now iftop has limitations with zones. iftop can not work properly in > both shared stack zone and exclusive stack zone. Because it invokes > DLPI functions. There are no resources available to add support at this > time. I will work with the upstream community to provide full support > for Solaris zones. How does it open DLPI devices? If it doesn't use libdlpi, does it have support for Solaris "vanity naming," which requires looking in /dev/net/ for the device first? If it doesn't do that, could a fix be contributed back upstream? It's usually about two lines of code. -- 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 Xiang.Zhou@Sun.COM Thu Jan 15 07:25:50 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 n0FFPoAL001428 for ; Thu, 15 Jan 2009 07:25:50 -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 n0FFPkoi011943 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 15 Jan 2009 07:25:50 -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 <0KDI00L0RQV16800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 08:25:49 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI00C2CQUZ6R70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 08:25:48 -0700 (MST) 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 n0FFPkaY013265 for ; Thu, 15 Jan 2009 15:25:46 +0000 (GMT) Received: from sun.com ([129.158.123.8]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0KDI003BUQUY4PC5@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 23:25:46 +0800 (SGT) Received: from [192.18.19.175] (Forwarded-For: [129.150.144.31]) by sedge1-mail1.singapore.sun.com (mshttpd); Thu, 15 Jan 2009 23:25:46 +0800 Date: Thu, 15 Jan 2009 23:25:46 +0800 From: Xiang Samuel Zhou Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <18799.13055.277845.373212@gargle.gargle.HOWL> To: James Carlson Cc: Edward Pilatowicz , PSARC-ext@Sun.COM, Jim Walker Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-PMX-Version: 5.4.1.325704 References: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> <18799.13055.277845.373212@gargle.gargle.HOWL> Status: RO Content-Length: 2190 ----- Original Message ----- From: James Carlson Date: Thursday, January 15, 2009 8:58 pm Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] To: Xiang Zhou Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker > Xiang Zhou writes: > > On 01/14/09 06:37, Edward Pilatowicz wrote: > > > imho, yes. > > > > > > if iftop has limitations wrt zones, i'd expect that to be > documented.> > (similar to how lack of ipv6 support is documented.) > > > > > > also, if this is the case i'd like to hear that improved > support for > > > zones it being planned. (once again, similar to the ipv6 > situation.)> > > > Here is the update related solaris zones: > > > > Now iftop has limitations with zones. iftop can not work properly > in > > both shared stack zone and exclusive stack zone. Because it > invokes > > DLPI functions. There are no resources available to add support > at this > > time. I will work with the upstream community to provide full > support > > for Solaris zones. > > How does it open DLPI devices? It first use "open" system call to open something like /dev/bge, then send strbuf containing DL_ATTACH_REQ to the opened STREAMS. It uses dlpi device to get the mac address. > > If it doesn't use libdlpi, does it have support for Solaris "vanity > naming," which requires looking in /dev/net/ for the device first? It doesn't looking in /dev/net/, but it seems works ok on renamed link, e.g. the command "iftop -i e1kg1" shows the traffic on e1kg1 where e1kg1 is the renamed name of e1000g1. For capture packets, it uses pcap_open_live to open the interface. It seems libpcap support vanity naming. > > If it doesn't do that, could a fix be contributed back upstream? It's > usually about two lines of code. Make sense. I will deliever the patch in a couple of days. Thanks for your comments. - Xiang > > -- > 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 carlsonj@phorcys.east.sun.com Thu Jan 15 07:33:51 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 n0FFXpDW001734 for ; Thu, 15 Jan 2009 07:33:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0FFXlRX016109; Thu, 15 Jan 2009 07:33:48 -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 <0KDI0011XR8CUX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 07:33:48 -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 <0KDI00LMHR8BDD10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 07:33:48 -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 n0FFXkYc009024; Thu, 15 Jan 2009 10:33:46 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0FFXkLA009021; Thu, 15 Jan 2009 10:33:46 -0500 (EST) Date: Thu, 15 Jan 2009 10:33:46 -0500 From: James Carlson Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: To: Xiang Samuel Zhou Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker Message-id: <18799.22362.692429.642585@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: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> <18799.13055.277845.373212@gargle.gargle.HOWL> Status: RO Content-Length: 1650 Xiang Samuel Zhou writes: > ----- Original Message ----- > From: James Carlson > > How does it open DLPI devices? > It first use "open" system call to open something like /dev/bge, then send strbuf containing DL_ATTACH_REQ to the opened STREAMS. It uses dlpi device to get the mac address. If I'm reading that correctly, it doesn't even support DLPI Style 1. I'm hoping that's wrong, based on the description below, because it'd be a show-stopper of a bug. > > If it doesn't use libdlpi, does it have support for Solaris "vanity > > naming," which requires looking in /dev/net/ for the device first? > It doesn't looking in /dev/net/, but it seems works ok on renamed link, e.g. the command "iftop -i e1kg1" shows the traffic on e1kg1 where e1kg1 is the renamed name of e1000g1. For capture packets, it uses pcap_open_live to open the interface. It seems libpcap support vanity naming. OK. As long as you're not either delivering your own copy or statically linking it in, you should be fine. Solaris already comes with libpcap, and it (in turn) uses libdlpi and supports vanity naming. > > If it doesn't do that, could a fix be contributed back upstream? It's > > usually about two lines of code. > Make sense. I will deliever the patch in a couple of days. None should be needed if you're not dealing with the /dev entries directly, and are instead going through the normal system libpcap. -- 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 Xiang.Zhou@sun.com Thu Jan 15 08:33: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 n0FGXbYh020409 for ; Thu, 15 Jan 2009 08:33:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FGXSmQ023772 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 15 Jan 2009 16:33:36 GMT 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 <0KDI00B0XTZYS200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 08:33:34 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI0056GTZWPF80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 08:33:33 -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 n0FGXW4M004931 for ; Thu, 15 Jan 2009 16:33:32 +0000 (GMT) Received: from sun.com ([129.158.123.8]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0KDI0038XTZW4PG5@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Jan 2009 00:33:32 +0800 (SGT) Received: from [192.18.19.175] (Forwarded-For: [129.150.144.31]) by sedge1-mail1.singapore.sun.com (mshttpd); Fri, 16 Jan 2009 00:33:32 +0800 Date: Fri, 16 Jan 2009 00:33:32 +0800 From: Xiang Samuel Zhou Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <18799.22362.692429.642585@gargle.gargle.HOWL> To: James Carlson Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-PMX-Version: 5.4.1.325704 References: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> <18799.13055.277845.373212@gargle.gargle.HOWL> <18799.22362.692429.642585@gargle.gargle.HOWL> Status: RO Content-Length: 2816 ----- Original Message ----- From: James Carlson Date: Thursday, January 15, 2009 11:33 pm Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] To: Xiang Samuel Zhou Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker > Xiang Samuel Zhou writes: > > ----- Original Message ----- > > From: James Carlson > > > How does it open DLPI devices? > > It first use "open" system call to open something like /dev/bge, > then send strbuf containing DL_ATTACH_REQ to the opened STREAMS. It > uses dlpi device to get the mac address. > > If I'm reading that correctly, it doesn't even support DLPI Style 1. > I'm hoping that's wrong, based on the description below, because it'd > be a show-stopper of a bug. iftop ONLY use these codes to get the mac address. For other operations on interface, it uses functions in libpcap. I tried to remove the codes to get mac address. it works ok in global zone and non-global exclusive zone. Further, if I remove all the definations in dlpi.h and do not include dlpi.h in source code, the compiled binary works good for exclusive zone and vanity naming. > > > > If it doesn't use libdlpi, does it have support for Solaris > "vanity> > naming," which requires looking in /dev/net/ for the > device first? > > It doesn't looking in /dev/net/, but it seems works ok on renamed > link, e.g. the command "iftop -i e1kg1" shows the traffic on e1kg1 > where e1kg1 is the renamed name of e1000g1. For capture packets, it > uses pcap_open_live to open the interface. It seems libpcap support > vanity naming. > > OK. As long as you're not either delivering your own copy or > statically linking it in, you should be fine. Solaris already comes > with libpcap, and it (in turn) uses libdlpi and supports vanity > naming. > > > > If it doesn't do that, could a fix be contributed back > upstream? It's > > > usually about two lines of code. > > Make sense. I will deliever the patch in a couple of days. > > None should be needed if you're not dealing with the /dev entries > directly, and are instead going through the normal system libpcap. Right, could it be ok to fix the issue: removed the code dealing with /dev and /dev/net entries which is used for dlpi operation, do not use functions and definations in dlpi.h, and make all packet capture works depend on libpcap? Because the code just use dlpi.h interfaces to get mac address which is not an important information of iftop. Thanks! - Xiang > > -- > 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 carlsonj@phorcys.east.sun.com Thu Jan 15 08:54:57 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 n0FGsuuc021041 for ; Thu, 15 Jan 2009 08:54:57 -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 n0FGsZVF016500; Fri, 16 Jan 2009 00:54:52 +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 <0KDI00B1JUZEQG00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 08:54:50 -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 <0KDI00LSYUZ9DB90@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 08:54:46 -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 n0FGsjRw009508; Thu, 15 Jan 2009 11:54:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0FGsjC2009505; Thu, 15 Jan 2009 11:54:45 -0500 (EST) Date: Thu, 15 Jan 2009 11:54:45 -0500 From: James Carlson Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: To: Xiang Samuel Zhou Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker Message-id: <18799.27221.285426.876513@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: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> <18799.13055.277845.373212@gargle.gargle.HOWL> <18799.22362.692429.642585@gargle.gargle.HOWL> Status: RO Content-Length: 1844 Xiang Samuel Zhou writes: > > If I'm reading that correctly, it doesn't even support DLPI Style 1. > > I'm hoping that's wrong, based on the description below, because it'd > > be a show-stopper of a bug. > iftop ONLY use these codes to get the mac address. For other operations on interface, it uses functions in libpcap. > I tried to remove the codes to get mac address. it works ok in global zone and non-global exclusive zone. Further, if I remove all the definations in dlpi.h and do not include dlpi.h in source code, the compiled binary works good for exclusive zone and vanity naming. I think we're getting down below architectural review. If you can send me a pointer to the original code and your changes, I'll look at it to see if there are problems here. The architectural issue, though, is that DLPI applications need to support both Style 1 and Style 2 in order to work properly on Solaris, and should also support vanity naming to avoid confusion. How you go about achieving that is separate. > > None should be needed if you're not dealing with the /dev entries > > directly, and are instead going through the normal system libpcap. > Right, could it be ok to fix the issue: removed the code dealing with /dev and /dev/net entries which is used for dlpi operation, do not use functions and definations in dlpi.h, and make all packet capture works depend on libpcap? Because the code just use dlpi.h interfaces to get mac address which is not an important information of iftop. I'm not sure what you mean by "important" here, but getting the hardware (mac) address through libdlpi is pretty simple. -- 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 Xiang.Zhou@sun.com Thu Jan 15 20:48:28 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 n0G4mRCh029168 for ; Thu, 15 Jan 2009 20:48:28 -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 n0G4mOq0016933 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Jan 2009 12:48:26 +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 <0KDJ00H0RS0OPQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 20:48:24 -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 <0KDJ00E2ES0LOO70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 15 Jan 2009 20:48:22 -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 n0G4mLnV007991 for ; Fri, 16 Jan 2009 04:48:21 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0KDJ00A01RZYDL00@mail-apac.sun.com> (original mail from Xiang.Zhou@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Jan 2009 12:48:21 +0800 (SGT) Received: from [129.158.219.227] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KDJ00G05S0JHZE0@mail-apac.sun.com>; Fri, 16 Jan 2009 12:48:20 +0800 (SGT) Date: Fri, 16 Jan 2009 12:47:46 +0800 From: Xiang Zhou Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <18799.27221.285426.876513@gargle.gargle.HOWL> Sender: Xiang.Zhou@sun.com To: James Carlson Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker Message-id: <49701172.2000608@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qlAPL33xfuROnx+0aHFR3Q)" X-PMX-Version: 5.4.1.325704 References: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> <18799.13055.277845.373212@gargle.gargle.HOWL> <18799.22362.692429.642585@gargle.gargle.HOWL> <18799.27221.285426.876513@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (X11/20080407) Status: RO Content-Length: 5318 This is a multi-part message in MIME format. --Boundary_(ID_qlAPL33xfuROnx+0aHFR3Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 01/16/09 00:54, James Carlson wrote: > Xiang Samuel Zhou writes: > >>> If I'm reading that correctly, it doesn't even support DLPI Style 1. >>> I'm hoping that's wrong, based on the description below, because it'd >>> be a show-stopper of a bug. >>> >> iftop ONLY use these codes to get the mac address. For other operations on interface, it uses functions in libpcap. >> I tried to remove the codes to get mac address. it works ok in global zone and non-global exclusive zone. Further, if I remove all the definations in dlpi.h and do not include dlpi.h in source code, the compiled binary works good for exclusive zone and vanity naming. >> > > I think we're getting down below architectural review. If you can > send me a pointer to the original code and your changes, I'll look at > it to see if there are problems here. > OK. The original code have been exacted at /net/flowerpath.prc/export/home/iftop/b/iftop-0.17/ The changed code directory: /net/flowerpath.prc/export/home/iftop/a/iftop-0.17/ And here is the patch(diff -ur output): /net/flowerpath.prc/export/home/iftop/to.patch Thank you for helping me to look into the code. - Xiang > The architectural issue, though, is that DLPI applications need to > support both Style 1 and Style 2 in order to work properly on Solaris, > and should also support vanity naming to avoid confusion. How you go > about achieving that is separate. > > >>> None should be needed if you're not dealing with the /dev entries >>> directly, and are instead going through the normal system libpcap. >>> >> Right, could it be ok to fix the issue: removed the code dealing with /dev and /dev/net entries which is used for dlpi operation, do not use functions and definations in dlpi.h, and make all packet capture works depend on libpcap? Because the code just use dlpi.h interfaces to get mac address which is not an important information of iftop. >> > > I'm not sure what you mean by "important" here, but getting the > hardware (mac) address through libdlpi is pretty simple. > -- Best Regards, Xiang --Boundary_(ID_qlAPL33xfuROnx+0aHFR3Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 01/16/09 00:54, James Carlson wrote: 
Xiang Samuel Zhou writes:
  
If I'm reading that correctly, it doesn't even support DLPI Style 1.
I'm hoping that's wrong, based on the description below, because it'd
be a show-stopper of a bug.
      
iftop ONLY use these codes to get the mac address. For other operations on interface, it uses functions in libpcap.
I tried to remove the codes to get mac address. it works ok in global zone and non-global exclusive zone. Further, if I remove all the definations in dlpi.h and do not include dlpi.h in source code, the compiled binary works good for exclusive zone and vanity naming.
    

I think we're getting down below architectural review.  If you can
send me a pointer to the original code and your changes, I'll look at
it to see if there are problems here.
OK. The original code have been exacted at
/net/flowerpath.prc/export/home/iftop/b/iftop-0.17/
The changed code directory:
/net/flowerpath.prc/export/home/iftop/a/iftop-0.17/
And here is the patch(diff -ur output):
/net/flowerpath.prc/export/home/iftop/to.patch

Thank you for helping me to look into the code.

- Xiang

The architectural issue, though, is that DLPI applications need to
support both Style 1 and Style 2 in order to work properly on Solaris,
and should also support vanity naming to avoid confusion.  How you go
about achieving that is separate.

  
None should be needed if you're not dealing with the /dev entries
directly, and are instead going through the normal system libpcap.
      
Right, could it be ok to fix the issue: removed the code dealing with /dev and /dev/net entries which is used for dlpi operation, do not use functions and definations in dlpi.h, and make all packet capture works depend on libpcap? Because the code just use dlpi.h interfaces to get mac address which is not an important information of iftop.
    

I'm not sure what you mean by "important" here, but getting the
hardware (mac) address through libdlpi is pretty simple.
  

-- 
Best Regards,
Xiang
--Boundary_(ID_qlAPL33xfuROnx+0aHFR3Q)-- From edward.pilatowicz@Sun.COM Fri Jan 16 09:55:05 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 n0GHt4jG004351 for ; Fri, 16 Jan 2009 09:55:04 -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 n0GHsxmq030683; Fri, 16 Jan 2009 10:55:01 -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 <0KDK00I0JSFOZ100@nwk-avmta-2.sfbay.sun.com>; Fri, 16 Jan 2009 09:55:00 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDK00GC9SFOWV20@nwk-avmta-2.sfbay.sun.com>; Fri, 16 Jan 2009 09:55:00 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0GHsxNa232160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 09:54:59 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n0GHsxKQ232157; Fri, 16 Jan 2009 09:54:59 -0800 (PST) Date: Fri, 16 Jan 2009 09:54:59 -0800 From: Edward Pilatowicz Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: To: Xiang Samuel Zhou Cc: James Carlson , PSARC-ext@Sun.COM, Jim Walker Message-id: <20090116175459.GA229062@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901130832.n0D8Wb1d028739@sac.sfbay.sun.com> <20090113220356.GC436257@eng.sun.com> <496D1B7A.60404@sun.com> <20090113223752.GE436257@eng.sun.com> <496F0DD1.4010301@Sun.COM> <18799.13055.277845.373212@gargle.gargle.HOWL> <18799.22362.692429.642585@gargle.gargle.HOWL> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1673 On Fri, Jan 16, 2009 at 12:33:32AM +0800, Xiang Samuel Zhou wrote: > > ----- Original Message ----- > From: James Carlson > Date: Thursday, January 15, 2009 11:33 pm > Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] > To: Xiang Samuel Zhou > Cc: Edward Pilatowicz , PSARC-ext@sun.com, Jim Walker > > > Xiang Samuel Zhou writes: > > > ----- Original Message ----- > > > From: James Carlson > > > > How does it open DLPI devices? > > > It first use "open" system call to open something like /dev/bge, > > then send strbuf containing DL_ATTACH_REQ to the opened STREAMS. It > > uses dlpi device to get the mac address. > > > > If I'm reading that correctly, it doesn't even support DLPI Style 1. > > I'm hoping that's wrong, based on the description below, because it'd > > be a show-stopper of a bug. > iftop ONLY use these codes to get the mac address. For other operations on interface, it uses functions in libpcap. > I tried to remove the codes to get mac address. it works ok in global zone and non-global exclusive zone. Further, if I remove all the definations in dlpi.h and do not include dlpi.h in source code, the compiled binary works good for exclusive zone and vanity naming. > this is really good news. if at all possible, it'd be great if you could include these changes in your integrated version of itop and try to contribute those changes back to the community. regardless of if you include these changes, i'd like you to update the man pages delivered with iftop to document any limitations wrt zones. thanks ed From Sebastien.Roy@sun.com Wed Jan 21 11:16:04 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 n0LJG472001125 for ; Wed, 21 Jan 2009 11:16:04 -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 n0LJFq3H002787 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jan 2009 11:16:04 -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 <0KDU00L095ILBS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 11:15:57 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDU00I825IKPT40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 11:15:56 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0LJFu3J003089 for ; Wed, 21 Jan 2009 19:15:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDU00G013XEMG00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 12:15:55 -0700 (MST) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDU00EG75IDFI90@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 12:15:49 -0700 (MST) Date: Wed, 21 Jan 2009 14:15:38 -0500 From: Sebastien Roy Subject: re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <18797.40375.475300.25562@gargle.gargle.HOWL> Sender: Sebastien.Roy@sun.com To: Peter.Memishian@sun.com Cc: PSARC-ext@sun.com, Xiang.Zhou@sun.com Message-id: <1232565338.10652.44.camel@strat> 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: <18797.40375.475300.25562@gargle.gargle.HOWL> Status: RO Content-Length: 487 On Wed, 2009-01-14 at 03:09 -0500, Peter Memishian wrote: > Unlike many other Unix variants, Solaris draws a clear separation between > an IP interface and a datalink. Which is iftop providing information > about? Further, what APIs does it use to get this information? (I don't > see any mention in the Interfaces section.) I asked for more time on this case at today's PSARC meeting since I never saw answers to these questions. Can the project team please address these? -Seb From James.Walker@sun.com Wed Jan 21 11:44:43 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 n0LJihlO011406 for ; Wed, 21 Jan 2009 11:44:43 -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 n0LJig73018804 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Jan 2009 11:44:43 -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 <0KDU00K196UISK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 12:44:42 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDU00GSG6UIS230@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 12:44:42 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0LJigaD024885 for ; Wed, 21 Jan 2009 19:44:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDU00L015VZ8800@mail-amer.sun.com> (original mail from James.Walker@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 12:44:42 -0700 (MST) Received: from [172.20.25.153] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDU00LVM6T23O70@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Jan 2009 12:43:50 -0700 (MST) Date: Wed, 21 Jan 2009 13:08:36 -0700 From: Jim Walker Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 01/20/2009] In-reply-to: <1232565338.10652.44.camel@strat> Sender: James.Walker@sun.com To: Sebastien Roy Cc: Peter.Memishian@sun.com, PSARC-ext@sun.com, Xiang.Zhou@sun.com Reply-to: James.Walker@sun.com Message-id: <497780C4.7030907@sun.com> Organization: Sun Microsystems, Inc. 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: <18797.40375.475300.25562@gargle.gargle.HOWL> <1232565338.10652.44.camel@strat> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 687 Sebastien Roy wrote: > On Wed, 2009-01-14 at 03:09 -0500, Peter Memishian wrote: >> Unlike many other Unix variants, Solaris draws a clear separation between >> an IP interface and a datalink. Which is iftop providing information >> about? Further, what APIs does it use to get this information? (I don't >> see any mention in the Interfaces section.) > > I asked for more time on this case at today's PSARC meeting since I > never saw answers to these questions. Can the project team please > address these? I wasn't able to make the meeting today, but was planning to extend the timeout also, to make sure everything PSARC wise was addressed. I'll check with Xiang. Cheers, Jim From James.Walker@Sun.COM Wed Feb 11 09:53:48 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 n1BHrlva005445 for ; Wed, 11 Feb 2009 09:53:47 -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 n1BHrjd9027064 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 01:53:46 +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 <0KEW00A07XPK9H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 09:53:44 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEW00KNEXPH1O90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 09:53:42 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1BHrfYN027538 for ; Wed, 11 Feb 2009 17:53:41 +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 <0KEW00J00XI6MR00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 10:53:41 -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 <0KEW008C4XP9HZK0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 10:53:34 -0700 (MST) Date: Wed, 11 Feb 2009 11:20:46 -0700 From: Jim Walker Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 02/06/2009] Sender: James.Walker@Sun.COM To: PSARC-ext@Sun.COM Cc: Xiang Zhou Reply-to: James.Walker@Sun.COM Message-id: <499316FE.6060309@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 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 799 Offlist Xiang worked out the iftop zone support with Jim Carlson, Ed Pilatowicz and Sebastien Roy, and has a working prototype. Since all issues have been addressed and the timeout has occurred, I will mark this case closed approved. I plan to add this note to the case directory. Cheers, Jim +++ iftop zone support Unlike many other Unix variants, Solaris draws a clear separation between an IP interface and a datalink. iftop will support the IP and datalink interfaces in global zones, and support only the IP interface in exclusive zones and with vanity naming. It will use libpcap, socket API, and ioctls with the IP interface. The DLPI interface included with iftop will be removed. All changes will be sent to the upstream community, and the man pages will be updated accordingly. From James.Walker@Sun.COM Wed Feb 11 10:12: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 n1BICfEc008083 for ; Wed, 11 Feb 2009 10:12: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 n1BICdje013878 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Feb 2009 10:12:41 -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 <0KEW00D3XYL4HO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 10:12:40 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEW00B1FYL2GN50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 10:12:38 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1BICcR4008003 for ; Wed, 11 Feb 2009 18:12:38 +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 <0KEW00L00WD7R500@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 11:12:38 -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 <0KEW00AASYKWE070@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 11:12:32 -0700 (MST) Date: Wed, 11 Feb 2009 11:39:45 -0700 From: Jim Walker Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 02/06/2009] Sender: James.Walker@Sun.COM To: PSARC-ext@Sun.COM Cc: Xiang Zhou Reply-to: James.Walker@Sun.COM Message-id: <49931B71.5080006@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 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 61 This case was approved at todays PSARC meeting. Cheers, Jim From Xiang.Zhou@sun.com Wed Feb 11 19:08:00 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 n1C37xkB024388 for ; Wed, 11 Feb 2009 19:08: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 n1C37ixu026418 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 12 Feb 2009 11:07:58 +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 <0KEX00D01ND7A300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 19:07:55 -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 <0KEX003NRND6VR40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Feb 2009 19:07:55 -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 n1C37rVV028996 for ; Thu, 12 Feb 2009 03:07:53 +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 <0KEX00B00MZG0J00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Feb 2009 11:07:53 +0800 (SGT) Received: from [129.158.219.227] ([unknown] [129.158.219.227]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEX000P7NCVPYA0@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Feb 2009 11:07:44 +0800 (SGT) Date: Thu, 12 Feb 2009 11:06:31 +0800 From: Xiang Zhou Subject: Re: iftop [PSARC/2009/018 FastTrack timeout 02/06/2009] In-reply-to: <499316FE.6060309@sun.com> Sender: Xiang.Zhou@sun.com To: James.Walker@sun.com Cc: PSARC-ext@sun.com Message-id: <49939237.401@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: <499316FE.6060309@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080407) Status: RO Content-Length: 946 On 02/12/09 02:20, Jim Walker wrote: > Offlist Xiang worked out the iftop zone support with Jim Carlson, > Ed Pilatowicz and Sebastien Roy, and has a working prototype. Great! Thank you all for the help! - Xiang > > Since all issues have been addressed and the timeout has occurred, > I will mark this case closed approved. > > I plan to add this note to the case directory. > > Cheers, > Jim > > +++ > > iftop zone support > > Unlike many other Unix variants, Solaris draws a clear separation between > an IP interface and a datalink. > > iftop will support the IP and datalink interfaces in global zones, and > support only the IP interface in exclusive zones and with vanity naming. > It will use libpcap, socket API, and ioctls with the IP interface. The > DLPI interface included with iftop will be removed. > > All changes will be sent to the upstream community, and the man pages > will be updated accordingly. > -- Best Regards, Xiang