[HECnet] Thousands of DECnet errors on Tops-20

[Paul Koning]

Remember that DEC protocols (at least DECnet and MOP, I don't remember what LAT does) all have a length field following the protocol type field, and the payload comes after that.  As far as the DECnet architecture is concerned, that length field is part of the data link layer, it is how it offers a service of sending packets without a minimum length.  So rather than supporting a DSDU size of 46 to 1500 bytes, the DEC Ethernet datalink supports a DSDU size of 1 to 1498 bytes.  This is why you see 1498 and not 1500 as the max packet size, and why it appears in buffer sizes.

Non-DEC observers normally don't think of that length field as a datalink layer element so from that point of view this is all a bit confusing.  But if you read the DNA Ethernet data link layer spec it's all spelled out clearly and is perfectly consistent.

Given that an Ethernet can potentially carry non-DECnet traffic (certainly does, nowadays) a data link buffer size capable of receiving any size packet that might be thrown at you makes perfect sense.  What doesn't necessarily follow is that this larger buffer size should show up in DECnet protocol messages or protocol behaviors.

	paul

> On Jan 20, 2021, at 6:11 PM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> Another interesting observation:
> 
> All systems I can observe over ethernet (various modern VMS, Ultrix, whatever) seem to like to give a maximum data layer block size of 1498.
> 
> I suspect that this might be related to the two additional bytes I see added in actual communication. Which leads to total packet size of 1500.
> 
> I'm going to change my systems to use 1498 based on this.
> 
>  Johnny
> 
> On 2021-01-20 23:54, Johnny Billquist 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.
>> 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.
>> 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...
>> 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...
>>   Johnny
>> On 2021-01-20 21:06, Paul Koning wrote:
>>> 
>>> 
>>>> On Jan 17, 2021, at 10:45 PM, Thomas DeBellis <tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com>> wrote:
>>>> 
>>>> I think I may have finally gotten to the bottom of this.  It's a level 1 routing message that I'm getting from 2.1023 (A2RTR) that does not appear to be respecting lengths, viz:
>>>> 
>>>> *22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN (0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
>>>> 
>>>> This is two (2) bytes over the maximum that Tops-20 can accept.
>>>> 
>>>>     NCP>*SHOW LINE NI-0 CHARACTERISTICS *
>>>>     NCP>
>>>>     22:16:04     NCP
>>>> 
>>>>     Request # 23; Show Line Characteristics Completed
>>>> 
>>>>     Line = NI-0
>>>> 
>>>>       Receive Buffers = 6
>>>>       Controller = Normal
>>>>       Protocol = Ethernet
>>>>       Hardware Address = 00 1F 16 EC CE 47
>>>>       Receive buffer size = *1476*
>>>> 
>>>> It would appear that the 20's are advertising this length in their layer 1 hello messages:
>>>> 
>>>> 22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize *1476* pri 5 hello 15
>>>> 22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize *1476* pri 5 hello 15
>>>> 
>>> The buffer size in the routing message and in the NCP characteristics (1476) is defined as the size of the routing layer message; it does NOT include the data link layer overhead.  So the 14 byte Ethernet header is not part of that count; neither is the 2 byte DEC Ethernet length field -- which DNA considers a data link field.
>>> 
>>> I assume the tcpdump report includes everything after the Ethernet header in the reported length, so 1478 is correct, given that it includes the Ethernet length field.  If TOPS is not expecting that, this would be a bug on its part.
>>> 
>>> That said, I didn't really intend to send packets that big.  The code was supposed to use the minimum of the neighbor buffer sizes or my own, but in one of the two places where the calculation was done the part "my own" was missing.  Fixed in rev 577, so with that you should be seeing 590 byte messages.
>>> 
>>> You should still look at why TOPS-20 is apparently getting the buffer length rules wrong.
>>> 
>>> paul
> 
> -- 
> Johnny Billquist                  || "I'm on a bus
>                                  ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol