VLAN observability enhancement ============================== Release binding: patch Commitment level: Stable Problem area ============ PSARC 2000/147 introduced VLAN support for Ethernet devices. However, it did not clearly state how or when VLAN packets could be sent or received by DLPI consumers, or how VLAN packets would be accounted by the system. Thus, different network drivers have implemented different semantics, leading to inconsistent or even incorrect behavior. * Specifically, today, snooping on a physical link only reports untagged * packets. Customers would like to observe all traffic, including VLAN * traffic when snooping over a physical link. * In addition, currently, snoop(1M) does not have the ability to filter on VLAN-tagged packets, which will become a problem if the above issue * is addressed. * Proposal overview ================= To address the mentioned problem, this case: * clearly defines the semantics of DL_PROMISC_SAP and the DLIOCRAW ioctl, and how they affect network observation behavior in a VLAN environment. * discusses some common network kstats and their semantics in a VLAN environment. * discusses changes made to pfmod(7M) and snoop(1M) which are * necessary for snoop to be able to capture and filter VLAN packets. * DL_PROMISC_SAP ============== If a stream enables promiscuous mode at the DL_PROMISC_SAP level, based on its physical-level promiscuous setting, the stream is able to receive packets of all SAP (Ethernet type) values, no matter what SAP it is bound to. Note that to a stream attached to a physical link, all VLAN packets have SAP value 0x8100. Therefore, we propose that all VLAN packets be sent upstream if the physical stream is in DL_PROMISC_SAP promiscuous mode. As a result, if snooping on a physical link, VLAN tagged packets will be visible if they pass the physical-level filter. DLIOCRAW ======== PSARC/2005/626 discussed the DLIOCRAW ioctl semantics in detail: "The DLIOCRAW ioctl function is used by some DLPI applica- tions, most notably the snoop(1M) command. The DLIOCRAW com- mand puts the stream into a raw mode, which, upon receive, causes the the full MAC-level packet to be sent upstream in an M_DATA message instead of it being transformed into the DL_UNITDATA_IND form normally used for reporting incoming packets. Packet SAP filtering is still performed on streams that are in raw mode; if a stream user wants to receive all incoming packets it must also select the appropriate promis- cuous modes. After successfully selecting raw mode, the application is also allowed to send fully formatted packets to the driver as M_DATA messages for transmission. DLIOCRAW takes no arguments. Once enabled, the stream remains in this mode until closed." But it does not specifically discuss the semantics of DLIOCRAW in * a VLAN environment. To address this ambiguity, we propose: * - For streams attached to a physical link (e.g., bge0) * * On the receive-side, the streams in the raw mode must send * the VLAN tagged packets upstream as they are, without * stripping off the VLAN headers from the packets. * * On the transmit-side, the streams in the raw mode must keep * the VLAN headers in the VLAN packets intact before it sends * them out on the wire. * Note that above semantics also applies to the special priority * tagged packets, which have VLAN header but with zero VLAN ID * and non-zero priority bits (see the IEEE 802.1D standard). * - For streams attached to a VLAN link (e.g., bge1000) * * On the receive-side, the streams in the raw mode must only * accept the VLAN tagged packets with the correct VLAN IDs. * If the priority bits are zero, the streams must strip off * the VLAN headers (but not the preceding Ethernet headers) * before passing the packets upstream; otherwise, the streams * will use the reserved tag 0 to encode the VLAN TCI and send * up the packets. * * On the transmit-side, the packets sent down to the streams in * the raw mode will have either Ethernet headers (but no VLAN * headers), or VLAN headers with the special priority tags * (VLAN IDs are zero). The streams must insert(encode) the * VLAN tags into the packets before sending them out on the wire. * Note that the above proposal implies a (never documented) interface * to request certain QoS control of a packet on a raw stream: the packet * will have a VLAN header with its priority bits set but a VLAN ID of * zero. * PSARC 2000/147 defines another two QoS driver interfaces to set * the priority value when sending a packet. The priority value can be * specified: * - on a per-stream basis using the DL_UDQOS_REQ request, it will * remain unchanged until the next DL_UDQOS_REQ is sent. * - on a per-packet basis either using the b_band field of a M_DATA * message or the dl_priority field of a DL_UNITDATA_REQ. * To avoid confusion, the per-packet mechanisms defined above will only * be used when the stream is not in raw mode. If DLIOCRAW is used, * the stream will respect the priority value set in the VLAN header, * or use the per-stream priority value set by DL_UDQOS_REQ if the * priority is not set in the VLAN header. * As a result of the proposed DLIOCRAW semantics, if snooping over an * physical network link, users will see packets with full MAC headers, * including non-tagged packets, VLAN packets with VLAN headers and * the special priority tagged packets; and if snooping over a VLAN * link, users will only see packets targeted on this VLAN, with the * VLAN tags already be stripped off, with the exception of the special * priority tagged packets. * Network kstats ============== PSARC/1997/198 discussed some common network kstats and their semantics: kstat name SNMP variable type commitment lvl. multircv ifInMulticastPktsi ui32 evolving brdcstrcv ifInBroadcastPkts ui32 evolving multixmt ifOutMulticastPkts ui32 evolving brdcstxmt ifOutBroadcastPkts ui32 evolving rbytes ifInOctets ui32 evolving norcvbuf ifInDiscards ui32 evolving unknowns ifInUnknownProtos ui32 evolving obytes ifOutOctets ui32 evolving ipackets rsIfInPackets ui32 stable opackets rsIfOutPackets ui32 stable rbytes64 ifHCInOctets ui64 evolving ipackets64 rsIfInPackets ui64 evolving obytes64 ifHCOutOctets ui64 evolving opackets64 rsIfOutPackets ui64 evolving noxmtbuf ifOutDiscards ui32 evolving collisions rsIfCollisions ui32 stable ierrors ifInErrors ui32 stable oerrors ifOutErrors ui32 stable In order to match the observation behavior over a physical network link, for kstats listed above, we propose that VLAN traffic statistics be counted as statistics of a physical network link. As the result, * the kstats of a physical link (e.g., bge0) will represent a sum of * both tagged (VLAN) and untagged packets on the wire. * pfmod ===== Because of the proposed changes to DLIOCRAW and DL_PROMISC_SAP, snoop will be able to receive packets with VLAN headers. However, * snoop is not currently able to capture, filter, or display VLAN * packets. Enhancing snoop to capture and display VLAN packets is * straightforward, but filtering support requires adding new * operations to the pfmod kernel packet filter. * Specifically, when possible, snoop filters packets in kernel-space using pfmod, which is an implementation of CMU/Stanford Packet Filter (CSPF). CSPF, as originally designed, is a language for a simple stack machine whose only storage is a stack. Indirection and branching are not supported. Offsets are fixed and must be determined at the time the packet filtering program is generated. There is no provision for indirect addressing in pfmod, or to have variable offsets. Therefore, there is no way to parse variable length headers, headers that may appear after the variable length header, or any other instance of dynamic packet structure. VLAN tagged packets are an instance of a dynamic packet structure because the VLAN header is inserted between the link layer header and the network layer header, thus changing packet structure from the packet structure where there are no VLANs. There is no way to determine, when snoop generates a packet filtering program, if snoop will be filtering on a network that involves VLANs. In order to solve this problem, we will add indirection, forward branching, and extra stack operations to pfmod. * Indirection - pfmod will have extra storage, in the form of an offset register. The offset register will be initialized to zero. The ENF_PUSHWORD instruction will change such that the offset register will be used in determining where to get the data. See the document impact section for details. ENF_PUSHWORD is the only existing instruction whose semantics change. Since the offset register is zero by default, then no user of pfmod will be affected by these changes unless that user makes use of the new instructions. * Forward branching - Two forward branching instructions, ENF_BRFL and ENF_BRTR, will be added. It will not be possible for these branches to go backwards in order to protect against a malicious user causing an infinite loop in the kernel. See document impact section for more details on the instructions. * Extra stack operations - A pop operation is added to pfmod. The pop operation exists to remove an element from the stack without performing any operations on it. These three things combined give us the ability to generate programs that can detect if a packet has a VLAN header, and then to change the offsets it uses. More details, along with background information can be found in the documents on the OpenSolaris Clearview project page for VLAN filtering at: http://www.opensolaris.org/os/project/clearview/vlan_filtering/ snoop * ===== * Snoop will be modified to accept two new filtering expressions to * make packet capture on a VLAN enabled interface easier. One existing * expression will have its semantics change. Snoop's output will * change so that if the packet is VLAN tagged and the VLAN ID is not * zero, that information will be displayed. * The new expressions are: * * vlan - This expression will match any packet with ethertype VLAN * whose VLAN ID is not zero. Packets with VLAN ID of zero are * handled differently because those are used to encode priority * information. * * vlan-id - This expression will match any packet whose ethertype * is VLAN and whose VLAN ID is the same as the ID given in the * expression. Unlike with the vlan expression, packets with * ethertype VLAN whose ID is zero will not be treated differently. * These packets, on a physical link, introduce a VLAN header * that DLIOCRAW applications might not be expecting. Treating * these packets allows administrators to easily troubleshoot * any problems that might occur. * The semantics of snoop's ethertype expression will change so that * any existing customer scripts will continue to capture the same * packets. * The following are examples of snoop's new output for when it displays * a packet with a VLAN header. * Example 1: Default summary mode * VLAN#123: 192.168.2.42 -> 192.168.2.66 ICMP Echo request (ID: 35366 Sequence number: 0) Example 2: -V output mode * ________________________________ 192.168.2.42 -> 192.168.2.66 ETHER Type=0800 (IP), VLAN ID=123, size=106 bytes 192.168.2.42 -> 192.168.2.66 IP D=192.168.2.66 S=192.168.2.42 LEN=84, ID=5395, TOS=0x0, TTL=255 192.168.2.42 -> 192.168.2.66 ICMP Echo request (ID: 35367 Sequence number: 0) Example 3: -v output mode * ETHER: ----- Ether Header ----- * ETHER: * ETHER: Packet 1 arrived at 13:52:2.50694 * ETHER: Packet size = 106 bytes * ETHER: Destination = 0:7:e9:24:45:93, * ETHER: Source = 0:3:ba:45:a6:d4, * ETHER: VLAN ID = 123 * ETHER: VLAN Priority = 0 * ETHER: Ethertype = 0800 (IP) * ETHER: * IP: ----- IP Header ----- * IP: * IP: Version = 4 * IP: Header length = 20 bytes * IP: Type of service = 0x00 * IP: xxx. .... = 0 (precedence) * IP: ...0 .... = normal delay * IP: .... 0... = normal throughput * IP: .... .0.. = normal reliability * IP: .... ..0. = not ECN capable transport * IP: .... ...0 = no ECN congestion experienced * IP: Total length = 84 bytes * IP: Identification = 5396 * IP: Flags = 0x0 * IP: .0.. .... = may fragment * IP: ..0. .... = last fragment * IP: Fragment offset = 0 bytes * IP: Time to live = 255 seconds/hops * IP: Protocol = 1 (ICMP) * IP: Header checksum = 20d8 * IP: Source address = 192.168.2.42, 192.168.2.42 * IP: Destination address = 192.168.2.66, 192.168.2.66 * IP: No options * IP: * ICMP: ----- ICMP Header ----- * ICMP: * ICMP: Type = 8 (Echo request) * ICMP: Code = 0 (ID: 35368 Sequence number: 0) * ICMP: Checksum = 8ff * ICMP: * See the document impact section for more details on these changes. * Application impact =================== * Network observation applications As already discussed, network observation applications (which make use of the DL_PROMISC_SAP promiscuity and the DLIOCRAW ioctl) will be able to see VLAN packets (with VLAN headers) on physical links, and will * perhaps see packets with VLAN headers on a VLAN link (in the case of * special priority tagged packets). * Third party network observation tools that depend on libpcap (such as tcpdump and ethereal) will not be affected by the changes to pfmod. Libpcap is a wrapper around whatever packet capture or packet filtering facilities are provided by the native operating system. The * current version of libpcap does not make use of pfmod on Solaris. Libpcap on Solaris uses bufmod to pull packets into user space and then relies on a user space implementation of Berkeley Packet Filter (BPF) to perform filtering operations. Users that use libpcap-based packet capture tools such as tcpdump and ethereal will need to include a vlan expression in their packet * filtering expression if they want to capture VLAN tagged traffic on an * interface configured with VLANs while attached to the physical link. * Third party tools that make use of pfmod will find that their current programs will continue to work, and if used in an environment without VLAN tagged packets, will continue to behave the same way. If the * tool is attached to the physical interface and the tool user wants * to filter on VLAN tagged packets, then the tool will have to generate * a different program. * * MIB-II consumers PSARC/1997/198 declared that the listed set of network kstats were suitable for use for MIB-II purposes. As a result, MIB-II consumer (applications like netstat and the SNMP daemon) are gathering information by reading these network statistics. But that PSARC case didn't clearly define the semantics of these kstats in a VLAN environment. There are concerns that those MIB-II consumers might assume the kstats of a physical link only represent the non-VLAN view of the statistics, and if it represents a composite view of both VLAN tagged statistics and untagged statistics, it may cause problem. An option is to introduce another set of "physical kstats" to count both VLAN and non-VLAN traffic and and keep the current set of kstats to only count non-VLAN traffic. But we decide to make the above network kstats represent both VLAN and non-VLAN statistics for several reasons: - The characteristic of VLAN packets To the physical link, VLAN packets are just packets with SAP value 0x8100. They are no more special than other packets, for example, IP packets. - Consistency among network drivers Note that legacy network drivers -- even those that support VLANs -- use the same network kstats for both VLAN and non-VLAN traffic. Thus, if we changed the kstat semantics to only count non-VLAN traffic, the result would be inconsistent semantics unless the legacy drivers were also updated. However, it is not feasible to track down and modify all legacy drivers since many are owned by third parties. Indeed, a design goal of Nemo Unification (http://www.opensolaris.org/os/project/clearview/uv-design.pdf) is to provide the VLAN support without changing legacy drivers. In addition, we believe that the above also proves that the MIB-II consumers will not be affected by our proposed kstats semantics. - Consistency between "dladm" and "netstat" The "dladm show-link -s" command is used to display network statistics of each link. The statistics it reports include both VLAN and non-VLAN statistics. Presenting different view by "dladm show-link -s" and "netstat -i" will only cause confusion. * pfmod consumers The only pfmod consumers in the OS/Net consolidation are dhcpagent, in.dhcpd, and snoop. Dhcpagent and in.dhcpd do not use DLIOCRAW and so should require no * changes. * Snoop will change to generate pfmod programs using the new features so that it will continue to work correctly in a VLAN environment. Network driver impact ===================== We will coordinate to update all Sun supported drivers to adhere to this proposal. Note that the behavior changes we propose only affect network drivers that support VLANs: - The clearview team will change both GLDv2 and GLDv3 to make sure drivers written to the GLD framework work correctly. - SSG/NSN is already aware of this proposal and they will change the ce driver accordingly (bug 4722784). - There are very few third-party monolithic drivers that have VLAN * support. Syskonnect might be one of them, and we are contacting the * relevant people to see the options to update their drivers to be * consistent with our proposal. * Document impact =============== * dlpi(7P) - Evolving As VLAN is DL_ETHER specific, a media type specific subsection will be added into the dlpi(7P) manpage. Below are proposed context diffs. Note that in order to make the manpage clear, the proposed manpage changes include both the behavior specified (but never documented) by PSARC 2000/147 and the new behavior proposed by this new case. The parts are new with this case are marked with the changebars on the right: *** dlpi.origin.text Fri Apr 21 17:12:24 2006 --- dlpi.new.text Mon May 8 14:48:41 2006 *************** *** 317,323 **** --- 317,383 ---- this mode until closed. + DL_ETHER SPECIFIC DLPI SEMANTICS + VLAN Support + + VLAN PPA Access + + Some DL_ETHER DLPI providers support IEEE 802.1Q Virtual + LANs (VLANs). For these providers, traffic for a particu- + lar VLAN can be accessed by attaching to (or opening) a + special VLAN PPA that is calculated from the VLAN ID and + the actual hardware PPA of the device. This VLAN PPA is + calculated by multiplying the VLAN ID by 1000 and adding + the hardware PPA. For instance, VLAN PPA 2001 provides + access to VLAN ID 2 on hardware PPA 1. As with hardware + PPA's, a DLPI provider may provide either or both + DL_STYLE1 or DL_STYLE2 access to a given VLAN PPA, and + portable DLPI consumers must try both DLPI styles before + concluding that a DL_ETHER DLPI provider does not offer + VLAN support. + + Unless raw mode is enabled, a DLPI stream bound to a VLAN + PPA behaves no differently than a traditional DLPI stream. + In particular, as with hardware PPAs, data must be sent + to a DLPI provider without any link-layer headers (which + will then be added by the provider), and received data + will be passed to interested DLPI consumers without any + link-layer headers. Thus, DLPI consumers do not require + special-case logic to make use of VLAN PPAs. + + Hardware PPA Access + + As per IEEE 802.1Q, all VLAN traffic is sent using Ether- + Type 0x8100. As such, in addition to attaching to the VLAN + PPA, all VLAN traffic for a given hardware PPA can also be + accessed by attaching to the hardware PPA and binding to + SAP 0x8100. In this case, all VLAN traffic, regardless of + VLAN ID, can be sent and received by the DLPI consumer. + However, even when raw mode is disabled, packets will be + received starting with their VLAN headers, and must be sent + to the DLPI provider with their VLAN headers already pre- + pended (but without Ethernet headers). Because adhering to + these semantics requires each DLPI consumer to have specia- + lized knowledge of VLANs, VLANs should only be accessed in + this manner when the VLAN PPA access method is insufficient + (e.g., because access to all VLAN traffic, regardless of + VLAN ID, is needed). + + Further, since all VLAN traffic is sent with SAP 0x8100, if | + a DLPI consumer enables promiscuous mode of a stream at the | + DL_PROMISC_SAP level, all VLAN traffic that was not fil- | + tered at the physical (DL_PROMISC_PHYS) level will also be | + visible. As before, these packets will also be received | + starting with their VLAN headers if raw mode is not enabled. | + + QoS Support * + + The IEEE 802.1D standard defines eight classes of priority * + values used by QoS traffic control of Ethernet packet. The * + priority values, although are encoded in the 802.1Q tags, * + can be used independently from VLANs. In particular, a * + special priority tagged packet (with VLAN ID zero but * + priority bits non-zero) does not belong to any VLANs. * + + The priority value can be set on either per-stream or per- * + packet basis. Specifically, DLPI consumers can: * + + - specify the per-stream priority using the DL_UDQOS_REQ * + request. The priority value will remain unchanged until * + the next DL_UDQOS_REQ. * + + - specify the per-packet priority value using the b_band * + field of a M_DATA message or the dl_priority field of a * + DL_UNITDATA_REQ. * + + raw mode | * + + Hardware PPA Access | * + + If raw mode is enabled, then the complete, unmodified MAC- | * + level packet -- including Ethernet and VLAN headers -- | * + will be passed to interested DLPI consumers. Similarly, | * + the entire MAC-level packet -- including Ethernet and VLAN | * + headers -- must be sent to the DLPI provider for transmi- | * + ssion. Note that the priority value (if any) can also be | * + encoded into the VLAN header, and the priority value spe- | * + cified in the b_band field will be ignored. | * + + VLAN PPA Access | * + + If raw mode is enabled, only packets with the correct VLAN | * + ID will be passed up to the interested DLPI consumers. | * + DLPI providers must strip off the VLAN headers (but not the | * + preceding Ethernet headers) before sending up the packets, | * + with the exceptions of priority tagged packets. In that | * + case, DLPI providers must use the reserved tag 0 to encode | * + the VLAN TCI and send up the packets. | * + + Similarly, on the transmit-side, DLPI consumers must send | * + the packets down to the DLPI providers without the VLAN | * + headers (but with the Ethernet headers), unless certain | * + QoS support is required. In that case, the packet can | * + have the VLAN header to indicate the priority value but | * + its VLAN ID must be zero. The DLPI providers will then | * + insert the VLAN tags or encode the VLAN tags using the | * + priority value specified in the VLAN headers, and send the | * + packets out on the wire. | * FILES Files in or under /dev. * pfmod(7M) Below are proposed context diffs of pfmod(7M) manpage: *** pfmod.original.text Thu Apr 6 12:42:01 2006 --- pfmod.new.text Tue May 9 08:52:32 2006 *************** *** 104,122 **** (The priority field mentioned above is ignored in this implementation.) Each filter command list specifies a sequence of actions that operate on an internal stack of ! ushort_ts ("shortwords"). Each shortword of the command list ! specifies one of the actions ENF_PUSHLIT, ENF_PUSHZERO, ! ENF_PUSHONE, ENF_PUSHFFFF, ENF_PUSHFF00, ENF_PUSH00FF, or ! ENF_PUSHWORD+n, which respectively push the next shortword ! of the command list, zero, one, 0xFFFF, 0xFF00, 0x00FF, or ! shortword n of the subject message on the stack, and a ! binary operator from the set {ENF_EQ, ENF_NEQ, ENF_LT, ! ENF_LE, ENF_GT, ENF_GE, ENF_AND, ENF_OR, ENF_XOR} which then ! operates on the top two elements of the stack and replaces ! them with its result. When both an action and operator are ! specified in the same shortword, the action is performed ! followed by the operation. The binary operator can also be from the set {ENF_COR, ENF_CAND, ENF_CNOR, ENF_CNAND}. These are "short-circuit" operators, in that they terminate the execution of the --- 104,139 ---- (The priority field mentioned above is ignored in this implementation.) Each filter command list specifies a sequence of actions that operate on an internal stack of ! ushort_ts ("shortwords") or an offset register. The offset ! register is initially zero. Each shortword of the command ! list specifies an action and a binary operator. Using _n_ as ! shorthand for the next shortword of the instruction stream and ! _%oreg_ for the offset register, the list of actions is: ! COMMAND SHORTWORDS ACTION ! ENF_PUSHLIT 2 Push _n_ on the stack. ! ENF_PUSHZERO 1 Push zero on the stack. ! ENF_PUSHONE 1 Push one on the stack. ! ENF_PUSHFFFF 1 Push 0xFFFF on the stack. ! ENF_PUSHFF00 1 Push 0xFF00 on the stack. ! ENF_PUSH00FF 1 Push 0x00FF on the stack. ! ENF_LOAD_OFFSET 2 Load _n_ into _%oreg_. ! ENF_BRTR 2 Branch forward _n_ shortwords if ! the top element of the stack is ! non-zero. ! ENF_BRFL 2 Branch forward _n_ shortwords if ! the top element of the stack is zero. ! ENF_POP 1 Pop the top element from the stack. ! ENF_PUSHWORD+m 1 Push the value of shortword (_m_ + ! _%oreg_) of the packet onto the stack. ! ! The binary operators can be from the set {ENF_EQ, ENF_NEQ, ENF_LT, ! ENF_LE, ENF_GT, ENF_GE, ENF_AND, ENF_OR, ENF_XOR} which ! operate on the top two elements of the stack and replace ! them with its result. + When both an action and operator are specified in the same + shortword, the action is performed followed by the operation. + The binary operator can also be from the set {ENF_COR, ENF_CAND, ENF_CNOR, ENF_CNAND}. These are "short-circuit" operators, in that they terminate the execution of the *************** *** 186,192 **** The reverse ARP daemon program may use code similar to the following fragment to construct a filter that rejects all but RARP packets. That is, is accepts only packets whose ! Ethernet type field has the value ETHERTYPE_REVARP. struct ether_header eh; /* used only for offset values */ --- 203,210 ---- The reverse ARP daemon program may use code similar to the following fragment to construct a filter that rejects all but RARP packets. That is, is accepts only packets whose ! Ethernet type field has the value ETHERTYPE_REVARP. The filter ! will work whether or not a VLAN is configured. struct ether_header eh; /* used only for offset values */ *************** *** 222,227 **** --- 240,254 ---- sizeof (us_short); *fwp++ = ENF_PUSHWORD + offset; *fwp++ = ENF_PUSHLIT; + *fwp++ = htons(ETHERTYPE_VLAN); + *fwp++ = ENF_EQ; + *fwp++ = ENF_BRFL; + *fwp++ = 3; /* If this isn't ethertype VLAN, don't change oreg */ + *fwp++ = ENF_LOAD_OFFSET; + *fwp++ = 2; /* size of the VLAN tag in words */ + *fwp++ = ENF_POP; + *fwp++ = ENF_PUSHWORD + offset; + *fwp++ = ENF_PUSHLIT; *fwp++ = htons(ETHERTYPE_REVARP); *fwp++ = ENF_EQ; pf.Pf_FilterLen = fwp - &pf.Pf_Filter[0]; *************** *** 232,237 **** --- 259,272 ---- *fwp++ = ENF_PUSHWORD + offset; *fwp++ = ENF_PUSHLIT | ENF_EQ; + *fwp++ = htons(ETHERTYPE_VLAN); + *fwp++ = ENF_BRFL | ENF_NOP; + *fwp++ = 3; + *fwp++ = ENF_LOAD_OFFSET | ENF_NOP; + *fwp++ = 2; + *fwp++ = ENF_POP | ENF_NOP; + *fwp++ = ENF_PUSHWORD + offset; + *fwp++ = ENF_PUSHLIT | ENF_EQ; *fwp++ = htons(ETHERTYPE_REVARP); * snoop(1M) Below are the proposed man page diffs for snoop. *** snoop.old.txt Tue May 23 13:39:13 2006 --- snoop.new.txt Wed Jun 7 16:40:02 2006 * *************** * *** 24,34 **** * snoop can display packets in a single-line summary form or * in verbose multi-line forms. In summary form, only the data * ! pertaining to the highest level protocol is displayed. For * ! example, an NFS packet will have only NFS information * ! displayed. The underlying RPC, UDP, IP, and ethernet frame * ! information is suppressed but can be displayed if either of * ! the verbose options are chosen. * In the absence of a name service, such as LDAP or NIS, snoop * displays host names as numeric IP addresses. * --- 24,37 ---- * snoop can display packets in a single-line summary form or * in verbose multi-line forms. In summary form, only the data * ! pertaining to the highest level protocol is displayed. * ! Except that if the packet has a VLAN header and its VLAN ID * ! is non-zero then snoop will show that the packet is VLAN * ! tagged. For example, an NFS packet will have only NFS * ! information displayed. The underlying RPC, UDP, IP, and * ! Ethernet frame information is suppressed (except for VLAN * ! information under the conditions stated earlier) but can be * ! displayed if either of the verbose options are chosen. * In the absence of a name service, such as LDAP or NIS, snoop * displays host names as numeric IP addresses. * *************** *** 450,457 **** ethertype number ! True if the ethernet type field has value number. ! Equivalent to "ether[12:2] = number". --- 450,459 ---- ethertype number ! True if the Ethernet type field has value number. ! If number is not 0x8100 (VLAN) and the packet is ! VLAN tagged, then the expression will match the ! encapsulated Ethernet type. *************** * *** 471,478 **** * --- 473,488 ---- * * True if the packet is of the appropriate ethertype. * * + vlan * + * + True if the packet has ethertype VLAN and the VLAN ID * + is not zero. * * + vlan-id id * * + True for packets of ethertype VLAN with the id id. * + * + * pppoe * * True if the ethertype of the packet is either pppoed *