21 Jan
2021
21 Jan
'21
3:30 a.m.
On 2021-01-21 02:37, Paul Koning wrote:
Right. All good. I previously was wondering if RSX might just use the
own buffer size, which would then be the reason it fails to talk to that
VMS V5.4 node, but this is not the case...
Yeah. Got it sorted now. I misunderstood the code the first time.
I agree. I would really like to investigate things more here.
I struggled a lot with this, and only when I put RSX to use 576 byte
buffer size did I finally manage to establish a link up.
But looking at the packets, everything seems to be just as expected even
when I set RSX to use 1500 bytes, but VMS just refuse to accept the link
then. And the only difference is just that one field in the init message
that declares the buffer size of the node.
I tried a lot of different values between 576 and 1500. Nothing above
576 works.
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
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.
Well, now we need to clarify what we mean by 576 or 578 byte messages.
The 576 is what is reported in the init message, and is what the each
node knows the other accept. 578 is the number of bytes in the payload
on the wire.
And in this case, the wire is ethernet. So essentially what tcpdump reports.
So, in the DECnet sense, it's still 576 bytes. But then you have those
two extra bytes at the start, making it 578.
And of course, any ethernet driver actually need to read 578 bytes, in
order to get the 576 bytes at the DECnet link layer.
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.