21 Jan
2021
21 Jan
'21
11:58 a.m.
On 2021-01-20 21:06, Paul Koning wrote:
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.
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.
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