ed@mtxinu.UUCP (Ed Gould) (04/23/85)
> I could see three types of packets going past. One came from the > rwho daemon (IP Type 0x800, UDP Type 0x11, Port 0x201) and one > had type field 0x806 and was clearly the Address Resolution Protocol. > However, the third type of packet had a type field of 0x6002 and > is a complete mystery. Can anyone tell me what it is? It's a trailer packet. The real header is at the end. This is a non-standard addition to IP, used on VAXen to avoid extra data copies when the data is otherwise page-aligned. Transmission of trailer packets can be disabled by /etc/ifconfig <interface> -trailers if desired. -- Ed Gould mt Xinu, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146
chris@umcp-cs.UUCP (Chris Torek) (04/26/85)
> It's a trailer packet.
Funny, my netinet/if_ether.h says
#define ETHERPUP_TRAIL 0x1000
(which means the trailer types are 0x1000 to 0x100f), which would leave
0x6002 still unexplained.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandrobert@cheviot.UUCP (Robert Stroud) (04/26/85)
We have an Ethernet with two VAXes running 4.2 BSD at one end, and various Perqs at the other end. The Perqs use ISO protocols rather than DOD Arpanet protocols, so normally don't talk to the VAXes. However, I added some tracing to one of them to use it as an Ethernet monitor and watch what went by. Naturally, it should have only picked up broadcast packets or packets specifically addressed to itself. I could see three types of packets going past. One came from the rwho daemon (IP Type 0x800, UDP Type 0x11, Port 0x201) and one had type field 0x806 and was clearly the Address Resolution Protocol. However, the third type of packet had a type field of 0x6002 and is a complete mystery. Can anyone tell me what it is? It is much less frequent than the rwho packets (every 10-20 minutes?), and the Destination address doesn't make any sense to me. I certainly don't see why it is being received by the Perq in question, although it is definitely being sent by one of the VAXes. If it is any help, here are the first few bytes of the protocol in hex... TO: AB00 0002 0000 FROM: AA00 0301 02E0 TYPE: 6002 1c 00 07 00 00 00 01 00 03 03 00 00 02 00 02 05 00 07 00 06 aa 00 03 01 02 e0 64 00 01 01 00 (sixteen times) f3 cc 80 da 80 da 80 da ... By the way, the packet is always the same. Is the TO address some sort of multicast address? (Why is the third part of it zero?). The FROM address corresponds to one of the VAXes. Please mail me, and I'll summarise to the net if there's any interest. Robert J Stroud, Computing Laboratory, University of Newcastle upon Tyne. ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa UUCP ...!ukc!cheviot!robert
robert@cheviot.UUCP (Robert Stroud) (05/01/85)
I asked if anyone knew about some Ethernet packets with type 0x6002 I'd seen flying about on our LAN. It would seem that they are generated automatically by our DEUNA boards every ten minutes. My thanks to George Ross and Steven Bellovin for this information. After searching through the DEUNA manual for a while, I discovered how to turn these messages off using the "Write Mode" command - see section 4.4.9 and table 4-22. Our DEUNA driver obviously doesn't disable this feature at boot-time. I would guess that the Perq is picking up the multicast packets because the 3Com board has been instructed to accept all multicasts, (or perhaps this is its default state - is this part of the 802.3 spec?) Hope this is of some help to anybody else out there who is concerned about just what goes up and down their Ethernet! Robert Stroud (...!ukc!cheviot!robert) ------------------------------------------------------------------------- From: George Ross <ukc!edcaad!cstvax!gdmr> ... According to the DEUNA section of the VMS I/O manual (5B in the V3 set) the destination multicast address of these packets (AB-00-00-02-00-00) corresponds to "Remote Console", and protocol type 6002 also corresponds to "Remote Console". My suspicion is that the DEUNA itself is sending these things, since they are coming from both a VMS machine (which might have been expected) and a UNIX machine (which seems unlikely otherwise). -------------------------------------------------------------------------- From: Steven Bellovin <mcvax!seismo!ulysses!smb> The message is a "system ID" message generated every 10 minutes by your DEUNA boards. (I can tell they're DEUNAs from the source address field.) See Figure 4-34 and Table 4-41 in the DEUNA manual, and the following pages. The destination address you cite, ab-00-00-02-00-00, is indeed a multicast address (the low-order bit of the first byte is on), and is the "Remote Console Service" multicast address.
robert@cheviot.UUCP (Robert Stroud) (05/07/85)
<325@cheviot.UUCP> cancelled from rn.