From sacadmin Fri Apr 10 13:55:17 2009 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 n3AKtHBR000540; Fri, 10 Apr 2009 13:55:17 -0700 (PDT) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3AKtG88000536; Fri, 10 Apr 2009 13:55:16 -0700 (PDT) Date: Fri, 10 Apr 2009 13:55:16 -0700 (PDT) From: Darren Reed Message-Id: <200904102055.n3AKtG88000536@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Berkeley Packet Filter for OpenSolaris [PSARC/2009/232 FastTrack timeout 4/24/09] Status: RO Content-Length: 571 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: Berkeley Packet Filter for OpenSolaris 1.2. Name of Document Author/Supplier: Author: Darren Reed 1.3 Date of This Document: 10 April, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@Sun.COM Fri Apr 10 14:01:24 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 n3AL1N2n000745 for ; Fri, 10 Apr 2009 14:01:23 -0700 (PDT) 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 n3AL1LjK026328 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 11 Apr 2009 05:01:22 +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 <0KHW00805L29WN00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:01:21 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW005UQL28TF10@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:01:20 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3AL1Jbe026848 for ; Fri, 10 Apr 2009 21:01:19 +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-5.01 64bit (built Feb 19 2009)) id <0KHW00600L1BYE00@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 22:01:19 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHW006XFL26T8A0@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 22:01:19 +0100 (BST) Date: Fri, 10 Apr 2009 14:01:17 -0700 From: Darren Reed Subject: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris Sender: Darren.Reed@Sun.COM To: psarc-ext@Sun.COM Message-id: <49DFB39D.1020301@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 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 19283 This is a self sponsored fast track, timeout set for 2 weeks... Abstract ======== This case seeks to build on the Crossbow (PSARC/2006/357[7]) infrastructure and provide a new (to OpenSolaris) mechanism for capturing packets: the use of the Berkeley Packet Filter (BPF). The goal of this project is to provide a method to capture packets that has higher performance than what we have to offer today on Solaris (DLPI based schemes.) It also has the added benefit of increasing our compatibility with other software that has been built to use BPF. Release Binding --------------- This case seeks to obtain approval for minor release binding. Background ========== Packet capture on Solaris is currently built around the use of DLPI. Whilst the introduction of libdlpi (PSARC/2006/436[1]) has made it easier to program using DLPI and the IP Observability Project (PSARC/2006/475[2]) introduced the means by which packets that are local to the host could be intercepted, neither did anything to address the primary problem with DLPI: compared to other mechanisms, it is slow, the in-kernel filtering is either not used or very primitive and provides very little useful information about the packet capturing itself by way of statistics. Introduction ============ The architecture of BPF lends itself to more efficient means of doing packet capture, where a single read can transfer large numbers of packets per call. It also allows the sniffer to choose how much data from each packet they wish to copy, be it the entire packet or just the first 128 bytes to capture headers. Internal Architecture ~~~~~~~~~~~~~~~~~~~~~ Internally, the architecture of BPF is very simple: it has a lower half that receives packets from the NIC drivers, copying matching packets into a static buffer and an upper half that implements a character pseudo-device. Buffers ------- The backing for the pseudo-device operating as a character device is a buffer allocated by the driver for storing packet data in. The buffersize used by the device for storing copied packet data in is set by the application. By default libpcap sets this size the the same size as the driver's default: 32k. The maximum this project allows is 16M. Two buffers of this size are allocated by the driver: an "active" buffer and a "hold" buffer. This supports applications doing sleeping reads, if they aren't using poll, and reading an entire buffer of data whilst the system continues to catch new packets. Applications can set the buffer size using libpcap or with the BIOCSBLEN ioctl (see man page.) List of Interfaces ------------------ BPF maintains an internal list of network interfaces that it supports capturing packets for. What distinguishes this list from that either in the mac or ip modules is that it uses the datalink type as a part of the key for determining what is an identical entry. Additionally, on OpenSolaris the device structure used inside of the ip module is different to the mac module, preventing either one being used as a master list by BPF. Answering queries such as returning the complete list of datalink types supported by a device (BIOCGDLTLIST), would be much more complicated without that internal list. Packet Capture -------------- When BPF is called from the mac layer, it is handed the packet as it is received from the NIC driver as part of the promiscuous callback handling in the mac layer. It is the same mblk_t for the packet that will later be passed on though the stack and has neither the mblk_t's nor dblk_t's duplicated. Thus the capturing of the packet becomes part of the execution of the datapath for each packet. Interactions with existing technology in Solaris ================================================ This section goes into detail about what impact this project has on other areas of Solaris or what impact they have on this project. Vanity Naming ~~~~~~~~~~~~~ The Vanity Naming Project[6] introduced the means by which link names could be changed to be a different name than the underlying mac name. This project will only support packet capture on interfaces using the interface name allocated by the dls module that was delivered by the vanity naming project. IP Observability ~~~~~~~~~~~~~~~~ The IP observerability project introduced the ability to capture packets from within IP, presenting them through devices files in /dev/ipnet for libdlpi to use. This project will update some of the interfaces introduced by IP observability. Updating IPNET -------------- Unfortunately the mechanism used to do this is bound up within IP. To build upon the work done here, this project will change the mechanism by which IP observability works within IP to use the netinfo (PSARC/2008/219[3]), enabling external kernel modules to easily subscribe to the packet events that make up this feature. A single new event will be added, NH_OBSERVING. Callbacks that are activated with this event will receive a pointer to a hook_pkt_observe_t structure as the hook_data_t value. This project will introduce a version 2 of the IPNET "protocol", with an updated header. Selection of version 1 (the existing version of IPNET headers) or version 2 will be achieved using the DLIOCIPNETINFO ioctl on the /dev/ipnet STREAMS device. The version bump with IPNET is required to maintain backward compatibility with the current interface delivered and described with lo0(7d) - it is currently a Committed interface. mac networking layer ~~~~~~~~~~~~~~~~~~~~ The design of BPF on BSD places it in the MAC layer where it has easy access to functions to enable/disable promiscuous mode and the data structures used to represent network interfaces. Promiscuous callbacks --------------------- This project does not add or change any of the existing promiscuous callbacks that exist in the mac module. On the receive side, the promiscuous callbacks have been placed in the mac module early in the receive path, before any classification work is done on the packet. This means that packet sniffing will happen at line rate but still in accordance to how the NIC has been programmed to queue packets on its rings. On the transmit side, the promiscuous callbacks are activated before a packet packet is classified and put in the appropriate descriptor ring for transmission. Existing Interfaces ------------------ With the mac layer presented by Crossbow, most of the necessary features are provided, albeit via private interfaces: dls_mgmt_get_linkid mac_client_close mac_client_handle_t mac_client_name - returns the name associated with the mac_client object mac_client_open mac_handle_t - value returned by a successful call to mac_open that is used with calls to other functions in the mac layer mac_multicast_add - add another multicast address to the interface mac_multicast_remove - remove a multicast address from the interface mac_name - renames the name of the MAC device (can be different to the name returned by mac_client_name) mac_open mac_promisc_add - enable receipt of packets "promiscuously" via callbacks mac_promisc_handle_t mac_promisc_remove - disable callbacks for packets mac_sdu_get - returns the MTU for a MAC mac_tx - deliver a packet New Interfaces -------------- BPF requires notification about each NIC that gets added, its datalink type and length of the hardware address. It uses this information to maintain an internal list of network interfaces that are available for capturing packets on. To support this, it is necessary to call into BPF from mac inside of mac_register() and mac_unregister(). This is done using a function pointer that is set by calling a new function called mac_set_bpfattach(). This function will take two parameters, one is the function to call when attaching (mac_register), the other is the function to call when detaching (mac_unregister). To account for the fact that drivers may have already called mac_register() before mac_set_bpfattach() is called, mac_set_bpfattach() will walk through all existing attached devices and call bpfattach() for each one of those. This approach is necessary due to the lack of a mechanism equivalent to netinfo's NE_PLUMB/NE_UNPLUMB events for IP, which will be used to support IPNET. Whilst the interface mentioned here is private, it's listed here for completeness. mac_set_bpfattach - set function pointers to be called when drivers call mac_register An additional change is required in the mac module to improve performance: the introduction of a new promiscuous callback flag: MAC_PROMISC_FLAGS_NO_COPY. By default, the current mode of operation when registering a callback with the mac module today using mac_promisc_add will perform a copymsg() on every packet passed in. When peek'ing at packets, such as what BPF does, it isn't necessary to create a new mblk_t as BPF does not perform any destructive operations on the packet. When this flag is presented with MAC_PROMISC_FLAGS_VLAN_TAG_STRIP, the behaviour is to fall back to doing the copymsg(). MAC_PROMISC_FLAGS_NO_COPY - promiscuous callback is well behaved and does not need a copy of the packet libpcap ~~~~~~~ This project will update the copy of libpcap delivered by PSARC/2008/288[5] to use the BPF interface delivered with this project. A follow on project may look at extending the libpcap filtering langauge to easily allow filtering on the IPNET header fields. snoop ~~~~~ While implementation of snoop will continue to use DLPI via libdlpi to retrieve packets, it will be updated to understand version 2 of the IPNET packet headers and by default will use this version when communicating with devices in /dev/ipnet. Support for understanding the existing version 1 headers will remain. libnet ~~~~~~ The implementation of libnet delivered into the SFW consolidation by PSARC/2008/409 will not be modified as a part of this case. etherstubs ~~~~~~~~~~ When an etherstub is being used as the locus for a vnic, it will be possible to see the network traffic on the vnic that: - is broadcast or multicast at the link layer - is moving between zones that are using vnic's on top of the etherstub driver to support an exclusive instance of IP It will not be possible to see link layer traffic for IP traffic between two local zones that are using a shared stack, or even multiple vnics in the global zone. To obesrve that traffic, the IPNET link layer must be specified. New Interfaces ============== This section looks at each of the new interfaces being introduced. Those that are described in the man page, bpf.7d, are not discussed here. Loopback DLT type ~~~~~~~~~~~~~~~~~ With the provision of access to loopback data by adapting the mechanism used for ipnet, access to packets on the loopback interface as well as those inside of IP moving between zones using a shared stack instance model can be achieved. For each network interface that is used with the IP protocols, a tap point will be created with a new different datalink type. The datalink type for this will be DLT_LOOP_SOLARIS. Both the structure contents and datalink type name will be registered with the tcpdump project[4]. The packet header structure used with DLT_LOOP_SOLARIS will be the same as used with version 2 of the IP Observability devices in the /dev/ipnet directory. The proposed structure will be called dl_ipnetinfo_v2_t and the details pertaining to it can be found below. /dev/bpf ~~~~~~~~ This driver ships using /dev/bpf as the device file for applications to open. Whilst the creation of the device cannot be as a clone (it is not a STREAMS driver), it is still possible for the driver to assign a new minor number each time the device is opened. Thus even though the driver isn't a clone driver, it is not necessary to have /dev/bpf0-15 for proper BPF semantics. driver.conf file ~~~~~~~~~~~~~~~~ This project intends to use the driver.conf as the means by which the default and maximum buffer sizes can be changed. By default these are 32k and 16M repectively. They can be changed using the names "buf_size" and "max_buf_size". It is not envisaged that these will ever need changing but scope is provided for those that either need or wish to. Whilst there are numerous new avenues being explored for datalink and IP administration, it needs to be remembered that whilst this device is centered around networking, it is neither a datalink nor an IP interface and thus isn't managed by dladm and friends. The need to change (increase) the value from that shipped is expected to be a rare event. ~~~~~~~~~~~ This file contains all of the structure and ioctl definitions that make up the programming interface for BPF. Four of the ioctls listed below are being introduced as "Project Private" as they form the foundation for supporting 32bit applications running against 64bit kernels. This is necessary because some of the structures exchanged between the bpf driver and applications contain pointers. ~~~~~~~~~~~~~~~ This is file contains the definitions for structures used in the kernel and is thus private to the project. Manual page ~~~~~~~~~~~ The manual page for bpf will be delivered to section 7d. A copy from BSD is provided with this case. Interface Table ~~~~~~~~~~~~~~~ Interface Commitment Comments --------------------- ---------------- ------------- usr/kernel/drv/bpf Project Private usr/kernel/drv/bpf.conf Project Private /dev/bpf Uncommitted Committed Project Private BPF_MAJOR_VERSION Committed BPF_MINOR_VERSION Committed BIOCGBLEN Committed BIOCSBLEN Committed BIOCSETF Committed BIOCFLUSH Committed BIOCPROMISC Committed BIOCGDLT Committed BIOCGETIF Committed BIOCSETIF Committed BIOCSORTIMEOUT Committed BIOCGORTIMEOUT Committed BIOCGSTATS Committed BIOCIMMEDIATE Committed BIOCVERSION Committed BIOCSTCPF Committed BIOCSUDPF Committed BIOCGHDRCMPLT Committed BIOCSHDRCMPLT Committed BIOCSDLT Committed BIOCGDLTLIST Committed BIOCGSEESENT Committed BIOCSSEESENT Committed BIOCSRTIMEOUT Committed BIOCGRTIMEOUT Committed BBIOCSETF32 Project private BIOCGDLTLIST32 Project private BIOCSRTIMEOUT32 Project private BIOCGRTIMEOUT32 Project private struct bpf_dltlist Committed struct bpf_hdr Committed struct bpf_insn Committed struct bpf_program Committed struct bpf_stat Committed struct bpf_timeval Committed struct bpf_version Committed NH_OBSERVING Committed hook_pkt_observe_t Committed DLT_LOOP_SOLARIS Committed dl_ipnetinfo_v2_t Committed Structure Definitions ~~~~~~~~~~~~~~~~~~~~~ struct bpf_dltlist ------------------ struct bpf_dltlist { u_int bfl_len; /* number of bfd_list array */ u_int *bfl_list; /* array of DLTs */ }; struct bpf_hdr -------------- struct bpf_hdr { struct bpf_timeval bh_tstamp; /* time stamp */ uint32_t bh_caplen; /* length of captured portion */ uint32_t bh_datalen; /* original length of packet */ uint16_t bh_hdrlen; /* length of bpf header (this struct plus alignment padding) */ }; struct bpf_insn --------------- struct bpf_insn { uint16_t code; /* Instruction */ u_char jt; /* Jump true */ u_char jf; /* Jump false */ uint32_t k; /* space for constant */ }; struct bpf_stat --------------- struct bpf_stat { uint64_t bs_recv; /* number of packets received */ uint64_t bs_drop; /* number of packets dropped */ uint64_t bs_capt; /* number of packets captured */ uint64_t bs_padding[13]; }; struct bpf_timeval ------------------ struct bpf_timeval { int32_t tv_sec; int32_t tv_usec; }; struct bpf_version ------------------ struct bpf_version { u_short bv_major; u_short bv_minor; }; struct bpf_program ------------------ struct bpf_program { u_int bf_len; /* length of program to load */ struct bpf_insn *bf_insns; /* pointer to program to load */ }; Structure supplied with NH_OBSERVE events ----------------------------------------- typedef struct hook_pkt_observe_s { uint8_t hpo_version; uint8_t hpo_family; uint16_t hpo_htype; uint32_t hpo_pktlen; uint32_t hpo_ifindex; uint32_t hpo_grifindex; uint32_t hpo_zsrc; uint32_t hpo_zdst; mblk_t *hpo_pkt; } hook_pkt_observe_t; hpo_family - protocol family (AF_INET/AF_INET6) hpo_zsrc - zone identifier for the source of the packet hpo_zdst - zone identifier for the destination of the packet hpo_ifindex - interface index number hpo_grifindex - group interface index number (for IPMP interfaces) hpo_htype - hook type (in, out, local) hpo_pkt - start of the mblk_t chain with the packet struct dl_ipnetinfo_v2 { uint8_t dli_version; uint8_t dli_family; uint16_t dli_htype; uint32_t dli_pktlen; uint32_t dli_ifindex; uint32_t dli_grifindex; uint32_t dli_zsrc; uint32_t dli_zdst; }; typedef struct dl_ipnetinfo_v2 dl_ipnetinfo_v2_t; dli_version - version number (2) dli_family - protocol family (AF_INET, AF_INET6, etc) dli_htype - hook type (in, out, local) dli_pktlen - length of the packet excluding this header dli_ifindex - interface index number dli_grifindex - group interface index number (for IPMP interfaces) dli_zsrc - zone identifier for the source of the packet dli_zdst - zone identifier for the destination of the packet References ========== [1] http://sac.eng.sun.com/sac/PSARC/2006/436 [2] http://sac.eng.sun.com/sac/PSARC/2006/475, http://opensolaris.org/os/project/clearview/ipnet/ [3] http://arc.opensolaris.org/caselog/PSARC/2008/219 [4] http://www.tcpdump.org/ [5] http://arc.opensolaris.org/caselog/PSARC/2008/288 [6] http://opensolaris.org/os/project/clearview/uv/ [7] http://sac.eng.sun.com/sac/PSARC/2006/357 From Kais.Belgaied@sun.com Fri Apr 10 14:15:59 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 n3ALFwSx001015 for ; Fri, 10 Apr 2009 14:15:59 -0700 (PDT) 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 n3ALFt0X053578; Fri, 10 Apr 2009 15:15:56 -0600 (MDT) 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 <0KHW0000PLQIEY00@brm-avmta-1.central.sun.com>; Fri, 10 Apr 2009 15:15:54 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00HSELQIN120@brm-avmta-1.central.sun.com>; Fri, 10 Apr 2009 15:15:54 -0600 (MDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n3ALFrb9250971; Fri, 10 Apr 2009 14:15:53 -0700 (PDT) Date: Fri, 10 Apr 2009 14:15:53 -0700 From: Kais Belgaied Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <49DFB39D.1020301@Sun.COM> To: Darren Reed Cc: psarc-ext@sun.com Reply-to: Kais.Belgaied@sun.com Message-id: <49DFB709.1000203@Sun.COM> 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: <49DFB39D.1020301@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 20408 Hi Darren, while the architecture looks sound, it has so many pieces and interactions with other subsystems (the pluggale sockets, MAC, etc), way beyond what's suitable for a fasttrack. This should be a full case. Kais. On 04/10/09 14:01, Darren Reed wrote: > This is a self sponsored fast track, timeout set for 2 weeks... > > Abstract > ======== > This case seeks to build on the Crossbow (PSARC/2006/357[7]) > infrastructure > and provide a new (to OpenSolaris) mechanism for capturing packets: the > use of the Berkeley Packet Filter (BPF). The goal of this project is to > provide a method to capture packets that has higher performance than > what we have to offer today on Solaris (DLPI based schemes.) It also has > the added benefit of increasing our compatibility with other software > that has been built to use BPF. > > Release Binding > --------------- > This case seeks to obtain approval for minor release binding. > > Background > ========== > Packet capture on Solaris is currently built around the use of DLPI. > Whilst the introduction of libdlpi (PSARC/2006/436[1]) has made it easier > to program using DLPI and the IP Observability Project > (PSARC/2006/475[2]) > introduced the means by which packets that are local to the host could > be intercepted, neither did anything to address the primary problem > with DLPI: compared to other mechanisms, it is slow, the in-kernel > filtering is either not used or very primitive and provides very > little useful information about the packet capturing itself by way > of statistics. > > Introduction > ============ > > The architecture of BPF lends itself to more efficient means of doing > packet capture, where a single read can transfer large numbers of packets > per call. It also allows the sniffer to choose how much data from each > packet they wish to copy, be it the entire packet or just the first 128 > bytes to capture headers. > > Internal Architecture > ~~~~~~~~~~~~~~~~~~~~~ > Internally, the architecture of BPF is very simple: it has a lower > half that receives packets from the NIC drivers, copying matching > packets into a static buffer and an upper half that implements a > character pseudo-device. > > Buffers > ------- > The backing for the pseudo-device operating as a character device > is a buffer allocated by the driver for storing packet data in. > The buffersize used by the device for storing copied packet data > in is set by the application. By default libpcap sets this size > the the same size as the driver's default: 32k. The maximum this > project allows is 16M. > > Two buffers of this size are allocated by the driver: an "active" > buffer and a "hold" buffer. This supports applications doing > sleeping reads, if they aren't using poll, and reading an entire > buffer of data whilst the system continues to catch new packets. > > Applications can set the buffer size using libpcap or with the > BIOCSBLEN ioctl (see man page.) > > List of Interfaces > ------------------ > BPF maintains an internal list of network interfaces that it supports > capturing packets for. What distinguishes this list from that either > in the mac or ip modules is that it uses the datalink type as a part > of the key for determining what is an identical entry. Additionally, > on OpenSolaris the device structure used inside of the ip module is > different to the mac module, preventing either one being used as a > master list by BPF. Answering queries such as returning the complete > list of datalink types supported by a device (BIOCGDLTLIST), would > be much more complicated without that internal list. > > Packet Capture > -------------- > When BPF is called from the mac layer, it is handed the packet as > it is received from the NIC driver as part of the promiscuous > callback handling in the mac layer. It is the same mblk_t for the > packet that will later be passed on though the stack and has > neither the mblk_t's nor dblk_t's duplicated. Thus the capturing > of the packet becomes part of the execution of the datapath for > each packet. > > Interactions with existing technology in Solaris > ================================================ > This section goes into detail about what impact this project has on > other areas of Solaris or what impact they have on this project. > > Vanity Naming > ~~~~~~~~~~~~~ > The Vanity Naming Project[6] introduced the means by which link names > could be changed to be a different name than the underlying mac name. > This project will only support packet capture on interfaces using the > interface name allocated by the dls module that was delivered by the > vanity naming project. > > IP Observability > ~~~~~~~~~~~~~~~~ > The IP observerability project introduced the ability to capture packets > from within IP, presenting them through devices files in /dev/ipnet for > libdlpi to use. This project will update some of the interfaces > introduced > by IP observability. > > Updating IPNET > -------------- > Unfortunately the mechanism used to do this is bound up within IP. To > build upon the work done here, this project will change the mechanism > by which IP observability works within IP to use the netinfo > (PSARC/2008/219[3]), enabling external kernel modules to easily subscribe > to the packet events that make up this feature. A single new event > will be added, NH_OBSERVING. Callbacks that are activated with this > event will receive a pointer to a hook_pkt_observe_t structure as > the hook_data_t value. > > This project will introduce a version 2 of the IPNET "protocol", with an > updated header. Selection of version 1 (the existing version of IPNET > headers) or version 2 will be achieved using the DLIOCIPNETINFO ioctl > on the /dev/ipnet STREAMS device. > > The version bump with IPNET is required to maintain backward > compatibility > with the current interface delivered and described with lo0(7d) - > it is currently a Committed interface. > > mac networking layer > ~~~~~~~~~~~~~~~~~~~~ > The design of BPF on BSD places it in the MAC layer where it has > easy access to functions to enable/disable promiscuous mode and > the data structures used to represent network interfaces. > > Promiscuous callbacks > --------------------- > This project does not add or change any of the existing promiscuous > callbacks that exist in the mac module. > > On the receive side, the promiscuous callbacks have been placed in the > mac module early in the receive path, before any classification work > is done on the packet. This means that packet sniffing will happen at > line rate but still in accordance to how the NIC has been programmed > to queue packets on its rings. > > On the transmit side, the promiscuous callbacks are activated before a > packet packet is classified and put in the appropriate descriptor ring > for transmission. > > Existing Interfaces > ------------------ > With the mac layer presented by Crossbow, most of the necessary features > are provided, albeit via private interfaces: > > dls_mgmt_get_linkid > mac_client_close > mac_client_handle_t > mac_client_name - returns the name associated with the mac_client object > mac_client_open > mac_handle_t - value returned by a successful call to mac_open that is > used with calls to other functions in the mac layer > mac_multicast_add - add another multicast address to the interface > mac_multicast_remove - remove a multicast address from the interface > mac_name - renames the name of the MAC device (can be different to the > name returned by mac_client_name) > mac_open > mac_promisc_add - enable receipt of packets "promiscuously" via callbacks > mac_promisc_handle_t > mac_promisc_remove - disable callbacks for packets > mac_sdu_get - returns the MTU for a MAC > mac_tx - deliver a packet > > New Interfaces > -------------- > BPF requires notification about each NIC that gets added, its datalink > type and length of the hardware address. It uses this information to > maintain an internal list of network interfaces that are available for > capturing packets on. To support this, it is necessary to call into BPF > from mac inside of mac_register() and mac_unregister(). This is done > using a function pointer that is set by calling a new function called > mac_set_bpfattach(). This function will take two parameters, one is > the function to call when attaching (mac_register), the other is the > function to call when detaching (mac_unregister). To account for the > fact that drivers may have already called mac_register() before > mac_set_bpfattach() is called, mac_set_bpfattach() will walk through > all existing attached devices and call bpfattach() for each one of > those. This approach is necessary due to the lack of a mechanism > equivalent to netinfo's NE_PLUMB/NE_UNPLUMB events for IP, which will > be used to support IPNET. Whilst the interface mentioned here is > private, it's listed here for completeness. > > mac_set_bpfattach - set function pointers to be called when drivers call > mac_register > > An additional change is required in the mac module to improve > performance: > the introduction of a new promiscuous callback flag: > MAC_PROMISC_FLAGS_NO_COPY. > > By default, the current mode of operation when registering a callback > with the mac module today using mac_promisc_add will perform a copymsg() > on every packet passed in. When peek'ing at packets, such as what BPF > does, it isn't necessary to create a new mblk_t as BPF does not perform > any destructive operations on the packet. When this flag is presented > with MAC_PROMISC_FLAGS_VLAN_TAG_STRIP, the behaviour is to fall back > to doing the copymsg(). > > MAC_PROMISC_FLAGS_NO_COPY - promiscuous callback is well behaved and does > not need a copy of the packet > > libpcap > ~~~~~~~ > This project will update the copy of libpcap delivered by > PSARC/2008/288[5] > to use the BPF interface delivered with this project. A follow on project > may look at extending the libpcap filtering langauge to easily allow > filtering on the IPNET header fields. > > snoop > ~~~~~ > While implementation of snoop will continue to use DLPI via libdlpi > to retrieve packets, it will be updated to understand version 2 of > the IPNET packet headers and by default will use this version when > communicating with devices in /dev/ipnet. Support for understanding > the existing version 1 headers will remain. > > libnet > ~~~~~~ > The implementation of libnet delivered into the SFW consolidation by > PSARC/2008/409 will not be modified as a part of this case. > > etherstubs > ~~~~~~~~~~ > When an etherstub is being used as the locus for a vnic, it will be > possible to see the network traffic on the vnic that: > - is broadcast or multicast at the link layer > - is moving between zones that are using vnic's on top of the etherstub > driver to support an exclusive instance of IP > > It will not be possible to see link layer traffic for IP traffic > between two local zones that are using a shared stack, or even > multiple vnics in the global zone. To obesrve that traffic, the > IPNET link layer must be specified. > > New Interfaces > ============== > This section looks at each of the new interfaces being introduced. > Those that are described in the man page, bpf.7d, are not discussed > here. > > Loopback DLT type > ~~~~~~~~~~~~~~~~~ > With the provision of access to loopback data by adapting the mechanism > used for ipnet, access to packets on the loopback interface as well as > those inside of IP moving between zones using a shared stack instance > model can be achieved. > > For each network interface that is used with the IP protocols, a tap > point will be created with a new different datalink type. The datalink > type for this will be DLT_LOOP_SOLARIS. Both the structure contents > and datalink type name will be registered with the tcpdump project[4]. > > The packet header structure used with DLT_LOOP_SOLARIS will be the > same as used with version 2 of the IP Observability devices in the > /dev/ipnet directory. The proposed structure will be called > dl_ipnetinfo_v2_t and the details pertaining to it can be found below. > > /dev/bpf > ~~~~~~~~ > This driver ships using /dev/bpf as the device file for applications > to open. Whilst the creation of the device cannot be as a clone (it > is not a STREAMS driver), it is still possible for the driver to > assign a new minor number each time the device is opened. Thus > even though the driver isn't a clone driver, it is not necessary > to have /dev/bpf0-15 for proper BPF semantics. > > driver.conf file > ~~~~~~~~~~~~~~~~ > This project intends to use the driver.conf as the means by which the > default and maximum buffer sizes can be changed. By default these are > 32k and 16M repectively. They can be changed using the names "buf_size" > and "max_buf_size". It is not envisaged that these will ever need > changing but scope is provided for those that either need or wish to. > > Whilst there are numerous new avenues being explored for datalink and > IP administration, it needs to be remembered that whilst this device is > centered around networking, it is neither a datalink nor an IP interface > and thus isn't managed by dladm and friends. The need to change > (increase) > the value from that shipped is expected to be a rare event. > > > ~~~~~~~~~~~ > This file contains all of the structure and ioctl definitions that make > up the programming interface for BPF. Four of the ioctls listed below > are being introduced as "Project Private" as they form the foundation > for supporting 32bit applications running against 64bit kernels. This > is necessary because some of the structures exchanged between the bpf > driver and applications contain pointers. > > > ~~~~~~~~~~~~~~~ > This is file contains the definitions for structures used in the kernel > and is thus private to the project. > > Manual page > ~~~~~~~~~~~ > The manual page for bpf will be delivered to section 7d. > A copy from BSD is provided with this case. > > Interface Table > ~~~~~~~~~~~~~~~ > Interface Commitment Comments > --------------------- ---------------- ------------- > usr/kernel/drv/bpf Project Private > usr/kernel/drv/bpf.conf Project Private > /dev/bpf Uncommitted > Committed > Project Private > BPF_MAJOR_VERSION Committed > BPF_MINOR_VERSION Committed > BIOCGBLEN Committed > BIOCSBLEN Committed > BIOCSETF Committed > BIOCFLUSH Committed > BIOCPROMISC Committed > BIOCGDLT Committed > BIOCGETIF Committed > BIOCSETIF Committed > BIOCSORTIMEOUT Committed > BIOCGORTIMEOUT Committed > BIOCGSTATS Committed > BIOCIMMEDIATE Committed > BIOCVERSION Committed > BIOCSTCPF Committed > BIOCSUDPF Committed > BIOCGHDRCMPLT Committed > BIOCSHDRCMPLT Committed > BIOCSDLT Committed > BIOCGDLTLIST Committed > BIOCGSEESENT Committed > BIOCSSEESENT Committed > BIOCSRTIMEOUT Committed > BIOCGRTIMEOUT Committed > BBIOCSETF32 Project private > BIOCGDLTLIST32 Project private > BIOCSRTIMEOUT32 Project private > BIOCGRTIMEOUT32 Project private > struct bpf_dltlist Committed > struct bpf_hdr Committed > struct bpf_insn Committed > struct bpf_program Committed > struct bpf_stat Committed > struct bpf_timeval Committed > struct bpf_version Committed > NH_OBSERVING Committed > hook_pkt_observe_t Committed > DLT_LOOP_SOLARIS Committed > dl_ipnetinfo_v2_t Committed > > > Structure Definitions > ~~~~~~~~~~~~~~~~~~~~~ > struct bpf_dltlist > ------------------ > struct bpf_dltlist { > u_int bfl_len; /* number of bfd_list array */ > u_int *bfl_list; /* array of DLTs */ > }; > > struct bpf_hdr > -------------- > struct bpf_hdr { > struct bpf_timeval bh_tstamp; /* time stamp */ > uint32_t bh_caplen; /* length of captured portion */ > uint32_t bh_datalen; /* original length of packet */ > uint16_t bh_hdrlen; /* length of bpf header (this > struct > plus alignment padding) */ > }; > > struct bpf_insn > --------------- > struct bpf_insn { > uint16_t code; /* Instruction */ > u_char jt; /* Jump true */ > u_char jf; /* Jump false */ > uint32_t k; /* space for constant */ > }; > > struct bpf_stat > --------------- > struct bpf_stat { > uint64_t bs_recv; /* number of packets received */ > uint64_t bs_drop; /* number of packets dropped */ > uint64_t bs_capt; /* number of packets captured */ > uint64_t bs_padding[13]; > }; > > struct bpf_timeval > ------------------ > struct bpf_timeval { > int32_t tv_sec; > int32_t tv_usec; > }; > > struct bpf_version > ------------------ > struct bpf_version { > u_short bv_major; > u_short bv_minor; > }; > > struct bpf_program > ------------------ > struct bpf_program { > u_int bf_len; /* length of program to load */ > struct bpf_insn *bf_insns; /* pointer to program to load */ > }; > > Structure supplied with NH_OBSERVE events > ----------------------------------------- > typedef struct hook_pkt_observe_s { > uint8_t hpo_version; > uint8_t hpo_family; > uint16_t hpo_htype; > uint32_t hpo_pktlen; > uint32_t hpo_ifindex; > uint32_t hpo_grifindex; > uint32_t hpo_zsrc; > uint32_t hpo_zdst; > mblk_t *hpo_pkt; > } hook_pkt_observe_t; > > hpo_family - protocol family (AF_INET/AF_INET6) > hpo_zsrc - zone identifier for the source of the packet > hpo_zdst - zone identifier for the destination of the packet > hpo_ifindex - interface index number > hpo_grifindex - group interface index number (for IPMP interfaces) > hpo_htype - hook type (in, out, local) > hpo_pkt - start of the mblk_t chain with the packet > > > struct dl_ipnetinfo_v2 { > uint8_t dli_version; > uint8_t dli_family; > uint16_t dli_htype; > uint32_t dli_pktlen; > uint32_t dli_ifindex; > uint32_t dli_grifindex; > uint32_t dli_zsrc; > uint32_t dli_zdst; > }; > typedef struct dl_ipnetinfo_v2 dl_ipnetinfo_v2_t; > > dli_version - version number (2) > dli_family - protocol family (AF_INET, AF_INET6, etc) > dli_htype - hook type (in, out, local) > dli_pktlen - length of the packet excluding this header > dli_ifindex - interface index number > dli_grifindex - group interface index number (for IPMP interfaces) > dli_zsrc - zone identifier for the source of the packet > dli_zdst - zone identifier for the destination of the packet > > References > ========== > [1] http://sac.eng.sun.com/sac/PSARC/2006/436 > [2] http://sac.eng.sun.com/sac/PSARC/2006/475, > http://opensolaris.org/os/project/clearview/ipnet/ > [3] http://arc.opensolaris.org/caselog/PSARC/2008/219 > [4] http://www.tcpdump.org/ > [5] http://arc.opensolaris.org/caselog/PSARC/2008/288 > [6] http://opensolaris.org/os/project/clearview/uv/ > [7] http://sac.eng.sun.com/sac/PSARC/2006/357 > > From Darren.Reed@sun.com Fri Apr 10 14:20: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 n3ALK0Ca001069 for ; Fri, 10 Apr 2009 14:20:00 -0700 (PDT) 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 n3ALJsCN005462 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 11 Apr 2009 05:19: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 <0KHW00B01LXAC700@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:19:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00578LX9TA30@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:19:58 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3ALJvY4027306 for ; Fri, 10 Apr 2009 21:19:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHW00A00LX9DW00@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 22:19:57 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHW00BSCLX73Y60@fe-emea-10.sun.com>; Fri, 10 Apr 2009 22:19:56 +0100 (BST) Date: Fri, 10 Apr 2009 14:19:54 -0700 From: Darren Reed Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <49DFB709.1000203@Sun.COM> Sender: Darren.Reed@sun.com To: Kais.Belgaied@sun.com Cc: psarc-ext@sun.com Message-id: <49DFB7FA.3020009@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: <49DFB39D.1020301@Sun.COM> <49DFB709.1000203@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 348 On 10/04/09 02:15 PM, Kais Belgaied wrote: > Hi Darren, > > while the architecture looks sound, it has so many pieces and > interactions with other subsystems > (the pluggale sockets, MAC, etc), way beyond what's suitable for a > fasttrack. > This should be a full case. Really? It seems rather obvious and straight forward to me O:-) Darren From gdamore@sun.com Fri Apr 10 14:25:02 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 n3ALP22P001352 for ; Fri, 10 Apr 2009 14:25:02 -0700 (PDT) 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 n3ALP1bE001153 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 10 Apr 2009 14:25:01 -0700 (PDT) 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 <0KHW00103M5PF300@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 10 Apr 2009 15:25:01 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00H1DM5OMV40@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 10 Apr 2009 15:25:00 -0600 (MDT) 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 n3ALP0Au004673 for ; Fri, 10 Apr 2009 14:25:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHW00E00M0HMN00@fe-sfbay-09.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 10 Apr 2009 14:25:00 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHW00B0AM5ER220@fe-sfbay-09.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 10 Apr 2009 14:24:54 -0700 (PDT) Date: Fri, 10 Apr 2009 14:24:49 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <49DFB39D.1020301@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: psarc-ext@sun.com Message-id: <49DFB921.3070904@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: <49DFB39D.1020301@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 12673 First off, I think this idea is a good idea. But I'm unconvinced that the project is simple and obvious enough to fall into a fast track bucket. I suspect that there are some bigger issues (and at least an opinion would be good to have for this case -- more later) that I think a full case might be called for. Darren Reed wrote: > This is a self sponsored fast track, timeout set for 2 weeks... > > Abstract > ======== > This case seeks to build on the Crossbow (PSARC/2006/357[7]) > infrastructure > and provide a new (to OpenSolaris) mechanism for capturing packets: the > use of the Berkeley Packet Filter (BPF). The goal of this project is to > provide a method to capture packets that has higher performance than > what we have to offer today on Solaris (DLPI based schemes.) It also has > the added benefit of increasing our compatibility with other software > that has been built to use BPF. > > Release Binding > --------------- > This case seeks to obtain approval for minor release binding. > > Background > ========== > Packet capture on Solaris is currently built around the use of DLPI. > Whilst the introduction of libdlpi (PSARC/2006/436[1]) has made it easier > to program using DLPI and the IP Observability Project > (PSARC/2006/475[2]) > introduced the means by which packets that are local to the host could > be intercepted, neither did anything to address the primary problem > with DLPI: compared to other mechanisms, it is slow, the in-kernel > filtering is either not used or very primitive and provides very > little useful information about the packet capturing itself by way > of statistics. > > Introduction > ============ > > The architecture of BPF lends itself to more efficient means of doing > packet capture, where a single read can transfer large numbers of packets > per call. It also allows the sniffer to choose how much data from each > packet they wish to copy, be it the entire packet or just the first 128 > bytes to capture headers. > > Internal Architecture > ~~~~~~~~~~~~~~~~~~~~~ > Internally, the architecture of BPF is very simple: it has a lower > half that receives packets from the NIC drivers, copying matching > packets into a static buffer and an upper half that implements a > character pseudo-device. > > Buffers > ------- > The backing for the pseudo-device operating as a character device > is a buffer allocated by the driver for storing packet data in. > The buffersize used by the device for storing copied packet data > in is set by the application. By default libpcap sets this size > the the same size as the driver's default: 32k. The maximum this > project allows is 16M. > > Two buffers of this size are allocated by the driver: an "active" > buffer and a "hold" buffer. This supports applications doing > sleeping reads, if they aren't using poll, and reading an entire > buffer of data whilst the system continues to catch new packets. > > Applications can set the buffer size using libpcap or with the > BIOCSBLEN ioctl (see man page.) Does this mean that libpcap will be converted to use BPF? > > List of Interfaces > ------------------ > BPF maintains an internal list of network interfaces that it supports > capturing packets for. What distinguishes this list from that either > in the mac or ip modules is that it uses the datalink type as a part > of the key for determining what is an identical entry. Additionally, > on OpenSolaris the device structure used inside of the ip module is > different to the mac module, preventing either one being used as a > master list by BPF. Answering queries such as returning the complete > list of datalink types supported by a device (BIOCGDLTLIST), would > be much more complicated without that internal list. > > Packet Capture > -------------- > When BPF is called from the mac layer, it is handed the packet as > it is received from the NIC driver as part of the promiscuous > callback handling in the mac layer. It is the same mblk_t for the > packet that will later be passed on though the stack and has > neither the mblk_t's nor dblk_t's duplicated. Thus the capturing > of the packet becomes part of the execution of the datapath for > each packet. > > Interactions with existing technology in Solaris > ================================================ > This section goes into detail about what impact this project has on > other areas of Solaris or what impact they have on this project. > > Vanity Naming > ~~~~~~~~~~~~~ > The Vanity Naming Project[6] introduced the means by which link names > could be changed to be a different name than the underlying mac name. > This project will only support packet capture on interfaces using the > interface name allocated by the dls module that was delivered by the > vanity naming project. What does this mean? Does it mean that vanity names "are", or "are not" supported? > > IP Observability > ~~~~~~~~~~~~~~~~ > The IP observerability project introduced the ability to capture packets > from within IP, presenting them through devices files in /dev/ipnet for > libdlpi to use. This project will update some of the interfaces > introduced > by IP observability. Can you spell this out in more detail. What are the interfaces modified? How so? > > Updating IPNET > -------------- > Unfortunately the mechanism used to do this is bound up within IP. To > build upon the work done here, this project will change the mechanism > by which IP observability works within IP to use the netinfo > (PSARC/2008/219[3]), enabling external kernel modules to easily subscribe > to the packet events that make up this feature. A single new event > will be added, NH_OBSERVING. Callbacks that are activated with this > event will receive a pointer to a hook_pkt_observe_t structure as > the hook_data_t value. > > This project will introduce a version 2 of the IPNET "protocol", with an > updated header. Selection of version 1 (the existing version of IPNET > headers) or version 2 will be achieved using the DLIOCIPNETINFO ioctl > on the /dev/ipnet STREAMS device. > > The version bump with IPNET is required to maintain backward > compatibility > with the current interface delivered and described with lo0(7d) - > it is currently a Committed interface. Should we EOF version 1 of IPNET? I know it was marked Committed.... but maybe it hasn't been widely enough used yet that breaking it would be seen as critical. (Has it escaped into Solaris 10, for example.) Its unclear what Committed "means" for the interim OpenSolaris builds... [ snip! ] > > > > New Interfaces > -------------- > BPF requires notification about each NIC that gets added, its datalink > type and length of the hardware address. It uses this information to > maintain an internal list of network interfaces that are available for > capturing packets on. To support this, it is necessary to call into BPF > from mac inside of mac_register() and mac_unregister(). This is done > using a function pointer that is set by calling a new function called > mac_set_bpfattach(). This function will take two parameters, one is > the function to call when attaching (mac_register), the other is the > function to call when detaching (mac_unregister). To account for the > fact that drivers may have already called mac_register() before > mac_set_bpfattach() is called, mac_set_bpfattach() will walk through > all existing attached devices and call bpfattach() for each one of > those. This approach is necessary due to the lack of a mechanism > equivalent to netinfo's NE_PLUMB/NE_UNPLUMB events for IP, which will > be used to support IPNET. Whilst the interface mentioned here is > private, it's listed here for completeness. > > mac_set_bpfattach - set function pointers to be called when drivers call > mac_register Sounds suspiciously close to how BSD does it. Not surprisingly. :-) > > An additional change is required in the mac module to improve > performance: > the introduction of a new promiscuous callback flag: > MAC_PROMISC_FLAGS_NO_COPY. > > By default, the current mode of operation when registering a callback > with the mac module today using mac_promisc_add will perform a copymsg() > on every packet passed in. When peek'ing at packets, such as what BPF > does, it isn't necessary to create a new mblk_t as BPF does not perform > any destructive operations on the packet. When this flag is presented > with MAC_PROMISC_FLAGS_VLAN_TAG_STRIP, the behaviour is to fall back > to doing the copymsg(). > > MAC_PROMISC_FLAGS_NO_COPY - promiscuous callback is well behaved and does > not need a copy of the packet > > libpcap > ~~~~~~~ > This project will update the copy of libpcap delivered by > PSARC/2008/288[5] > to use the BPF interface delivered with this project. A follow on project > may look at extending the libpcap filtering langauge to easily allow > filtering on the IPNET header fields. Ah! The answer to my earlier question. > > snoop > ~~~~~ > While implementation of snoop will continue to use DLPI via libdlpi > to retrieve packets, it will be updated to understand version 2 of > the IPNET packet headers and by default will use this version when > communicating with devices in /dev/ipnet. Support for understanding > the existing version 1 headers will remain. It seems like this ought to be switched to use BPF. snoop is still the only shipping and fully supported sniffer we have. Until wireshark ships, that is. Its also very widely used. Making it go faster would be a big win. > > /dev/bpf > ~~~~~~~~ > This driver ships using /dev/bpf as the device file for applications > to open. Whilst the creation of the device cannot be as a clone (it > is not a STREAMS driver), it is still possible for the driver to > assign a new minor number each time the device is opened. Thus > even though the driver isn't a clone driver, it is not necessary > to have /dev/bpf0-15 for proper BPF semantics. That seems like redundant information for this case. :-) We all know how cloneable devices work in Solaris. :-) > > driver.conf file > ~~~~~~~~~~~~~~~~ > This project intends to use the driver.conf as the means by which the > default and maximum buffer sizes can be changed. By default these are > 32k and 16M repectively. They can be changed using the names "buf_size" > and "max_buf_size". It is not envisaged that these will ever need > changing but scope is provided for those that either need or wish to. Ewww... perhaps this ought to be available as per device tunables? Configurable via Brussels? > > Whilst there are numerous new avenues being explored for datalink and > IP administration, it needs to be remembered that whilst this device is > centered around networking, it is neither a datalink nor an IP interface > and thus isn't managed by dladm and friends. The need to change > (increase) > the value from that shipped is expected to be a rare event. > > > ~~~~~~~~~~~ > This file contains all of the structure and ioctl definitions that make > up the programming interface for BPF. Four of the ioctls listed below > are being introduced as "Project Private" as they form the foundation > for supporting 32bit applications running against 64bit kernels. This > is necessary because some of the structures exchanged between the bpf > driver and applications contain pointers. > > > ~~~~~~~~~~~~~~~ > This is file contains the definitions for structures used in the kernel > and is thus private to the project. So, perhaps this file ought not to live in "net/bpfdesc.h", but rather in the kernel source directory where bpf will live. And thus not delivered to the customer? IMO implementation private headers have no business on the deployed system... that's what the source code distribution is for. :-) So, I definitely think this exceeds the "obvious enough for a fast track" threshold. There are significant questions above. Additionally, I think we need to have an opinion from PSARC that indicates that once this interface is available, applications ought to either use libpcap, or this interface directly, in favor of accessing DLPI. I think conversion of snoop, if not part of this project, needs to be included as a TCA or advice to SAC for a future project. Also,. is it necessary & desirable that BPF be "public"? Would it be sufficient to simply expose this to libpcap, and have userland applications access the libpcap interfaces? Are there known consumers of the BPF interface itself other than libpcap? I'm not hitting the derail button here, but I think the project team ought to consider doing so voluntarily. -- Garrett From gdamore@sun.com Fri Apr 10 14:26: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 n3ALQ26j001364 for ; Fri, 10 Apr 2009 14:26:02 -0700 (PDT) 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 n3ALQ1au058728 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 10 Apr 2009 15:26:02 -0600 (MDT) 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 <0KHW0010VM7DIL00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 15:26:01 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00HM0M7CN840@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 15:26:00 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3ALQ0oM022857 for ; Fri, 10 Apr 2009 14:26:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHW00200M30QN00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:26:00 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHW00585M7B4FH0@fe-sfbay-10.sun.com>; Fri, 10 Apr 2009 14:26:00 -0700 (PDT) Date: Fri, 10 Apr 2009 14:25:58 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <49DFB7FA.3020009@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: Kais.Belgaied@sun.com, psarc-ext@sun.com Message-id: <49DFB966.7010506@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: <49DFB39D.1020301@Sun.COM> <49DFB709.1000203@Sun.COM> <49DFB7FA.3020009@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 624 Darren Reed wrote: > On 10/04/09 02:15 PM, Kais Belgaied wrote: >> Hi Darren, >> >> while the architecture looks sound, it has so many pieces and >> interactions with other subsystems >> (the pluggale sockets, MAC, etc), way beyond what's suitable for a >> fasttrack. >> This should be a full case. > > Really? > > It seems rather obvious and straight forward to me O:-) > > Darren > I agree with Kais. My last e-mail had a lot more detail. You should self-derail. :-) I'll be happy to own the case for you should you decide to do so. (Provided, of course, that you'll act as the intern on it. :-) -- Garrett From Nicolas.Williams@sun.com Fri Apr 10 14:32:38 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 n3ALWbkO001484 for ; Fri, 10 Apr 2009 14:32:38 -0700 (PDT) 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 n3ALWWvH004043; Fri, 10 Apr 2009 14:32:36 -0700 (PDT) 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 <0KHW00209MIB7D00@brm-avmta-1.central.sun.com>; Fri, 10 Apr 2009 15:32:35 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00HZQMIBN530@brm-avmta-1.central.sun.com>; Fri, 10 Apr 2009 15:32:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3ALUgnT008517; Fri, 10 Apr 2009 16:30:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3ALUgGn008516; Fri, 10 Apr 2009 16:30:42 -0500 (CDT) Date: Fri, 10 Apr 2009 16:30:42 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <49DFB966.7010506@sun.com> To: "Garrett D'Amore" Cc: Darren Reed , Kais.Belgaied@sun.com, psarc-ext@sun.com Message-id: <20090410213042.GH1500@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: <49DFB39D.1020301@Sun.COM> <49DFB709.1000203@Sun.COM> <49DFB7FA.3020009@Sun.COM> <49DFB966.7010506@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 928 On Fri, Apr 10, 2009 at 02:25:58PM -0700, Garrett D'Amore wrote: > I agree with Kais. My last e-mail had a lot more detail. You should > self-derail. :-) I'll be happy to own the case for you should you > decide to do so. (Provided, of course, that you'll act as the intern on > it. :-) Now wait a minute. Derailing has consequences for the derailer (they have to write the opinion). Asking Darren to derail his own case is obviously an underhanded attempt to avoid those consequences :) If you want this to be a full case you should say that you're derailing, and if nobody does that then it remains a fasttrack. Hmmm, OTOH, with the new +1 requirement it's possible to force the sponsor to "self-derail" by denial-of-+1. Interesting wrinkle. So you could gang up with all other active ARC members and withold your +1s and thus avoid the consequences of being the one to call for derailing a fasttrack! Nico -- From Darren.Reed@sun.com Fri Apr 10 14:46:26 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 n3ALkPAF001719 for ; Fri, 10 Apr 2009 14:46:25 -0700 (PDT) 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 n3ALkK19005553 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 10 Apr 2009 15:46:25 -0600 (MDT) 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 <0KHW00F0ZN5D6W00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:46:25 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW005VFN5CTE40@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 14:46:24 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3ALkNOr028040 for ; Fri, 10 Apr 2009 21:46:23 +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-5.01 64bit (built Feb 19 2009)) id <0KHW00100MYKA800@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 22:46:23 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHW006ZMN4GT8A0@fe-emea-09.sun.com>; Fri, 10 Apr 2009 22:45:54 +0100 (BST) Date: Fri, 10 Apr 2009 14:45:52 -0700 From: Darren Reed Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <49DFB966.7010506@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: Kais.Belgaied@sun.com, PSARC-ext@sun.com, Aarti.Pai@sun.com Message-id: <49DFBE10.9010107@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: <49DFB39D.1020301@Sun.COM> <49DFB709.1000203@Sun.COM> <49DFB7FA.3020009@Sun.COM> <49DFB966.7010506@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 858 On 10/04/09 02:25 PM, Garrett D'Amore wrote: > Darren Reed wrote: >> On 10/04/09 02:15 PM, Kais Belgaied wrote: >>> Hi Darren, >>> >>> while the architecture looks sound, it has so many pieces and >>> interactions with other subsystems >>> (the pluggale sockets, MAC, etc), way beyond what's suitable for a >>> fasttrack. >>> This should be a full case. >> >> Really? >> >> It seems rather obvious and straight forward to me O:-) >> >> Darren >> > I agree with Kais. My last e-mail had a lot more detail. You should > self-derail. :-) I'll be happy to own the case for you should you > decide to do so. (Provided, of course, that you'll act as the intern > on it. :-) I think I can do that :-) Aarti, can you please put this case on the agenda for the 29th of April? (I can't make the next 2 meetings due to timezone difference.) Thanks, Darren From gdamore@sun.com Fri Apr 10 15:39:14 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 n3AMdD3b002712 for ; Fri, 10 Apr 2009 15:39:13 -0700 (PDT) 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 n3AMdDHI038153 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 10 Apr 2009 16:39:13 -0600 (MDT) 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 <0KHW00901PLDFQ00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 16:39:13 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHW00HTQPLCN8A0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 16:39:13 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3AMdCRn010942 for ; Fri, 10 Apr 2009 15:39:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHW00I00PC19T00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 10 Apr 2009 15:39:12 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHW00JTGPKLTZ10@fe-sfbay-10.sun.com>; Fri, 10 Apr 2009 15:38:46 -0700 (PDT) Date: Fri, 10 Apr 2009 15:38:45 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/232 Berkeley Packet Filter for OpenSolaris In-reply-to: <20090410213042.GH1500@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Darren Reed , Kais.Belgaied@sun.com, psarc-ext@sun.com Message-id: <49DFCA75.5020809@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: <49DFB39D.1020301@Sun.COM> <49DFB709.1000203@Sun.COM> <49DFB7FA.3020009@Sun.COM> <49DFB966.7010506@sun.com> <20090410213042.GH1500@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1167 Nicolas Williams wrote: > On Fri, Apr 10, 2009 at 02:25:58PM -0700, Garrett D'Amore wrote: > >> I agree with Kais. My last e-mail had a lot more detail. You should >> self-derail. :-) I'll be happy to own the case for you should you >> decide to do so. (Provided, of course, that you'll act as the intern on >> it. :-) >> > > Now wait a minute. Derailing has consequences for the derailer (they > have to write the opinion). Asking Darren to derail his own case is > obviously an underhanded attempt to avoid those consequences :) If you > want this to be a full case you should say that you're derailing, and if > nobody does that then it remains a fasttrack. > > Hmmm, OTOH, with the new +1 requirement it's possible to force the > sponsor to "self-derail" by denial-of-+1. Interesting wrinkle. > > So you could gang up with all other active ARC members and withold your > +1s and thus avoid the consequences of being the one to call for > derailing a fasttrack! > > Nico > I've already agreed to "own" the case, though. :-) And yes, I'd expect Darren to write the opinion, but that's because he's also a PSARC intern. :-) -- Garrett From Darren.Reed@sun.com Wed Apr 22 04:51:19 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 n3MBpIVh013985 for ; Wed, 22 Apr 2009 04:51:18 -0700 (PDT) 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 n3MBp93W026231 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Apr 2009 12:51:17 +0100 (BST) 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 <0KII00F0Z3LFI300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 04:51:15 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII009HO3LD54E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 04:51:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3MBpCKs028268 for ; Wed, 22 Apr 2009 11:51:12 +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-5.01 64bit (built Feb 19 2009)) id <0KII000002W6YV00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 12:51:12 +0100 (BST) Received: from [129.158.90.193] ([unknown] [129.158.90.193]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KII007CV3KT2MC0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 12:50:56 +0100 (BST) Date: Wed, 22 Apr 2009 21:50:46 +1000 From: Darren Reed Subject: PSARC/2009/232 Packet Capture Sender: Darren.Reed@sun.com To: Aarti.Pai@sun.com, PSARC-EXT Message-id: <49EF0496.206@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 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 130 Aarti, Please update the agenda for the 29th of April to have the review of PSARC/2009/232 scheduled for that meeting. Darren From Darren.Reed@sun.com Wed Apr 22 09:08:34 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 n3MG8Xkt015930 for ; Wed, 22 Apr 2009 09:08:34 -0700 (PDT) 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 n3MG8I6p002539 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 23 Apr 2009 00:08:32 +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 <0KII00071FI73500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 09:08:31 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII00KUBFI32120@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 09:08:28 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3MG8Rns029008 for ; Wed, 22 Apr 2009 16:08:27 +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-5.01 64bit (built Feb 19 2009)) id <0KII00G00FGK2300@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 17:08:27 +0100 (BST) Received: from [192.168.1.107] ([unknown] [202.45.110.141]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KII00MVEFGVWTC0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 17:07:46 +0100 (BST) Date: Thu, 23 Apr 2009 02:07:35 +1000 From: Darren Reed Subject: Re: PSARC/2009/232 Packet Capture In-reply-to: <49EF0496.206@Sun.COM> Sender: Darren.Reed@sun.com To: Aarti.Pai@sun.com, PSARC-EXT Message-id: <49EF40C7.2020105@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: <49EF0496.206@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 228 Materials for the case have been placed in the case directory. / /Darren Reed wrote: > Aarti, > > Please update the agenda for the 29th of April to have the review of > PSARC/2009/232 scheduled for that meeting. > > Darren > From Aarti.Pai@sun.com Wed Apr 22 16:00:02 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 n3MN01MV026016 for ; Wed, 22 Apr 2009 16:00:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3MN00PT008244 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 23 Apr 2009 00:00:01 +0100 (BST) 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 <0KII00407YK0UA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 17:00:00 -0600 (MDT) 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 <0KII002NYYJX4NC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 16:59:57 -0600 (MDT) 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 n3MMxvQ5005262 for ; Wed, 22 Apr 2009 22:59:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KII00M00XVFYR00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 16:59:57 -0600 (MDT) Received: from aarti-pais-macbook-pro.local ([unknown] [129.150.19.104]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KII000CHYJW6D40@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 22 Apr 2009 16:59:57 -0600 (MDT) Date: Wed, 22 Apr 2009 15:59:59 -0700 From: Aarti Pai Subject: Re: PSARC/2009/232 Packet Capture In-reply-to: <49EF0496.206@Sun.COM> Sender: Aarti.Pai@sun.com To: Darren Reed Cc: PSARC-EXT Message-id: <49EFA16F.1030108@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: <49EF0496.206@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 471 Darren Reed wrote: > Aarti, > > Please update the agenda for the 29th of April to have the review of > PSARC/2009/232 scheduled for that meeting. > > Darren > The agenda has been updated: 04/29/2009 glenn out 10:00-10:10 Open ARC Business (use open dial in above) 10:10-11:00 Open Discussion: Packet Capture for OpenSolaris (2009/232) Submitter: Darren Reed Owner: Garrett D'Amore Intern: Darren Reed Exposure: open Aarti From Darren.Reed@Sun.COM Wed May 6 22:45:13 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 n475jDtr007299 for ; Wed, 6 May 2009 22:45:13 -0700 (PDT) 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 n475jDka004638 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 6 May 2009 22:45:13 -0700 (PDT) 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 <0KJ900801ENDTY00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 May 2009 22:45:13 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ9004F3ENC7110@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 May 2009 22:45:13 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n475jCBr005634 for ; Thu, 07 May 2009 05:45:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ900900EL11O00@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 07 May 2009 06:45:12 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ90047DENACB20@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 07 May 2009 06:45:11 +0100 (BST) Date: Wed, 06 May 2009 22:45:10 -0700 From: Darren Reed Subject: PSARC/2009/232 Solaris Packet Capture Sender: Darren.Reed@Sun.COM To: psarc-ext@Sun.COM Message-id: <4A027566.9050807@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 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 207 I've sent email to psarc-agenda@, requesting a time slot for commitment next week of PSARC/2009/232. Materials for commitment can be found in the corresponding directory within the case directory. Darren From sacadmin Thu May 7 14:14:06 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 n47LE66m016084 for ; Thu, 7 May 2009 14:14:06 -0700 (PDT) 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 n47LE5bk059414 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 15:14:06 -0600 (MDT) 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 <0KJA0092HLNH9U00@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:14:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA00555LNFQD40@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:14:04 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n47LE3Q2029072 for ; Thu, 07 May 2009 21:14:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJA00400LAYQV00@fe-emea-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 22:14:03 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJA00F39LNDJ500@fe-emea-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 22:14:03 +0100 (BST) Date: Thu, 07 May 2009 14:14:01 -0700 From: Darren Reed Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <4A032B5F.50506@sun.com> Sender: Darren.Reed@sun.com To: Asa Romberger Cc: psarc-members@sun.com Message-id: <4A034F19.20401@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y8fYdLIwm+attD7EgAbhBA)" X-PMX-Version: 5.4.1.325704 References: <4A02030B.5070707@Sun.COM> <18946.53488.813547.499286@gargle.gargle.HOWL> <4A032B5F.50506@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 3246 This is a multi-part message in MIME format. --Boundary_(ID_y8fYdLIwm+attD7EgAbhBA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I think you mean May 20th? I'd rather not waste another week. Whilst the materials were posted "late", as in after 5pm on Wednesday, the request for a PSARC agenda slot was sent out at around 2:30pm on Wednesday. The materials for the case are present, so if the members can deal with having materials arrive a few hours late and un-cancel next weeks' meeting, it would be appreciated. Darren On 7/05/09 11:41 AM, Asa Romberger wrote: > Darren, > > Can this wait until June 20? > > Thanks > > Asa > > On 05/ 7/09 05:15 AM, James Carlson wrote: >> Darren Reed writes: >> >>> I'd like to request a slot at next week's PSARC meeting on June the >>> 13th, 2009, >>> for commitment review of PSARC/2009/232 - Solaris Packet Capture. >>> >> >> We canceled that slot at the end of yesterday's meeting due to the >> lack of projects asking for a review next week. >> >> If it can't wait for the following week, then I suggest asking folks >> on psarc-members@sun.com whether they can deal with un-canceling the >> meeting and getting late materials. Might be possible. >> >> --Boundary_(ID_y8fYdLIwm+attD7EgAbhBA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I think you mean May 20th?

I'd rather not waste another week.

Whilst the materials were posted "late", as in after 5pm on Wednesday,
the request for a PSARC agenda slot was sent out at around 2:30pm on
Wednesday.

The materials for the case are present, so if the members can deal with
having materials arrive a few hours late and un-cancel next weeks'
meeting, it would be appreciated.

Darren


On  7/05/09 11:41 AM, Asa Romberger wrote:
Darren,

Can this wait until June 20?

Thanks

Asa

On 05/ 7/09 05:15 AM, James Carlson wrote: 
Darren Reed writes:
  
I'd like to request a slot at next week's PSARC meeting on June the 
13th, 2009,
for commitment review of PSARC/2009/232 - Solaris Packet Capture.
    

We canceled that slot at the end of yesterday's meeting due to the
lack of projects asking for a review next week.

If it can't wait for the following week, then I suggest asking folks
on psarc-members@sun.com whether they can deal with un-canceling the
meeting and getting late materials.  Might be possible.

--Boundary_(ID_y8fYdLIwm+attD7EgAbhBA)-- From sacadmin Thu May 7 14:22:56 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 n47LMtKf016464 for ; Thu, 7 May 2009 14:22:55 -0700 (PDT) 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 n47LMtJr064713 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 15:22:55 -0600 (MDT) 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 <0KJA00L03M242700@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:22:52 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA00CTGM233E90@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:22:52 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n47LMpEu028938 for ; Thu, 07 May 2009 14:22:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJA00D00M1J3N00@fe-sfbay-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:22:51 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJA008N5M1Z3A10@fe-sfbay-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:22:48 -0700 (PDT) Date: Thu, 07 May 2009 14:22:47 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <4A034F19.20401@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: Asa Romberger , psarc-members@sun.com Message-id: <4A035127.2020409@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: <4A02030B.5070707@Sun.COM> <18946.53488.813547.499286@gargle.gargle.HOWL> <4A032B5F.50506@sun.com> <4A034F19.20401@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1502 I can attend. However, Darren, it is normally considered more or less required that you get on the schedule at least a week in advance, and that materials need to present at *least* a week in advance. Is there some pressing need to get this case reviewed for May 20th? Do you have particular time pressure for this case? - Garrett Darren Reed wrote: > I think you mean May 20th? > > I'd rather not waste another week. > > Whilst the materials were posted "late", as in after 5pm on Wednesday, > the request for a PSARC agenda slot was sent out at around 2:30pm on > Wednesday. > > The materials for the case are present, so if the members can deal with > having materials arrive a few hours late and un-cancel next weeks' > meeting, it would be appreciated. > > Darren > > > On 7/05/09 11:41 AM, Asa Romberger wrote: >> Darren, >> >> Can this wait until June 20? >> >> Thanks >> >> Asa >> >> On 05/ 7/09 05:15 AM, James Carlson wrote: >>> Darren Reed writes: >>> >>>> I'd like to request a slot at next week's PSARC meeting on June the >>>> 13th, 2009, >>>> for commitment review of PSARC/2009/232 - Solaris Packet Capture. >>>> >>> >>> We canceled that slot at the end of yesterday's meeting due to the >>> lack of projects asking for a review next week. >>> >>> If it can't wait for the following week, then I suggest asking folks >>> on psarc-members@sun.com whether they can deal with un-canceling the >>> meeting and getting late materials. Might be possible. >>> >>> > From sacadmin Thu May 7 14:27:48 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 n47LRmnE016513 for ; Thu, 7 May 2009 14:27:48 -0700 (PDT) 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 n47LRlib029099 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 14:27:48 -0700 (PDT) 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 <0KJA00L01MABJC00@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:27:47 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA00C38MA93HC0@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:27:46 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n47LRjlL029505 for ; Thu, 07 May 2009 21:27:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJA00E00M2ULW00@fe-emea-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 22:27:45 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJA00F4PMA7J500@fe-emea-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 22:27:45 +0100 (BST) Date: Thu, 07 May 2009 14:27:43 -0700 From: Darren Reed Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <4A035127.2020409@sun.com> Sender: Darren.Reed@Sun.COM To: "Garrett D'Amore" Cc: Asa Romberger , psarc-members@Sun.COM Message-id: <4A03524F.8080702@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A02030B.5070707@Sun.COM> <18946.53488.813547.499286@gargle.gargle.HOWL> <4A032B5F.50506@sun.com> <4A034F19.20401@Sun.COM> <4A035127.2020409@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1694 The goal for this project is to have it complete by the end of this quarter. Darren On 7/05/09 02:22 PM, Garrett D'Amore wrote: > I can attend. > > However, Darren, it is normally considered more or less required that > you get on the schedule at least a week in advance, and that materials > need to present at *least* a week in advance. > > Is there some pressing need to get this case reviewed for May 20th? > Do you have particular time pressure for this case? > > - Garrett > > Darren Reed wrote: >> I think you mean May 20th? >> >> I'd rather not waste another week. >> >> Whilst the materials were posted "late", as in after 5pm on Wednesday, >> the request for a PSARC agenda slot was sent out at around 2:30pm on >> Wednesday. >> >> The materials for the case are present, so if the members can deal with >> having materials arrive a few hours late and un-cancel next weeks' >> meeting, it would be appreciated. >> >> Darren >> >> >> On 7/05/09 11:41 AM, Asa Romberger wrote: >>> Darren, >>> >>> Can this wait until June 20? >>> >>> Thanks >>> >>> Asa >>> >>> On 05/ 7/09 05:15 AM, James Carlson wrote: >>>> Darren Reed writes: >>>> >>>>> I'd like to request a slot at next week's PSARC meeting on June >>>>> the 13th, 2009, >>>>> for commitment review of PSARC/2009/232 - Solaris Packet Capture. >>>>> >>>> >>>> We canceled that slot at the end of yesterday's meeting due to the >>>> lack of projects asking for a review next week. >>>> >>>> If it can't wait for the following week, then I suggest asking folks >>>> on psarc-members@sun.com whether they can deal with un-canceling the >>>> meeting and getting late materials. Might be possible. >>>> >>>> >> > From sacadmin Thu May 7 14:34:17 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 n47LYGI2016581 for ; Thu, 7 May 2009 14:34:16 -0700 (PDT) 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 n47LYC4J002380 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 14:34:16 -0700 (PDT) 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 <0KJA00B2HML3X500@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:34:15 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA005KRML3QG70@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:34:15 -0700 (PDT) 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 n47LYFMV000440 for ; Thu, 07 May 2009 14:34:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJA00800M7RE500@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:34:15 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJA005IDMKF6YB0@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:33:52 -0700 (PDT) Date: Thu, 07 May 2009 14:33:51 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <4A03524F.8080702@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: Asa Romberger , psarc-members@sun.com Message-id: <4A0353BF.1040704@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: <4A02030B.5070707@Sun.COM> <18946.53488.813547.499286@gargle.gargle.HOWL> <4A032B5F.50506@sun.com> <4A034F19.20401@Sun.COM> <4A035127.2020409@sun.com> <4A03524F.8080702@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1850 Darren Reed wrote: > The goal for this project is to have it complete by the end of this > quarter. Is this pressure tied to a specific release vehicle? - Garrett > > Darren > > On 7/05/09 02:22 PM, Garrett D'Amore wrote: >> I can attend. >> >> However, Darren, it is normally considered more or less required that >> you get on the schedule at least a week in advance, and that >> materials need to present at *least* a week in advance. >> >> Is there some pressing need to get this case reviewed for May 20th? >> Do you have particular time pressure for this case? >> >> - Garrett >> >> Darren Reed wrote: >>> I think you mean May 20th? >>> >>> I'd rather not waste another week. >>> >>> Whilst the materials were posted "late", as in after 5pm on Wednesday, >>> the request for a PSARC agenda slot was sent out at around 2:30pm on >>> Wednesday. >>> >>> The materials for the case are present, so if the members can deal with >>> having materials arrive a few hours late and un-cancel next weeks' >>> meeting, it would be appreciated. >>> >>> Darren >>> >>> >>> On 7/05/09 11:41 AM, Asa Romberger wrote: >>>> Darren, >>>> >>>> Can this wait until June 20? >>>> >>>> Thanks >>>> >>>> Asa >>>> >>>> On 05/ 7/09 05:15 AM, James Carlson wrote: >>>>> Darren Reed writes: >>>>> >>>>>> I'd like to request a slot at next week's PSARC meeting on June >>>>>> the 13th, 2009, >>>>>> for commitment review of PSARC/2009/232 - Solaris Packet Capture. >>>>>> >>>>> >>>>> We canceled that slot at the end of yesterday's meeting due to the >>>>> lack of projects asking for a review next week. >>>>> >>>>> If it can't wait for the following week, then I suggest asking folks >>>>> on psarc-members@sun.com whether they can deal with un-canceling the >>>>> meeting and getting late materials. Might be possible. >>>>> >>>>> >>> >> > From sacadmin Thu May 7 14:35:40 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 n47LZdU4016614 for ; Thu, 7 May 2009 14:35:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n47LZb5d019315 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Fri, 8 May 2009 05:35:38 +0800 (SGT) 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 <0KJA00M0RMNDDU00@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:35:37 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA00CR3MNC3BB0@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:35:37 -0600 (MDT) 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 n47LZaK4013173 for ; Thu, 07 May 2009 14:35:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJA00I00MKDRA00@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:35:36 -0700 (PDT) Received: from [129.145.154.84] ([unknown] [129.145.154.84]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJA00DAWMN6YZ50@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:35:30 -0700 (PDT) Date: Thu, 07 May 2009 14:35:29 -0700 From: Asa Romberger Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <4A03524F.8080702@Sun.COM> Sender: Asa.Romberger@sun.com To: Darren Reed Cc: "Garrett D'Amore" , psarc-members@sun.com Message-id: <4A035421.9000408@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: <4A02030B.5070707@Sun.COM> <18946.53488.813547.499286@gargle.gargle.HOWL> <4A032B5F.50506@sun.com> <4A034F19.20401@Sun.COM> <4A035127.2020409@sun.com> <4A03524F.8080702@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 1870 PSARC, Should I put this on the agenda for next week? Thanks Asa On 05/ 7/09 02:27 PM, Darren Reed wrote: > The goal for this project is to have it complete by the end of this > quarter. > > Darren > > On 7/05/09 02:22 PM, Garrett D'Amore wrote: >> I can attend. >> >> However, Darren, it is normally considered more or less required that >> you get on the schedule at least a week in advance, and that >> materials need to present at *least* a week in advance. >> >> Is there some pressing need to get this case reviewed for May 20th? >> Do you have particular time pressure for this case? >> >> - Garrett >> >> Darren Reed wrote: >>> I think you mean May 20th? >>> >>> I'd rather not waste another week. >>> >>> Whilst the materials were posted "late", as in after 5pm on Wednesday, >>> the request for a PSARC agenda slot was sent out at around 2:30pm on >>> Wednesday. >>> >>> The materials for the case are present, so if the members can deal with >>> having materials arrive a few hours late and un-cancel next weeks' >>> meeting, it would be appreciated. >>> >>> Darren >>> >>> >>> On 7/05/09 11:41 AM, Asa Romberger wrote: >>>> Darren, >>>> >>>> Can this wait until June 20? >>>> >>>> Thanks >>>> >>>> Asa >>>> >>>> On 05/ 7/09 05:15 AM, James Carlson wrote: >>>>> Darren Reed writes: >>>>> >>>>>> I'd like to request a slot at next week's PSARC meeting on June >>>>>> the 13th, 2009, >>>>>> for commitment review of PSARC/2009/232 - Solaris Packet Capture. >>>>>> >>>>> >>>>> We canceled that slot at the end of yesterday's meeting due to the >>>>> lack of projects asking for a review next week. >>>>> >>>>> If it can't wait for the following week, then I suggest asking folks >>>>> on psarc-members@sun.com whether they can deal with un-canceling the >>>>> meeting and getting late materials. Might be possible. >>>>> >>>>> >>> >> > From sacadmin Thu May 7 14:37:27 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 n47LbQxh016651 for ; Thu, 7 May 2009 14:37:26 -0700 (PDT) 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 n47LbOBn004483 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 14:37:26 -0700 (PDT) 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 <0KJA00A0RMQDL700@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:37:25 -0700 (PDT) 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 <0KJA00026MQCKXC0@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 14:37:25 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n47LbOj2029867 for ; Thu, 07 May 2009 21:37:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJA00A00MCREE00@fe-emea-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 22:37:24 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJA00C8WMQADW00@fe-emea-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 22:37:24 +0100 (BST) Date: Thu, 07 May 2009 14:37:21 -0700 From: Darren Reed Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <4A0353BF.1040704@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: Asa Romberger , psarc-members@sun.com Message-id: <4A035491.6080003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A02030B.5070707@Sun.COM> <18946.53488.813547.499286@gargle.gargle.HOWL> <4A032B5F.50506@sun.com> <4A034F19.20401@Sun.COM> <4A035127.2020409@sun.com> <4A03524F.8080702@Sun.COM> <4A0353BF.1040704@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1978 On 7/05/09 02:33 PM, Garrett D'Amore wrote: > Darren Reed wrote: >> The goal for this project is to have it complete by the end of this >> quarter. > > Is this pressure tied to a specific release vehicle? No. > > - Garrett > >> >> Darren >> >> On 7/05/09 02:22 PM, Garrett D'Amore wrote: >>> I can attend. >>> >>> However, Darren, it is normally considered more or less required >>> that you get on the schedule at least a week in advance, and that >>> materials need to present at *least* a week in advance. >>> >>> Is there some pressing need to get this case reviewed for May 20th? >>> Do you have particular time pressure for this case? >>> >>> - Garrett >>> >>> Darren Reed wrote: >>>> I think you mean May 20th? >>>> >>>> I'd rather not waste another week. >>>> >>>> Whilst the materials were posted "late", as in after 5pm on Wednesday, >>>> the request for a PSARC agenda slot was sent out at around 2:30pm on >>>> Wednesday. >>>> >>>> The materials for the case are present, so if the members can deal >>>> with >>>> having materials arrive a few hours late and un-cancel next weeks' >>>> meeting, it would be appreciated. >>>> >>>> Darren >>>> >>>> >>>> On 7/05/09 11:41 AM, Asa Romberger wrote: >>>>> Darren, >>>>> >>>>> Can this wait until June 20? >>>>> >>>>> Thanks >>>>> >>>>> Asa >>>>> >>>>> On 05/ 7/09 05:15 AM, James Carlson wrote: >>>>>> Darren Reed writes: >>>>>> >>>>>>> I'd like to request a slot at next week's PSARC meeting on June >>>>>>> the 13th, 2009, >>>>>>> for commitment review of PSARC/2009/232 - Solaris Packet Capture. >>>>>>> >>>>>> >>>>>> We canceled that slot at the end of yesterday's meeting due to the >>>>>> lack of projects asking for a review next week. >>>>>> >>>>>> If it can't wait for the following week, then I suggest asking folks >>>>>> on psarc-members@sun.com whether they can deal with un-canceling the >>>>>> meeting and getting late materials. Might be possible. >>>>>> >>>>>> >>>> >>> >> > From sacadmin Thu May 7 15:05: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 n47M5PM0017462 for ; Thu, 7 May 2009 15:05:25 -0700 (PDT) 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 n47M5P8t017215; Thu, 7 May 2009 15:05:25 -0700 (PDT) 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 <0KJA00203O0ZBD00@brm-avmta-1.central.sun.com>; Thu, 07 May 2009 16:05:23 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA00CL5O0Y3FE0@brm-avmta-1.central.sun.com>; Thu, 07 May 2009 16:05:22 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n47M5KIa036101; Thu, 07 May 2009 15:05:20 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n47M4OOA022241; Thu, 07 May 2009 15:04:24 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n47M4OjD022240; Thu, 07 May 2009 15:04:24 -0700 (PDT) Date: Thu, 07 May 2009 15:04:24 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 To: gdamore@sun.com, Darren.Reed@sun.com Cc: Asa.Romberger@sun.com, psarc-members@sun.com Message-id: <200905072204.n47M4OjD022240@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 217 > > Is this pressure tied to a specific release vehicle? > > No. Then why not let the no meeting on the 13 stand and everyone will have plenty of advanced knowledge that there will be a case on the 20th? Gary.. From sacadmin Thu May 7 15:17:00 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 n47MH0l0017544 for ; Thu, 7 May 2009 15:17:00 -0700 (PDT) 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 n47MGvlM029805 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 16:16:59 -0600 (MDT) 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 <0KJA00301OJWHV00@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 16:16:44 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJA002SHOJVUW00@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 16:16:43 -0600 (MDT) 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 n47MGhGM017781 for ; Thu, 07 May 2009 15:16:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJA00M00OEZS600@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:16:43 -0700 (PDT) Received: from [129.145.154.84] ([unknown] [129.145.154.84]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJA00DOXOJDYZ70@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:16:26 -0700 (PDT) Date: Thu, 07 May 2009 15:16:25 -0700 From: Asa Romberger Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <200905072204.n47M4OjD022240@marduk.eng.sun.com> Sender: Asa.Romberger@sun.com To: Darren.Reed@sun.com, psarc-members@sun.com Message-id: <4A035DB9.1030100@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: <200905072204.n47M4OjD022240@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 48 I am putting this on the agenda for May 20 Asa From sacadmin Thu May 7 15:19:26 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 n47MJQpK017720 for ; Thu, 7 May 2009 15:19:26 -0700 (PDT) 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 n47MJBLW025532 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Thu, 7 May 2009 15:19:26 -0700 (PDT) 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 <0KJA00D03OO13X00@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:19:13 -0700 (PDT) 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 <0KJA00C5MOO1XD00@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:19:13 -0700 (PDT) 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 n47MJDdx005936 for ; Thu, 07 May 2009 15:19:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJA00100OHC3U00@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Thu, 07 May 2009 15:19:13 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJA00CV6OO0M5B0@fe-sfbay-09.sun.com>; Thu, 07 May 2009 15:19:13 -0700 (PDT) Date: Thu, 07 May 2009 15:19:11 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 13 june 2009 - request for commitment review of PSARC/2009/232 In-reply-to: <200905072204.n47M4OjD022240@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: Darren.Reed@sun.com, Asa.Romberger@sun.com, psarc-members@sun.com Message-id: <4A035E5F.40306@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: <200905072204.n47M4OjD022240@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 517 Gary Winiger wrote: >>> Is this pressure tied to a specific release vehicle? >>> >> No. >> > > Then why not let the no meeting on the 13 stand and everyone > will have plenty of advanced knowledge that there will be a > case on the 20th? > > Gary.. > After communicating with Darren, I think this is the best. There is no real business reason for us to reinstate the meeting -- Darren just wanted to get this done as soon as possible. An extra week delay isn't going to matter. - Garrett From sac-owner Fri Aug 21 20:26:18 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 n7M3QHih015930 for ; Fri, 21 Aug 2009 20:26:17 -0700 (PDT) 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 n7M3QBqg000864 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Sat, 22 Aug 2009 11:26:16 +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 <0KOR00E05DJQCN00@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Fri, 21 Aug 2009 20:26:14 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOR001KMDJPYN30@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Fri, 21 Aug 2009 20:26:13 -0700 (PDT) Received: from fe-emea-10.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 n7M3QCGD015232 for ; Sat, 22 Aug 2009 03:26:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOR00B00DE2GI00@fe-emea-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Sat, 22 Aug 2009 04:25:54 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOR00B01DJ4XUD0@fe-emea-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Sat, 22 Aug 2009 04:25:54 +0100 (BST) Date: Fri, 21 Aug 2009 20:26:00 -0700 From: Darren Reed Subject: Opinion for SAC review: PSARC/2009/232 Solaris Packet Capture Sender: Darren.Reed@sun.com To: sac-review@sun.com Message-id: <4A8F6548.4080103@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Vh6JOSqeDQ2pb0nXYepNWQ)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090608) Status: RO Content-Length: 13372 This is a multi-part message in MIME format. --Boundary_(ID_Vh6JOSqeDQ2pb0nXYepNWQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Please review the opion attached and comment by August 28th. Darren --Boundary_(ID_Vh6JOSqeDQ2pb0nXYepNWQ) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Solaris Packet Capture Submitted by: Darren Reed File: PSARC/2009/232/opinion.ms Date: 20 May 2009 Committee: Jim Carlson, Mark Carlson, Richard Matthews, Sebastian Roy Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to integrate the Berkely Packet Cap- ture feature into the Solaris Kernel, bringing with it the Berkeley Packet Filter (BPF.) This feature is usually refered to as BPF and will be for the remainder of this document. This project also proposes to integrate the PF_PACKET API from Linux as a socket plugin. 2. Decision & Precedence Information The project is approved as specified in reference [1][2][3]. The project may be delivered in a minor release of the ON consolidation. 3. Interfaces The project exports the following interfaces. _____________________________________________________________________________ | Interfaces Exported | |_____________________________________|_______________________|_____________| |Interface | Classification | Comments | |_____________________________________|_______________________|_____________| |usr/kernel/drv/bpf | Project Private | | |usr/kernel/drv/bpf.conf | Project Private | | |/dev/bpf | Uncommitted | | | | Committed | | | | Project Private | | |_____________________________________|_______________________|_____________| PSARC/2009/232 Copyright 2009 Sun Microsyst - 2 - _____________________________________________________________________________ | Interfaces Exported | |_____________________________________|_______________________|_____________| |Interface | Classification | Comments | |_____________________________________|_______________________|_____________| |BPF_MAJOR_VERSION | Committed | | |BPF_MINOR_VERSION | Committed | | |BIOCGBLEN | Committed | | |BIOCSBLEN | Committed | | |BIOCSETF | Committed | | |BIOCFLUSH | Committed | | |BIOCPROMIS | Committed | | |BIOCGDLT | Committed | | |BIOCGETIF | Committed | | |BIOCSETIF | Committed | | |BIOCGETLIF | Committed | | |BIOCSETLIF | Committed | | |BIOCSORTIMEOUT | Committed | | |BIOCGORTIMEOUT | Committed | | |BIOCGSTATS | Committed | | |BIOCIMMEDIATE | Committed | | |BIOCVERSION | Committed | | |BIOCSTCPF | Committed | | |BIOCSUDPF | Committed | | |BIOCGHDRCMPLT | Committed | | |BIOCSHDRCMPLT | Committed | | |BIOCSDLT | Committed | | |BIOCGDLTLIST | Committed | | |BIOCGSEESENT | Committed | | |BIOCSSEESENT | Committed | | |BIOCSRTIMEOUT | Committed | | |BIOCGRTIMEOUT | Committed | | |BBIOCSETF32 | Project private | | |BIOCGDLTLIST32 | Project private | | |BIOCSRTIMEOUT32 | Project private | | |BIOCGRTIMEOUT32 | Project private | | |struct bpf_dltlist | Committed | | |struct bpf_hdr | Committed | | |struct bpf_insn | Committed | | |struct bpf_program | Committed | | |struct bpf_stat | Committed | | |struct bpf_timeval | Committed | | |struct bpf_version | Committed | | |NH_OBSERVING | Committed | | |hook_pkt_observe_t | Committed | | |DLT_IPNET | Committed | | |dl_ipnetinfo_v2_t | Committed | | |bpf-capture | Uncommitted | SDT probe | |MAC_PROMISC_FLAGS_NO_COPY | Consolidation Private| | |dls_set_bpfattach | Project Private | | |mac_addr_length | Consolidation Private| | |mac_type | Consolidation Private| | |/usr/kernel/socketmod/sockpfp | Project Private | | |/usr/kernel/socketmod/amd64/sockpfp | Project Private | | |_____________________________________|_______________________|_____________| PSARC/2009/232 Copyright 2009 Sun Microsyst - 3 - _____________________________________________________________________________ | Interfaces Exported | |_____________________________________|_______________________|_____________| |Interface | Classification | Comments | |_____________________________________|_______________________|_____________| |/usr/kernel/socketmod/sparcv9/sockpfp| Project Private | | | | Committed | | |PF_PACKET | Committed | | |SOL_PACKET | Committed | | |SO_ATTACH_FILTER | Committed | | |SO_DETACH_FILTER | Committed | | |SIOCGIFHWADDR | Committed | | |SIOCGSTAMP | Committed | | |PACKET_STATISTICS | Committed | | |PACKET_ADD_MEMBERSHIP | Committed | | |PACKET_DROP_MEMBERSHIP | Committed | | |PACKET_AUXDATA | Committed | | |PACKET_HOST | Committed | | |PACKET_BROADCAST | Committed | | |PACKET_MULTICAST | Committed | | |PACKET_OTHERHOST | Committed | | |PACKET_OUTGOING | Committed | | |struct packet_mreq | Committed | | |struct sock_filter | Committed | | |struct sock_fprog | Committed | | |struct sockaddr_ll | Committed | | |struct tpacket_auxdata* | Committed | | |struct tpacket_hdr* | Committed | | |struct tpacket_stats | Committed | | |struct tpacket2_hdr* | Committed | | |_____________________________________|_______________________|_____________| The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |___________________________|________________|__________| |Interface | Classification| Comments| |___________________________|________________|__________| | | | | |struct modlsockmod | | | |smod_reg_t | | | |sock_downcalls_t | | | |sock_lower_handle_t | | | |sock_upcalls_t | | | |mac_addr_len | | | |mac_client_open | | | |mac_client_close | | | |mac_close | | | |mac_header | | | |mac_multicast_add | | | |mac_multicast_remove | | | |mac_open_by_linkid | | | |___________________________|________________|__________| PSARC/2009/232 Copyright 2009 Sun Microsyst - 4 - _________________________________________________________ | Interfaces Imported | |___________________________|________________|__________| |Interface | Classification| Comments| |___________________________|________________|__________| |mac_promisc_add | | | |mac_promisc_remove | | | |mac_sdu_get | | | |mac_tx | | | |mac_unicast_primary_get | | | |dls_devnet_macname2linkid | | | |mac_client_handle_t | | | |mac_client_promisc_type_t | | | |mac_handle_t | | | |MAC_ADDRTYPE_MULTICAST | | | |MAC_ADDRTYPE_BROADCAST | | | |MAC_ADDRTYPE_UNICAST | | | |MAC_CLIENT_PROMISC_ALL | | | |MAC_CLIENT_PROMISC_FILTERED| | | |MAC_CLIENT_PROMISC_MULTI | | | |MAC_DROP_ON_NO_DESC | | | | | | | | | | | | | | | | | | | |___________________________|________________|__________| 4. Opinion 4.1. Setting the Packet Capture DLT The BPF architecture which allows a single network device name to be used to generate different types of packet cap- ture data, determined by where and how it is presented to BPF by the networking stack. This is different to existing architecture where a specific pathname or socket can only be used to receive a single type of packet. The delivery of the man page for BPF will document the ioctls used with this mechanism and the man page for tcpdump will document how users can use it from the command line. 5. Minority Opinion(s) None. 6. Advisory Information None. PSARC/2009/232 Copyright 2009 Sun Microsyst - 5 - 7. Appendices 7.1. Appendix A: Technical Changes Required No technical changes required. 7.2. Appendix B: Technical Changes Advised No technical changes advised. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/232. 1 commitment.materials/bpf-psarc.txt 2 commitment.materials/pfp-psarc.txt 3 commitment.materials/questions.txt PSARC/2009/232 Copyright 2009 Sun Microsyst --Boundary_(ID_Vh6JOSqeDQ2pb0nXYepNWQ)-- From sac-owner Wed Sep 9 11:42:39 2009 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02.SFBay.Sun.COM [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n89IgdRa012715 for ; Wed, 9 Sep 2009 11:42:39 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n89IgcgX007827 for ; Wed, 9 Sep 2009 11:42:39 -0700 (PDT) Received: from fe-emea-10.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 n89IgXYi021565 for ; Wed, 9 Sep 2009 18:42:33 GMT MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7QWsA8W46FlcOCizuP26/g)" Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPP00M00VQTDC00@fe-emea-10.sun.com> for sac-opinion@sac.eng.sun.com; Wed, 09 Sep 2009 19:42:21 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPP00GTVVYJ3Z00@fe-emea-10.sun.com>; Wed, 09 Sep 2009 19:42:21 +0100 (BST) Date: Wed, 09 Sep 2009 11:43:13 -0700 From: Darren Reed Subject: Opinion for archive: PSARC/2009/232 Solaris Packet Capture Sender: Darren.Reed@Sun.COM To: sac-opinion@sac.sfbay.sun.com, solaris-pac-opinion@old-sac.eng.sun.com Message-id: <4AA7F741.2050609@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090608) Status: RO Content-Length: 13303 This is a multi-part message in MIME format. --Boundary_(ID_7QWsA8W46FlcOCizuP26/g) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT --Boundary_(ID_7QWsA8W46FlcOCizuP26/g) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Solaris Packet Capture Submitted by: Darren Reed File: PSARC/2009/232/opinion.ms Date: 20 May 2009 Committee: Jim Carlson, Mark Carlson, Richard Matthews, Sebastian Roy Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to integrate the Berkely Packet Cap- ture feature into the Solaris Kernel, bringing with it the Berkeley Packet Filter (BPF.) This feature is usually refered to as BPF and will be for the remainder of this document. This project also proposes to integrate the PF_PACKET API from Linux as a socket plugin. 2. Decision & Precedence Information The project is approved as specified in reference [1][2][3]. The project may be delivered in a minor release of the ON consolidation. 3. Interfaces The project exports the following interfaces. _____________________________________________________________________________ | Interfaces Exported | |_____________________________________|_______________________|_____________| |Interface | Classification | Comments | |_____________________________________|_______________________|_____________| |usr/kernel/drv/bpf | Project Private | | |usr/kernel/drv/bpf.conf | Project Private | | |/dev/bpf | Uncommitted | | | | Committed | | | | Project Private | | |_____________________________________|_______________________|_____________| PSARC/2009/232 Copyright 2009 Sun Microsyst - 2 - _____________________________________________________________________________ | Interfaces Exported | |_____________________________________|_______________________|_____________| |Interface | Classification | Comments | |_____________________________________|_______________________|_____________| |BPF_MAJOR_VERSION | Committed | | |BPF_MINOR_VERSION | Committed | | |BIOCGBLEN | Committed | | |BIOCSBLEN | Committed | | |BIOCSETF | Committed | | |BIOCFLUSH | Committed | | |BIOCPROMIS | Committed | | |BIOCGDLT | Committed | | |BIOCGETIF | Committed | | |BIOCSETIF | Committed | | |BIOCGETLIF | Committed | | |BIOCSETLIF | Committed | | |BIOCSORTIMEOUT | Committed | | |BIOCGORTIMEOUT | Committed | | |BIOCGSTATS | Committed | | |BIOCIMMEDIATE | Committed | | |BIOCVERSION | Committed | | |BIOCSTCPF | Committed | | |BIOCSUDPF | Committed | | |BIOCGHDRCMPLT | Committed | | |BIOCSHDRCMPLT | Committed | | |BIOCSDLT | Committed | | |BIOCGDLTLIST | Committed | | |BIOCGSEESENT | Committed | | |BIOCSSEESENT | Committed | | |BIOCSRTIMEOUT | Committed | | |BIOCGRTIMEOUT | Committed | | |BBIOCSETF32 | Project private | | |BIOCGDLTLIST32 | Project private | | |BIOCSRTIMEOUT32 | Project private | | |BIOCGRTIMEOUT32 | Project private | | |struct bpf_dltlist | Committed | | |struct bpf_hdr | Committed | | |struct bpf_insn | Committed | | |struct bpf_program | Committed | | |struct bpf_stat | Committed | | |struct bpf_timeval | Committed | | |struct bpf_version | Committed | | |NH_OBSERVING | Committed | | |hook_pkt_observe_t | Committed | | |DLT_IPNET | Committed | | |dl_ipnetinfo_v2_t | Committed | | |bpf-capture | Uncommitted | SDT probe | |MAC_PROMISC_FLAGS_NO_COPY | Consolidation Private| | |dls_set_bpfattach | Project Private | | |mac_addr_length | Consolidation Private| | |mac_type | Consolidation Private| | |/usr/kernel/socketmod/sockpfp | Project Private | | |/usr/kernel/socketmod/amd64/sockpfp | Project Private | | |_____________________________________|_______________________|_____________| PSARC/2009/232 Copyright 2009 Sun Microsyst - 3 - _____________________________________________________________________________ | Interfaces Exported | |_____________________________________|_______________________|_____________| |Interface | Classification | Comments | |_____________________________________|_______________________|_____________| |/usr/kernel/socketmod/sparcv9/sockpfp| Project Private | | | | Committed | | |PF_PACKET | Committed | | |SOL_PACKET | Committed | | |SO_ATTACH_FILTER | Committed | | |SO_DETACH_FILTER | Committed | | |SIOCGIFHWADDR | Committed | | |SIOCGSTAMP | Committed | | |PACKET_STATISTICS | Committed | | |PACKET_ADD_MEMBERSHIP | Committed | | |PACKET_DROP_MEMBERSHIP | Committed | | |PACKET_AUXDATA | Committed | | |PACKET_HOST | Committed | | |PACKET_BROADCAST | Committed | | |PACKET_MULTICAST | Committed | | |PACKET_OTHERHOST | Committed | | |PACKET_OUTGOING | Committed | | |struct packet_mreq | Committed | | |struct sock_filter | Committed | | |struct sock_fprog | Committed | | |struct sockaddr_ll | Committed | | |struct tpacket_auxdata* | Committed | | |struct tpacket_hdr* | Committed | | |struct tpacket_stats | Committed | | |struct tpacket2_hdr* | Committed | | |_____________________________________|_______________________|_____________| The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |___________________________|________________|__________| |Interface | Classification| Comments| |___________________________|________________|__________| | | | | |struct modlsockmod | | | |smod_reg_t | | | |sock_downcalls_t | | | |sock_lower_handle_t | | | |sock_upcalls_t | | | |mac_addr_len | | | |mac_client_open | | | |mac_client_close | | | |mac_close | | | |mac_header | | | |mac_multicast_add | | | |mac_multicast_remove | | | |mac_open_by_linkid | | | |___________________________|________________|__________| PSARC/2009/232 Copyright 2009 Sun Microsyst - 4 - _________________________________________________________ | Interfaces Imported | |___________________________|________________|__________| |Interface | Classification| Comments| |___________________________|________________|__________| |mac_promisc_add | | | |mac_promisc_remove | | | |mac_sdu_get | | | |mac_tx | | | |mac_unicast_primary_get | | | |dls_devnet_macname2linkid | | | |mac_client_handle_t | | | |mac_client_promisc_type_t | | | |mac_handle_t | | | |MAC_ADDRTYPE_MULTICAST | | | |MAC_ADDRTYPE_BROADCAST | | | |MAC_ADDRTYPE_UNICAST | | | |MAC_CLIENT_PROMISC_ALL | | | |MAC_CLIENT_PROMISC_FILTERED| | | |MAC_CLIENT_PROMISC_MULTI | | | |MAC_DROP_ON_NO_DESC | | | | | | | | | | | | | | | | | | | |___________________________|________________|__________| 4. Opinion 4.1. Setting the Packet Capture DLT The BPF architecture which allows a single network device name to be used to generate different types of packet cap- ture data, determined by where and how it is presented to BPF by the networking stack. This is different to existing architecture where a specific pathname or socket can only be used to receive a single type of packet. The delivery of the man page for BPF will document the ioctls used with this mechanism and the man page for tcpdump will document how users can use it from the command line. 5. Minority Opinion(s) None. 6. Advisory Information None. PSARC/2009/232 Copyright 2009 Sun Microsyst - 5 - 7. Appendices 7.1. Appendix A: Technical Changes Required No technical changes required. 7.2. Appendix B: Technical Changes Advised No technical changes advised. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/232. 1 commitment.materials/bpf-psarc.txt 2 commitment.materials/pfp-psarc.txt 3 commitment.materials/questions.txt PSARC/2009/232 Copyright 2009 Sun Microsyst --Boundary_(ID_7QWsA8W46FlcOCizuP26/g)--