From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 6-DEC-1989 19:52 To: MRGATE::"ARISIA::EVERHART" Subj: RE: Questions about ethernet promiscuous mode. Message-Id: <8912070046.AA07042@crdgw1.ge.com> Received: From VENUS.YCC.YALE.EDU by CRVAX.SRI.COM with TCP; Wed, 6 DEC 89 15:07:55 PDT Date: Wed, 6 Dec 89 18:07 EST From: Leichter-Jerry@CS.YALE.EDU Subject: RE: Questions about ethernet promiscuous mode. Sender: LEICHTER@Venus.YCC.Yale.Edu To: STURTEVANT@CCC.NMFECC.GOV, INFO-VAX@KL.SRI.COM X-Vms-To: IN%"STURTEVANT@CCC.NMFECC.GOV" I run the ethernet controller in promiscuous mode on my VAXstation 3200. As I run my program to collect statistics, I detect some strange ethernet types appearing (returned from the $qio call in the P5 buffer, bytes 12 and 13). The values I see (in hex) are: 1111 2020 6666 AAAA C4C4 FFFF Looking at the remaining portion of the P5 buffer reveals all zeroes (bytes 14 through 19). The following is a guess; I don't have the right documentation handy to check it: What I strongly suspect is happening is that the driver is parsing a IEE802-format packet for you. The evidence: A "long" P5 buffer - Ethernet packets should only give you 14 bytes - and the pattern of the values you see, always xyxy. The direct analogue of an Ethernet protocol field is an 802 DSAP/SSAP pair. Each of these are one-byte values, and in most cases the DSAP and SSAP will be the same (though they don't HAVE to be). The first 12 bytes appear to have a pair of ethernet addresses in them. Examining the IOSB shows a normal completion status (SS$_NORMAL), a transfer size of greater than 46 bytes and less than 1500 bytes, a single bit set in the "unit and line status" field (XM$M_STS_ACTIVE), and all "error summary" bits clear. I could try and track-down the source/destination machines, but we have so much equipment attached to our ethernet, it would not be an easy task to determine what machines "own" these ethernet addresses. Additionally when I run our packet sniffer to trap these packets (filtering only on ethernet-type), no packets are detected. But my utility, at the same time, reports these types of packets as being present on the wire. Obviously I'm missing the boat here! What gives? If my hypothesis is correct, you won't see these packets because the values in the P5 buffer are NOT Ethernet protocol types. See if you can get your snif- fer to pick up 802 packets with a given DSAP/SSAP. Next topic: The I/O user's guide states that a IO$_READ performed while in promiscuous mode causes the following: o Padded ethernet frames (with a size-word) are passed directly into the P1 buffer in the first word of data. How can one detect when this has happened? You can't. There is no indication in the frame itself that this is happening. It is up to the users of a protocol to agree whether to pad or not. o After a read has completed, the user is supposed to check the P5 buffer to determine the format of the packet. I assume that this is indicated by the presence of a value in the CTL field and/or 5-byte protocol identifier. Can the CTL and/or 5-byte protocol identifier field contain the value zero? If so, what other test can be performed differentiate between Ethernet and 802 formats (non-zero SSAP and DSAPs are not enough)? The generic test, if you look at the raw data in the packet, is to examine bytes 12 and 13. View them as a 16-bit number, but as a big-endian number - that is, as 256 * byte 12 + byte 13. If this value is > 1500, it is an Ethernet packet and this is the protocol value. Otherwise, this is an 802- style packet and this value is the packet length. As far as I know, the driver is performing exactly this test and is providing either a 14- or a 20-byte P5 buffer depending on the result. Note also that the 6-byte protocol number (where did you get 5?) is only present in certain classes of 802 packets. -- Jerry