[HECnet] Thousands of DECnet errors on Tops-20

[Paul Koning]

> On Jan 20, 2021, at 5:54 PM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> Hey, speaking of this...
> 
> I decided to go and check how RSX actually works. And that have led to some interesting observations on my side.
> 
> 1. RSX actually do respect the maximum data layer block size the other end sends in its init message. So even if I have a large size defined in RSX, it should be working correct against another end with a smaller block size.

Yes, and that behavior is exactly what the spec intended.

> 2. With a block size of 576 (either local or remote), the actual packets being sent are 578 bytes. Seems there is a 2 byte checksum that is in addition to the actual payload. I found this a bit surprising, but it seems this might be very intentional. So I'm trying to see if this also is true for other systems. If someone else can do some checking that would also be interesting.

You mean the routing messages?  Yes, they end in a 2 byte checksum, but that is part of the message and is required to be included in the size limit.  If an implementation is told block size 576 and it sends 578 byte routing messages, that's a bug.  Apparently one it gets away with, but it's not supposed to do that.

Is this on Multinet?  I would expect this sort of thing to be caught on DDCMP.  For example, DECnet/E allocates DMC buffers of the precise size you ask for, so if you were to send it a routing message 2 bytes longer than expected, DDCMP would reject it as an oversized packet and the link would go down due to excessive retransmits.

> 3. VMS V5.4 seem to not be happy at all if the other end declares a largee maximum data layer block size that the local one. This is the problem I had when talking to a VAX at Peter, which is running V5.4. I have no idea if that problems is still there in V7...

That's ugly and a definite bug.

> It would be really interesting to have a Multinet VMS machine setup in the same area as me, with a link to RSX, so I could do some more testing...

	paul