Xref: utzoo comp.protocols.misc:964 comp.sys.dec:3877
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!slxsys!ibmpcug!ctssuk!VERKADE
From: VERKADE@CTSS.CO.UK (Herman Verkade)
Newsgroups: comp.protocols.misc,comp.sys.dec
Subject: Re: DECNET Phase IV routing packets
Message-ID: <900825003741.00000359@MARVIN.CTSS.CO.UK>
Date: 25 Aug 90 00:37:41 GMT
References: <137@nic.cerf.net>
Organization: CompuThoughts Software Solutions (UK) Ltd
Lines: 34

In article <137@nic.cerf.net>, hutton@nic.cerf.net (Tom Hutton) writes:
>Does anyone have a program for cracking DECNET routing packets.  We
>are attempting to track down some strange DECnet behavior and hex dumps
>of routing packets are not much help.   (If someone had the structures
>of the routing packets that would be of great help.   The DEC documents
>that I have are very vague in this area)

I don't have a program, but I do have the layout documented somewhere.
Unfortunately, I have just moved and it is somewhere in one of the 30 million
boxes in my study. From the top of my head: A routing packet contains one or
more routing update packets. Each of them starting off with two bytes in which
10 bits identify a base address and 5 bytes identify a count, followed by
`count' words containing cost/hops information. Don't quote me on the absolute
positioning of the fields in the words, but it's something like:

  08 40 01 04 01 04 01 04 00 00 ff ff 02 08 01 04 01 04

means:

  Subpacket contains info for 8 nodes starting off with 40 (hex)

  Node 64 (40 hex) is 1 hop away with cost 4
  Node 65 is 1 hop away with cost 4
  Node 66 is 1 hop away with cost 4
  Node 67 is 0 hop away with cost 0, i.e. it is the sender of the packet
  Node 68 is unreachable
  Node 69 is 2 hop away with cost 8
  Node 70 is 1 hop away with cost 4
  Node 71 is 1 hop away with cost 4
  
It is documented in the documents for DECnet Architecture and Protocols course.
If you want the precise info, send me mail and I'll forward it in a few days.

Herman Verkade