2 Mar
2026
2 Mar
'26
5:35 p.m.
Greetings!
Mentioning pyDECnet might be a red herring, but that's what I'm using to
connect to HECnet so I'm mentioning it. I'm trying to connect to Mark
Matlock's RSX11M.COM (Static IP:216.177.191.101) and we are getting some weird
errors.
My pyDECnet circuit line looks like this - modeled after Supratim's circuit config
that he sent me last year.:
circuit DDCMP-30-1 DDCMP tcp:60001:rsx11m.com:7728 --t3=15 --cost=9
On Mark's side he has an RSX11M host as the area router and the connection for me
is set up thusly:
MNC SET CIR IP-0-5 MODE DDCMP
MNC SET CIR IP-0-5 TCP HOST 0.0.0.0:0 PORT 7728
NCP SET CIR IP-0-5 STA ON
The connection isn't working. Mark is seeing errors like this:
02:53:40 MLTNET - IP-0-5 Incoming packet size error (1541) from
76.213.76.105:51354. Abort.
02:53:42 MLTNET - IP-0-5 Incoming packet size error (1541) from
76.213.76.105:34404. Abort.
02:53:44 MLTNET - IP-0-5 Incoming packet size error (1541) from
76.213.76.105:34412. Abort.
The A17RTR node has what look to be the normal settings. the Segment buffer size is
normal for DDCMP.
NCP>tell a17rtr show exe char
Node Volatile Characteristics as of 2-MAR-2026 09:35:20
Executor node = 17.1023 (A17RTR)
Identification = THEMIS2 - A17RTR - DECnet/Python Area-17 Router at Saginaw,
TX (DFW)
Management version = V4.0.0
Software identification = DECnet/Python V1.1.0
Incoming timer = 30
Outgoing timer = 30
NSP version = V4.0.0
Maximum links = 4095
Delay factor = 32
Delay weight = 3
Inactivity timer = 300
Retransmit factor = 5
Routing version = V2.0.0
Type = area
Maximum area = 63
Area maximum cost = 128
Area maximum hops = 16
Segment buffer size = 576
Does anyone know what causes the packet size to be bigger than normal? The ethernet
interface on the pyDECnet host is set to 1500MTU as is my firewall/router.
Where else can I look? I don't see anything in the pyDECnet documentation that
talks about DDCMP packet size. Where else can I look?
Regards,
John H. Reinhardt
2 Mar
2 Mar
5:38 p.m.
I don't think I've ever tried that DDCMP mode. I don't even remember
what it does...
Why are you wanting to use it?
Johnny
On 02/03/2026 17.35, John H. Reinhardt wrote:
Greetings!
Mentioning pyDECnet might be a red herring, but that's what I'musing
to connect to HECnet so I'm mentioning it. I'm trying to connect to
Mark Matlock's RSX11M.COM (Static IP:216.177.191.101) and we are getting
some weird errors.
My pyDECnet circuit line looks like this - modeled after Supratim's
circuit config that he sent me last year.:
circuit DDCMP-30-1 DDCMP tcp:60001:rsx11m.com:7728 --t3=15 --cost=9
On Mark's side he has an RSX11M host as the area router and the
connection for me is set up thusly:
MNC SET CIR IP-0-5 MODE DDCMP
MNC SET CIR IP-0-5 TCP HOST 0.0.0.0:0 PORT 7728
NCP SET CIR IP-0-5 STA ON
The connection isn't working. Mark is seeing errors like this:
02:53:40 MLTNET - IP-0-5 Incoming packet size error (1541) from
76.213.76.105:51354. Abort.
02:53:42 MLTNET - IP-0-5 Incoming packet size error (1541) from
76.213.76.105:34404. Abort.
02:53:44 MLTNET - IP-0-5 Incoming packet size error (1541) from
76.213.76.105:34412. Abort.
The A17RTR node has what look to be the normal settings. the Segment
buffer size is normal for DDCMP.
NCP>tell a17rtr show exe char
Node Volatile Characteristics as of 2-MAR-2026 09:35:20
Executor node = 17.1023 (A17RTR)
Identification = THEMIS2 - A17RTR - DECnet/Python Area-17
Router at Saginaw, TX (DFW)
Management version = V4.0.0
Software identification = DECnet/Python V1.1.0
Incoming timer = 30
Outgoing timer = 30
NSP version = V4.0.0
Maximum links = 4095
Delay factor = 32
Delay weight = 3
Inactivity timer =300
Retransmit factor = 5
Routing version = V2.0.0
Type = area
Maximum area = 63
Area maximum cost = 128
Area maximum hops = 16
Segment buffer size = 576
Does anyone know what causes the packet size to be bigger than normal?
The ethernet interface on the pyDECnet host is set to 1500MTU as is my
firewall/router.
Where else can I look? I don't see anything in the pyDECnet
documentation that talks about DDCMP packet size. Where else can I look?
Regards,
John H. Reinhardt
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
5:44 p.m.
Hm. The command "MNC SET CIR IP-0-5 MODE DDCMP" should have given a
warning that this has been deprecated. In essence, it does nothing.
All links are just multinet links, which is DDCMP, with a small header
to just get whole packets when using TCP.
Johnny
On 02/03/2026 17.38, Johnny Billquist wrote:
I don't think I've ever tried that DDCMP mode.
I don't even remember
what it does...
Why are you wanting to use it?
Johnny
On 02/03/2026 17.35, John H. Reinhardt wrote:
Greetings!
Mentioning pyDECnet might be a red herring, but that's what
I'musing to connect to HECnet so I'm mentioning it. I'm trying to
connect to Mark Matlock's RSX11M.COM (Static IP:216.177.191.101) and
we are getting some weird errors.
My pyDECnet circuit line looks like this - modeled after Supratim's
circuit config that he sent me last year.:
circuit DDCMP-30-1 DDCMP tcp:60001:rsx11m.com:7728 --t3=15 --cost=9
On Mark's side he has an RSX11M host as the area router and the
connection for me is set up thusly:
MNC SET CIR IP-0-5 MODE DDCMP
MNC SET CIR IP-0-5 TCP HOST 0.0.0.0:0 PORT 7728
NCP SET CIR IP-0-5 STA ON
The connection isn't working. Mark is seeing errorslike this:
02:53:40 MLTNET - IP-0-5 Incoming packet sizeerror (1541) from
76.213.76.105:51354. Abort.
02:53:42 MLTNET - IP-0-5 Incoming packet sizeerror (1541) from
76.213.76.105:34404. Abort.
02:53:44 MLTNET - IP-0-5 Incoming packet sizeerror (1541) from
76.213.76.105:34412. Abort.
The A17RTR node has what look to be the normal settings. the
Segment buffer size is normal for DDCMP.
NCP>tell a17rtr show exe char
Node Volatile Characteristics as of 2-MAR-2026 09:35:20
Executor node = 17.1023 (A17RTR)
Identification = THEMIS2 - A17RTR - DECnet/Python Area-17
Router at Saginaw, TX (DFW)
Management version = V4.0.0
Software identification = DECnet/Python V1.1.0
Incoming timer = 30
Outgoing timer = 30
NSP version = V4.0.0
Maximum links = 4095
Delay factor = 32
Delay weight = 3
Inactivity timer =300
Retransmit factor = 5
Routing version = V2.0.0
Type = area
Maximum area = 63
Area maximum cost = 128
Area maximum hops = 16
Segment buffer size =576
Does anyone know what causes the packet size to be bigger than normal?
The ethernet interface on the pyDECnet host is set to 1500MTU as is my
firewall/router.
Where else can I look? I don't see anything in the pyDECnet
documentation that talks about DDCMP packet size. Where else canI look?
Regards,
John H. Reinhardt
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
6:42 p.m.
On Mar 2, 2026, at 11:44 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Hm. The command "MNC SET CIR IP-0-5 MODE DDCMP" should have given a warning
that this has been deprecated. In essence, it does nothing.
All links are just multinet links, which is DDCMP, with a small header to just get whole
packets when using TCP.
Johnny
Well, Multinet is not DDCMP, it isn't even in the same province. PyDECnet certainly
supports that, and when used over TCP should work ok in spite of its fundamental design
errors.
DECnet packet sizes are controlled by the executor parameters, in particular the segment
buffer size you mentioned. Yes, Ethernet supports bigger frames, but 576 was the
conventional max size used with DECnet. Actually, DDCMP also supports much bigger frames
(up to 16k is the max the protocol can handle) but that certainly isn't normally done,
especially not on PDP-11s for obvious reasons...
paul
6:46 p.m.
On 02/03/2026 18.42, Paul Koning wrote:
Believe it or not. But my Multinet links in RSX, are run through the
DDCMP point-to-point handler.
All I do is add/remove the Multinet 4 byte header (well, I also make use
of that header, obviously). The rest I never had to touch.
On Mar 2, 2026, at 11:44 AM, Johnny Billquist
<bqt(a)softjar.se>wrote;wrote:
Hm. The command "MNC SET CIR IP-0-5 MODE DDCMP" should have given a warning
that this has been deprecated. In essence, it does nothing.
All links are just multinet links, which is DDCMP, with a small headerto just get whole
packets when using TCP.
Johnny
Well, Multinet is not DDCMP, it isn't even in the same province. PyDECnet certainly
supports that, and when used over TCP should work ok in spite of its fundamental design
errors. DECnet packet sizes are controlled by the executor
parameters, in particular the segment buffer size you mentioned. Yes, Ethernet supports
bigger frames, but 576 was the conventional max size used with DECnet. Actually, DDCMP
also supports much bigger frames (up to 16k is the max the protocol can handle) but that
certainly isn't normally done, especially noton PDP-11s for obvious reasons...
The reason for the size error in the logs is because RSX expects a
Multinet header before the DDCMP packet, which encodes the packet
length. And I do a little bit of sanity checking on it, and that's why
you see the error. I suspect/expect that when you say DDCMP on pyDECnet,
it don't have the Multinet header, so then the first 4 bytes are
interpreted as the Multinet header by RSX, which is not what it actually is.
Johnny
7 p.m.
On Mar 2, 2026, at 12:46 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 02/03/2026 18.42, Paul Koning wrote:
Believe it or not. But my Multinet links in RSX, are run through the DDCMP point-to-point
handler.
All I do is add/remove the Multinet 4 byte header (well, I also make use of that header,
obviously). The rest I never had to touch.
Um, what? Now I'm confused.
Multinet, as implemented in VMS, is a datalink, a "pointt to point" one in
DECnet terminology apart from the fact that it doesn't include the required semantics.
It has the 4 byte header you mentioned, followed by the payload, so after those 4 bytes
you see a routing header.
DDCMP is also a datalink, and there too you have a header (which includes the data length
so it's all self describing) followed by payload, with a CRC at the end.
Did you really mean that you have a Multinet header followed by a DDCMP header? Or did
you just mean that you use the point to point datalink dependent routing sublayer, passing
it the Multinet payload or the DDCMP payload depending on which datalink is used? That
second option is what I would expect, and for Multinet over TCP will work tolerably well
-- at least if you use disconnect and reconnect at the TCP layer to do the datalink
reinitialization that's a required point to point service the Multinet
"designers" didn't bother to implement.
paul
On Mar 2,
2026, at 11:44 AM, Johnny Billquist <bqt(a)softjar.se>wrote;wrote:
Hm. The command "MNC SET CIR IP-0-5 MODE DDCMP" should have given a warning
that this has been deprecated. In essence, it does nothing.
All links are just multinet links, which is DDCMP, with a small headerto just get whole
packets when using TCP.
Johnny
Well, Multinet is not DDCMP, it isn't even in the same province.
PyDECnet certainly supports that, and when used over TCP should work ok in spite of its
fundamental design errors. DECnet packet sizes are controlled by the
executor parameters, in particular the segment buffer size you mentioned. Yes, Ethernet
supports bigger frames, but 576 was the conventional max size used with DECnet. Actually,
DDCMP also supports much bigger frames (up to 16k is the max the protocol can handle) but
that certainly isn't normally done, especially noton PDP-11s for obvious reasons...
The reason for the size error in the logs is because RSX expects a Multinet header before
the DDCMP packet, which encodes the packet length. And I do a little bit of sanity
checking on it, and that's why you see the error. I suspect/expect that when you say
DDCMP on pyDECnet, it don't have the Multinet header, so then the first 4 bytes are
interpreted as the Multinet header by RSX, which is not what it actually is.
3 Mar
3 Mar
1:23 a.m.
On 2026-03-02 19:00, Paul Koning wrote:
Yeah. Sorry. My fault. Using bad terminology here, as well as not really
thinking enough before answering.
On Mar 2, 2026, at 12:46 PM, Johnny Billquist
<bqt(a)softjar.se>wrote;wrote:
On 02/03/2026 18.42, Paul Koning wrote:
Believe it or not. But my Multinet links in RSX, are run through the DDCMP point-to-point
handler.
All I do is add/remove the Multinet 4 byte header (well, I also make use of that header,
obviously). The rest I never had to touch.
Um, what? Now I'm confused. On Mar 2,
2026, at 11:44 AM, Johnny Billquist <bqt(a)softjar.se>wrote;wrote:
Hm. The command "MNC SET CIR IP-0-5 MODE DDCMP" should have given a warning
that this has been deprecated. In essence, it does nothing.
All links are just multinet links, which is DDCMP, with a small headerto just get whole
packets when using TCP.
Johnny
Well, Multinet is not DDCMP, it isn't even in the same province.
PyDECnet certainly supports that, and when used over TCP should work ok in spite of its
fundamental design errors. DECnet packet sizes are controlled by the
executor parameters, in particular the segment buffer size you mentioned. Yes, Ethernet
supports bigger frames, but 576 was the conventional max size used with DECnet. Actually,
DDCMP also supports much bigger frames (up to 16k is the max the protocol can handle) but
that certainly isn't normally done, especially noton PDP-11s for obvious reasons...
The reason for the size error in the logs is because RSX expects a Multinet header before
the DDCMP packet, which encodes the packet length. And I do a little bit of sanity
checking on it, and that's why you see the error. I suspect/expect that when you say
DDCMP on pyDECnet, it don't have the Multinet header, so then the first 4 bytes are
interpreted as the Multinet header by RSX, which is not what it actually is. Multinet, as implemented in VMS, is a datalink, a
"pointt to point" onein DECnet terminology apart from the fact that it
doesn't include the required semantics. It has the 4 byte header you mentioned,
followed by the payload, so after those 4 bytes you see a routing header.
Right. In RSX, such lines are "controlled" by the DDCMP Point
"driver".
But it is named so, because all point-to-point links that existed back
in the DEC days were DDCMP. But the actual DDCMP link layer processing
happens in a lower level driver, and the DDCMP Point driver is just fed
the packet after the DDCMP bits have been stripped. Which is the same as
what you get from the multinet driver, once the multinet header is stripped.
DDCMP is also a datalink, and there too you have a
header (which includes the data length so it's all self describing) followed by
payload, witha CRC at the end.
Right.
Did you really mean that you have a Multinet header
followed by a DDCMPheader? Or did you just mean that you use the point to point datalink
dependent routing sublayer, passing it the Multinet payload or the DDCMP payload depending
on which datalink is used? That second option is what Iwould expect, and for Multinet
over TCP will work tolerably well -- at least if you use disconnect and reconnect at the
TCP layer to do the datalink reinitialization that's a required point to point service
the Multinet "designers" didn't bother to implement.
The latter. Sorry.
But just to point out something else that should be somewhat obvious -
multinet over TCP is better than DDCMP over TCP. You don't need the
DDCMP layer processing, since TCP is already guaranteeing what DDCMP
otherwise provides. So using DDCMP just adds extra processing and bytes
to transfer compared to Multinet, without any actual gain.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:22 a.m.
On Mar 2, 2026, at 7:23 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2026-03-02 19:00, Paul Koning wrote:
...
Mostly true, for DDCMP over TCP. DDCMP also runs very well over UDP, and typically set it
up that way.
As I mentioned, one datalink layer service the routing layer requires is notification of
remote restart. DDCMP does that, Multinet doesn't. At least, not unless it passes an
underlying restart of the TCP connection up to routing. PyDECnet does that, I don't
know if VMS or RSX do. The fact that Multinet over UDP doesn't (can't) do it is
the main defect; it means that a restart of one side messes up the other, potentially for
a long time, because the routing init handshake falls apart without the datalink layer
support.
paul
Did you really mean that you have a Multinet
header followed by a DDCMPheader? Or did you just mean that you use the point to point
datalink dependent routing sublayer, passing it the Multinet payload or the DDCMP payload
depending on which datalink is used? That second option is what Iwould expect, and for
Multinet over TCP will work tolerably well -- at least if you use disconnect and reconnect
at the TCP layer to do the datalink reinitialization that's a required point to point
service the Multinet "designers" didn't bother to implement.
The latter. Sorry.
But just to point out something else that should be somewhat obvious - multinet over TCP
is better than DDCMP over TCP. You don't need the DDCMP layer processing, since TCP is
already guaranteeing what DDCMP otherwise provides. So using DDCMP just adds extra
processing and bytes to transfer compared to Multinet, without any actual gain.
10:40 a.m.
On 03/03/2026 03.22, Paul Koning wrote:
DDCMP will notice and handle out of order packets, but it still means it
have to restart the circuit, so UDP in this case is still not a great
idea. The better option would be to use the same datalink mode/protocol
as ethernet does, which is designed for the occasional dropped packet or
out of order packet.
On Mar 2, 2026, at 7:23 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2026-03-02 19:00, Paul Koning wrote:
...
Mostly true, for DDCMP over TCP. DDCMP also runs very well over UDP,
and typically set it up that way. Did you really mean that you have a Multinet
header followed by a
DDCMPheader? Or did you just mean that you use the point to point
datalink dependent routing sublayer, passing it the Multinet payload
or the DDCMP payload depending on which datalink is used? That
second option is what Iwould expect, and for Multinet over TCP will
work tolerably well -- at least if you use disconnect and reconnect
at the TCP layer to do the datalink reinitialization that's a
required point to point service the Multinet "designers" didn't
bother to implement.
The latter. Sorry.
But just to point out something else that should be somewhat obvious -
multinet over TCP is better than DDCMP over TCP. You don't need the
DDCMP layer processing, since TCP is already guaranteeing what DDCMP
otherwise provides. So using DDCMP just adds extra processing and
bytes to transfer compared to Multinet, without any actual gain. As I mentioned, one datalink layer service the routing
layer requires is
notification of remote restart. DDCMP does that, Multinet doesn't. At
least, not unless it passes an underlying restart of the TCP connection
up to routing. PyDECnet does that, I don't know if VMS or RSX do. The
fact that Multinet over UDP doesn't (can't) do it is the main defect; it
means that a restart of one side messes up the other, potentially for a
long time, because the routing init handshake falls apart without the
datalink layer support.
Multinet links do need to inform DECnet if the link is dropped. VMS does
that, and so do I. Because what happens when the connection is
reestablished is that you get a new init exchange. Which with TCP is
easy and obvious. With UDP it becomes a bit of guesswork. Usually it's
easier to just let DECnet itself declare the circuit down because of
timeouts. But I do also check if I see an init packet, and do a reset in
that case, if I remember right.
Johnny
3:58 p.m.
On Mar 3, 2026, at 4:40 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 03/03/2026 03.22, Paul Koning wrote:
DDCMP will notice and handle out of order packets, but it still means it have to restart
the circuit, so UDP in this case is still not a great idea. The better option would be to
use the same datalink mode/protocol as ethernet does, which is designed for the occasional
dropped packet or out of order packet.
Not true. DDCMP does not restart the link on out of order packets. Instead, it drops the
out of order packet, and then timeout of the ACK will cause it to be retransmitted.
paul
On Mar 2,
2026, at 7:23 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
On 2026-03-02 19:00, Paul Koning wrote:
...
Mostly true, for DDCMP over TCP. DDCMP also runs very well over UDP, and typically set it
up that way. Did you really mean that you have a Multinet
header followed by a DDCMPheader? Or did you just mean that you use the point to point
datalink dependent routing sublayer, passing it the Multinet payload or the DDCMP payload
depending on which datalink is used? That second option is what Iwould expect, and for
Multinet over TCP will work tolerably well -- at least if you use disconnect and reconnect
at the TCP layer to do the datalink reinitialization that's a required point to point
service the Multinet "designers" didn't bother to implement.
The latter. Sorry.
But just to point out something else that should be somewhat obvious - multinet over TCP
is better than DDCMP over TCP. You don't need the DDCMP layer processing, since TCP is
already guaranteeing what DDCMP otherwise provides. So using DDCMP just adds extra
processing and bytes to transfer compared to Multinet, without any actual gain.
5:42 p.m.
On 03/03/2026 15.58, Paul Koning wrote:
Ah. I had the broken understanding that DDCMP also restarted at that
point. Ok, so it resyncs and gets back in order on its own? That's nice.
I haven't looked at DDCMP in years...
Johnny
On Mar 3, 2026, at 4:40 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 03/03/2026 03.22, Paul Koning wrote:
DDCMP will notice and handle out of order packets, but it still means it have to restart
the circuit, so UDP in this case is still not a great idea. The better option would be to
use the same datalink mode/protocol as ethernet does, which is designed for the occasional
dropped packet or out of order packet.
Not true. DDCMP does not restart the link on out of order packets. Instead, it drops
the out of order packet, and then timeout of the ACK willcause it to be retransmitted.
On Mar 2,
2026, at 7:23 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
On 2026-03-02 19:00, Paul Koning wrote:
...
> Did you really mean that you have a Multinet header followed by a DDCMPheader? Or
did you just mean that you use the point to point datalink dependent routing sublayer,
passing it the Multinet payload or the DDCMP payload depending on which datalink is used?
That second option is what Iwould expect, and for Multinet over TCP will work tolerably
well -- atleast if you use disconnect and reconnect at the TCP layer to do the datalink
reinitialization that's a required point to point service the Multinet
"designers" didn't bother to implement.
The latter. Sorry.
But just to point out something else that should be somewhat obvious- multinet over TCP
is better than DDCMP over TCP. You don't need the DDCMP layer processing, since TCP is
already guaranteeing what DDCMP otherwise provides. So using DDCMP just adds extra
processing and bytes to transfer compared to Multinet, without any actual gain.
Mostly true, for DDCMP over TCP. DDCMP also runs very well over UDP,and typically set it
up that way.
8:55 p.m.
On Mar 3, 2026, at 11:42 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 03/03/2026 15.58, Paul Koning wrote:
Ah. I had the broken understanding that DDCMP also restarted at that point. Ok, so it
resyncs and gets back in order on its own? That's nice.
I haven't looked at DDCMP in years...
DDCMP is pretty simple, especially if you skip over the half duplex stuff and the
initialization handshake (though that will look familiar if you know NSP or TCP, which
adopted the 3-way handshake DDCMP introduced).
DDCMP is a lot like NSP or TCP: packets, sequence numbers, timeout & retransmit. One
small difference is that on timeout DDCMP doesn't just retransmit the packet; instead
it sends a REP message which essentially asks the other end to repeat its current ACK.
The idea is to avoid the overhead of sending a whole packet if the link is slow. For
links fast enough that the packet send time is small compared to the round trip latency,
that isn't interesting, but considering that DDCMP was designed when a medium speed
link was 1200 baud and 9600 was considered "high speed", it makes sense.
paul
On Mar 3,
2026, at 4:40 AM, Johnny Billquist <bqt(a)softjar.se> wrote:
...
DDCMP will notice and handle out of order packets, but it still means it have to restart
the circuit, so UDP in this case is still not a great idea. The better option would be to
use the same datalink mode/protocol as ethernet does, which is designed for the occasional
dropped packet or out of order packet.
Not true. DDCMP does not restart the link
on out of order packets. Instead, it drops the out of order packet, and then timeout of
the ACK willcause it to be retransmitted.
2 Mar
2 Mar
6:46 p.m.
On 3/2/2026 10:44 AM, Johnny Billquist wrote:
Hm. The command "MNC SET CIR IP-0-5 MODE
DDCMP" should have given a warning that this has been deprecated. In essence, it does
nothing.
All links are just multinet links, which is DDCMP, with a small header to just get whole
packets when using TCP.
Johnny
That explains the "MLTNET" in Marks error log. So, if I set up the phDECnet
circuit as a Multinet one is should work?
On 02/03/2026 17.38, Johnny Billquist wrote:
> I don't think I've ever tried that DDCMP mode. I don't even remember what
it does...
>
> Why are you wanting to use it?
>
> Johnny
>
Because that's what I was told needed to be done to connect to other HECnet nodes?
Mark has several set up that way and so does Supratim.
> On 02/03/2026 17.35, John H. Reinhardt wrote:
>> Greetings!
>>
>> Mentioning pyDECnet might be a red herring, but that's what I'musing
to connect to HECnet so I'm mentioning it. I'm trying to connect to Mark
Matlock's RSX11M.COM (Static IP:216.177.191.101) and we are getting some weird
errors.
>>
>> My pyDECnet circuit line looks like this - modeled after Supratim's
circuit config that he sent me last year.:
>>
>> circuit DDCMP-30-1 DDCMP tcp:60001:rsx11m.com:7728 --t3=15 --cost=9
>>
>>
>> On Mark's side he has an RSX11M host as the area router and the
connection for me is set up thusly:
>>
>> MNC SET CIR IP-0-5 MODE DDCMP
>> MNC SET CIR IP-0-5 TCP HOST 0.0.0.0:0 PORT 7728
>> NCP SET CIR IP-0-5 STA ON
>>
>> The connection isn't working. Mark is seeing errorslike this:
>>
>>
>> 02:53:40 MLTNET - IP-0-5 Incoming packet sizeerror (1541) from
>> 76.213.76.105:51354. Abort.
>> 02:53:42 MLTNET - IP-0-5 Incoming packet sizeerror (1541) from
>> 76.213.76.105:34404. Abort.
>> 02:53:44 MLTNET - IP-0-5 Incoming packet sizeerror (1541) from
>> 76.213.76.105:34412. Abort.
>>
>> The A17RTR node has what look to be the normal settings. the Segment buffer
size is normal for DDCMP.
>>
>> NCP>tell a17rtr show exe char
>>
>>
>> Node Volatile Characteristics as of 2-MAR-2026 09:35:20
>>
>> Executor node = 17.1023 (A17RTR)
>>
>> Identification = THEMIS2 - A17RTR - DECnet/Python Area-17
>> Router at Saginaw, TX (DFW)
>> Management version = V4.0.0
>> Software identification = DECnet/Python V1.1.0
>> Incoming timer = 30
>> Outgoing timer = 30
>> NSP version = V4.0.0
>> Maximum links = 4095
>> Delay factor = 32
>> Delay weight = 3
>> Inactivity timer =300
>> Retransmit factor = 5
>> Routing version = V2.0.0
>> Type = area
>> Maximum area = 63
>> Area maximum cost = 128
>> Area maximum hops = 16
>> Segment buffer size =576
>>
>>
>>
>> Does anyone know what causes the packet size to be bigger than normal? The
ethernet interface on the pyDECnet host is set to 1500MTU as is my firewall/router.
>>
>> Where else can I look? I don't see anything in the pyDECnet
documentation that talks about DDCMP packet size. Where else canI look?
>>
>> Regards,
>> John H. Reinhardt
6:47 p.m.
On 02/03/2026 18.46, John H. Reinhardt wrote:
On 3/2/2026 10:44 AM, Johnny Billquist wrote:
Yes.
Johnny
Hm. The command "MNC SET CIR IP-0-5 MODE
DDCMP" should have given a
warning that this has been deprecated. In essence, it does nothing.
All links are just multinet links, which is DDCMP, with a small header
to just get whole packets when using TCP.
Johnny
That explains the "MLTNET" in Marks error log. So, if I set up the
phDECnet circuit as a Multinet one is should work?
7:52 p.m.
I changed the pyDECnet config to use this:
#
# Circuit to Mark Matlock
#
#circuit DDCMP-30-1 DDCMP tcp:60001:rsx11m.com:7728 --t3=15 --cost=9
circuit MUL-30-1 Multinet --mode connect --remote-address rsx11m.com --remote-port 7728
--t3=15 --cost 20
Still not connecting. No error messages in the log file:
2026-03-02 12:45:48.732: MainThread: DECnet/Python shut down
2026-03-02 12:45:49.640: MainThread: Starting DECnet/Python V1.1.0
Python 3.10.12 (main, Jan 26 2026, 14:55:28) [GCC 11.4.0]
2026-03-02 12:45:49.641: MainThread: command line: /usr/local/bin/pydecnet --daemon
--log-file /var/log/decnet/pydecnet_themis2.log --keep 3 /etc/decnet/themis_pydecnet.conf
/etc/decnet/themis-pydecnet-http.conf
2026-03-02 12:45:52.854: A17RTR: Logging configuration reloaded
2026-03-02 12:45:52.854: A17RTR: Now running as daemon
2026-03-02 12:45:52.891: A17RTR: Event type 2.0, Local node state change
From node 17.1023 (A17RTR), occurred 02-Mar-2026 12:45:52.890
Reason = Operator command, Old state = Off, New state = On
2026-03-02 12:45:52.894: A17RTR: DECnet/Python is running
2026-03-02 12:46:03.988: A17RTR: Event type 4.15, Adjacency up
From node 17.1023 (A17RTR), occurred 02-Mar-2026 12:46:03.985
Circuit = ETH-0, Adjacent node = 17.266 (POHL)
2026-03-02 12:46:04.437: A17RTR: Event type 4.14, Node reachability change
From node 17.1023 (A17RTR), occurred 02-Mar-2026 12:46:04.436
Node = 17.266 (POHL), Status = Reachable
2026-03-02 12:46:05.106: A17RTR: Event type 4.15, Adjacency up
From node 17.1023 (A17RTR), occurred 02-Mar-2026 12:46:05.106
Circuit = ETH-0, Adjacent node = 17.263 (SCALZI)
2026-03-02 12:46:05.338: A17RTR: Event type 4.14, Node reachability change
From node 17.1023 (A17RTR), occurred 02-Mar-2026 12:46:05.337
Node = 17.263 (SCALZI), Status = Reachable
The monitor summary pages says:
Mark is out running errands. I'll have to wait until he gets back to see what the log
says on his side.
Thanks!
Regards,
John H. Reinhardt
On 3/2/2026 11:47 AM, Johnny Billquist wrote:
On 02/03/2026 18.46, John H. Reinhardt wrote:
On 3/2/2026 10:44 AM, Johnny Billquist wrote:
Yes.
Johnny Hm. The command "MNC SET CIR IP-0-5 MODE
DDCMP" should have given a warning that this has been deprecated. In essence, it does
nothing.
All links are just multinet links, which is DDCMP, with a small header to just get whole
packets when using TCP.
Johnny
That explains the "MLTNET" in Marks error log. So, if I set up the phDECnet
circuit as a Multinet one is should work? 
6:50 p.m.
On Mar 2, 2026, at 12:46 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
On 3/2/2026 10:44 AM, Johnny Billquist wrote:
PyDECnet is basically omnilingual. So you need to find out what line protocol the other
end uses and then configure PyDECnet to match. If the other side runs Multinet, you'd
configure that (making sure to set the directions correctly: one is originating, the other
incoming). And don't use Multinet over UDP unless nothing else is available, because
it is an utter crock.
I generallly suggest DDCMP because it works well, but lots of other options have been
used. Some of my preference comes from history; for example I tend not to use Ethernet
(or GRE, basicallly the same thing) for "wide area" use because it's a LAN
and back when it wouldn't work for WANs. Nowadays the Internet is so fast that
it's a reasonable option in many cases (though I would still hesitate to run it on a
trans-Atlantic circuit).
paul
Hm. The command "MNC SET CIR IP-0-5 MODE
DDCMP" should have given a warning that this has been deprecated. In essence, it does
nothing.
All links are just multinet links, which is DDCMP, with a small header to just get whole
packets when using TCP.
Johnny
That explains the "MLTNET" in Marks error log. So, if I set up the phDECnet
circuit as a Multinet one is should work?
On 02/03/2026 17.38, Johnny Billquist wrote:
> I don't think I've ever tried that DDCMP mode. I don't even remember what
it does...
>
> Why are you wanting to use it?
>
> Johnny
>
Because that's what I was told needed to be done to connect to other HECnet nodes?
Mark has several set up that way and so does Supratim.
6:57 p.m.
On 02/03/2026 18.50, Paul Koning wrote:
Agreed. Multinet and UDP is a bad match. It usually works, but it's far
from ideal. TCP makes much more sense.
And RSX only speaks Multinet. DDCMP without the Multinet headers are not
dealt with. I guess it would be possible to add, but then I'd have to
process and understand when one frame ends, so I can give it to DECnet
properly.
On Mar 2, 2026, at 12:46 PM, John H. Reinhardt
<johnhreinhardt(a)thereinhardts.org> wrote:
On 3/2/2026 10:44 AM, Johnny Billquist wrote:
PyDECnet is basically omnilingual. So you need to find out what line protocol the other
end uses and then configure PyDECnet to match. If theother side runs Multinet, you'd
configure that (making sure to set the directions correctly: one is originating, the other
incoming). And don't use Multinet over UDP unless nothing else is available, because
it is an utter crock. Hm. The command "MNC SET CIR IP-0-5 MODE
DDCMP" should have given a warning that this has been deprecated. In essence, it does
nothing.
All links are just multinet links, which is DDCMP, with a small header to just get whole
packets when using TCP.
Johnny
That explains the "MLTNET" in Marks error log. So, if I set up the phDECnet
circuit as a Multinet one is should work?
On 02/03/2026 17.38, Johnny Billquist wrote:
> I don't think I've ever tried that DDCMP mode. I don't even rememberwhat
it does...
>
> Why are you wanting to use it?
>
> Johnny
>
Because that's what I was told needed to be done to connect to other HECnet nodes?
Mark has several set up that way and so does Supratim. I generallly suggest DDCMP because it works well, but
lots of other options have been used. Some of my preference comes from history; for
example I tend not to use Ethernet (or GRE, basicallly the same thing) for "wide
area" use because it's a LAN and back when it wouldn't work for WANs.
Nowadays the Internet is so fast that it's a reasonable option in many cases (though I
would still hesitate to run it on a trans-Atlantic circuit).
It works to the other side of the world just fine. However, the problem
if you play ethernet is that you're doing my bridge, and that have
scaling issues, since on ethernet everyone is supposed to be able to
directly talk to everyone, but also multicasts should go everywhere.
Which becomes ugly if the ethernet is tunneled to many places but still
appears as one segment.
GRE can get into the same pickle. While individual GRE links are also
point-to-point, there is no stopping you from having multiple ones of
them...
Johnny
7:01 p.m.
On Mar 2, 2026, at 12:57 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
...
And RSX only speaks Multinet. DDCMP without the Multinet headers are not dealt with. I
guess it would be possible to add, but then I'd have to process and understand when
one frame ends, so I can give it to DECnet properly.
But that is trivial. If it's a control frame, it's just a header. If it's a
data (or maintenance) frame, it's header plus the data length given in the header,
plus 2 bytes for the data CRC.
paul
3 Mar
3 Mar
1:24 a.m.
On 2026-03-02 19:01, Paul Koning wrote:
Yeah. Could definitely be done. But I haven't done it for now. And I
really don't see much reason to do it. It's just extra overhead in bytes
and processing for no gain.
But if someone *really* wants it, I guess it could be done.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Mar 2, 2026, at 12:57 PM, Johnny Billquist
<bqt(a)softjar.se>wrote;wrote:
...
And RSX only speaks Multinet. DDCMP without the Multinet headers are not dealt with. I
guess it would be possible to add, but then I'd have to process and understand when
one frame ends, so I can give it to DECnet properly.
But that is trivial. If it's a control frame, it's just a header. If it's a
data (or maintenance) frame, it's header plus the data length given in the header,
plus 2 bytes for the data CRC.
2 Mar
2 Mar
7:10 p.m.
On 3/2/2026 11:50 AM, Paul Koning wrote:
This is what Mark configured on his RSX11M system. It's
duplicated several times for other incoming connections. I assume they work.
.;
.; Inbound Connection for John Reinhardt
.;
MNC SET CIR IP-0-5 MODE DDCMP
MNC SET CIR IP-0-5 TCP HOST 0.0.0.0:0 PORT 7728
NCP SET CIR IP-0-5 STA ON
MNC SHO ALL
And this is what I put in my pyDECnet config file:
#
# Circuit to Mark Matlock
#
circuit DDCMP-30-1 DDCMP tcp:60001:rsx11m.com:7728 --t3=15 --cost=9
This is based on the circuit documentation plus a config file I got from Supratim last
year which has quite a few DDCMP connections.
On Mar 2, 2026, at 12:46 PM, John H.
Reinhardt<johnhreinhardt(a)thereinhardts.org> wrote:
On 3/2/2026 10:44 AM, Johnny Billquist wrote:
PyDECnet is
basically omnilingual. So you need to find out what line protocol the other end uses and
then configure PyDECnet to match. If the other side runs Multinet, you'd configure
that (making sure to set the directions correctly: one is originating, the other
incoming). And don't use Multinet over UDP unless nothing else is available, because
it is an utter crock. Hm. The command "MNC SET CIR IP-0-5 MODE
DDCMP" should have given a warning that this has been deprecated. In essence, it does
nothing.
All links are just multinet links, which is DDCMP, with a small header to just get whole
packets when using TCP.
Johnny
That explains the "MLTNET" in Marks error log. So, if I set up the
phDECnet circuit as a Multinet one is should work?
On 02/03/2026 17.38, Johnny Billquist wrote:
> I don't think I've ever tried that DDCMP mode. I don't even remember what
it does...
>
> Why are you wanting to use it?
>
> Johnny
>
Because that's what I was told needed to be done to connect to other
HECnet nodes? Mark has several set up that way and so does Supratim. I generallly suggest DDCMP because it works well, but
lots of other options have been used. Some of my preference comes from history; for
example I tend not to use Ethernet (or GRE, basicallly the same thing) for "wide
area" use because it's a LAN and back when it wouldn't work for WANs.
Nowadays the Internet is so fast that it's a reasonable option in many cases (though I
would still hesitate to run it on a trans-Atlantic circuit).
paul
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
--
John H. Reinhardt
PRRT&HS #8909
C&O HS #11530
NRail (NTrak) #54979044 (7566)
4
days inactive
5
days old
19 comments
3 participants
participants (3)
-
John H. Reinhardt -
Johnny Billquist -
Paul Koning