[HECnet] Thousands of DECnet errors on Tops-20

[Johnny Billquist]

Oh, right...

And TOPS-20 do seem to be getting something wrong.

If they announce a receive buffer size of 1476, the actual payload they 
need to be able to receive is 1478, on the ethernet level.
This appears to be totally according to spec.

Thomas might need to go and dig really deep into the TOPS-20 DECnet code 
here. Because announcing a blksize of 1476 means that you really should 
expect and accept 1478 byte packets (payload). The first two bytes being 
a length field for the rest, and thus does not count to the actual 
DECnet packet.

RSX announces whatever you configure. The actual receive buffers set up 
on the ethernet controller will have 36 additional bytes added, to cover 
for potential overhead (which means the ethernet overhead of 16 bytes, 
plus the 2 for the length field). Why 36 then, you might ask. Well, just 
because there is a standard overhead allocation factor independent of 
the link layer, so it's the same everywhere. It should be big enough to 
cover the overhead of any link technology. It's just that for ethernet, 
the actual overhead is just 18 bytes. But it does mean that it can deal 
with packets that are even slightly larger than what has been announced 
as acceptable.

   Johnny

On 2021-01-21 11:58, Johnny Billquist wrote:
> 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.
> 
> No. tcpdump length information is just the payload length.
> Which here is consistent with the receive buffer size.
> The receive buffer size is 1476. DECnet adds the two bytes for length 
> information, which leads to a total payload of 1478, which is also the 
> size of the packet that tcpdump reports.
> 
> The ethernet headers are not included here.
> 
>> 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.
> 
> My understanding was that even the "broken" code would not be sending 
> anything close to 1500 bytes. Did I get that wrong?
> 
>> You should still look at why TOPS-20 is apparently getting the buffer 
>> length rules wrong.
> 
> I would be more interested in why TOPS-20 wants 1476, while most other 
> things goes for 1498, if we're not going for the 576. Not sure TOPS-20 
> actually does anything wrong in any other way...
> 
>    Johnny
> 

-- 
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