Assuming Rob makes his patch to SIMH available, is there anyone on
HECnet willing to test peering with my RSTS/E setup?
On Wed, Jan 4, 2012 at 5:45 PM, Rob Jarratt <robert.jarratt at ntlworld.com> wrote:
Yes, you are right, I do add a 2-byte length to the start of each buffer
that I send so that the other end can reassemble the buffer. Sorry, I did
say this in an earlier draft of the email, but decided to leave it out to
emphasise the simplicity of the implementation.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 04 January 2012 22:15
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
I assume there has to be a bit more to it, because DDCMP is a packet based
protocol (not a stream protocol as TCP is) and the higher layers rely on
that.
So there presumably is some form of framing in the emulated data stream to
indicate where the packet boundaries are.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Rob Jarratt
Sent: Wednesday, January 04, 2012 5:11 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
All I do in SIMH is to take the data bytes each end wants to send to the
other
end and send them over a socket, so I don't get involved with DDCMP
itself.
Both ends have to be SIMH for this to work. I don't do anything at the
actual
hardware level, although that would be nice. I think you can get
synchronous
serial cards for the PC but they are quite expensive.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 03 January 2012 21:18
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
DMC-11 speaks DDCMP V3.1 (give or take some bugs in the "high speed"
version). But that's sync only. Depending on what you want to talk
to, a
DMC
(or its relatives DMR-11, DMP-11, or DMV-11) may not help; if the
other
end
speaks DDCMP over an async link (UART) then it won't work because the
character framing doesn't match.
That said, I wonder what it means to emulate a DMC-11. You could have
it speak DDCMP over a UART, or something else entirely. If the former
it
would
talk to another DDCMP node; if the latter it would not but it would
still
work
for tying one emulated DMC-11 to another.
If you want DDCMP, one approach is to get a copy of the spec, and
implement
what it says. That works; it is how I implemented DDCMP support for
RSTS
V10
(based on an earlier version based on V9.6). The protocol is quite
simple
and
the spec is well enough written that, if you do what it says, the
result
WILL
interoperate with hardware such as the DMR-11. The only tricky one is
the
DMC-11 because it has some undocumented bugs; the main one I
remember
is that the high speed version can't handle back to back packets. I
wish
I could
contribute the code I wrote but I can't, for various reasons one of
them
is that
it's a RSTS device driver and written in 100% assembly language.
It would not be hard to do a version for other platforms; I once
looked at
a
Linux terminal protocol handler (forgot what that is called) that
could
hook
into DECnet/Linux. Didn't get far enough on that, though.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Abene
Sent: Sunday, January 01, 2012 6:06 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Hecnet and DDCMP
Jarratt, did you make this publicly available on the SIMH list? It
would
be great
to have a DMC11 device emulated, since I insist on running RSTS/E v8
(for historical reasons... it was the last real RSTS before "the
pollution").
RSTS/E v8
doesn't have ethernet support, so the only way I could have DECnet is
via
a
(previously unemulated)
DMC11 interface. Does yours work well?
-Mark
On Sun, Jan 1, 2012 at 3:23 AM, Jarratt RMA
<robert.jarratt at ntlworld.com>
wrote:
Working with a friend, I have written a SIMH emulation of the DMC11
device, so you can do this with SIMH. It tunnels the bytes sent
to/from the device over a socket. We have used the SIMH emulation to
connect my friend to HECnet over a (simulated) DMC11.
The bit I am not entirely sure about is to what extent this is using
DDCMP as I don't have a full understanding of DDCMP.
Regards
Rob
On 31 December 2011 18:46, The Presence <tpresence at hotmail.com>
wrote:
Hey guys,
Has anyone worked out a mechanism to connect a node to hecnet using
DDCMP?
Perhaps some tunneling technology over IP, or virtualized serial?
Kevin
Mark,
Contact me offline. Maybe with a little bit of effort we can sort this out. I will be available early tomorrow or later in the afternoon. I am in the Eastern US (EST5EDT). If you have a skype account we can use that to sort through this.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Mark Benson
Sent: Thu 1/5/2012 18:50
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
On 5 Jan 2012, at 23:27, hvlems at zonnet.nl wrote:
More than one area router in a given area is never a problem because there is a mechanism that selects the active area router.
The copy problems are observed with Legato and Star69 (from memory).
There's a high likely hood something is misconfigured on STAR69 - I wouldn't honestly know if it was either unless someone pointed it out.
--
Mark Benson
http://DECtec.info <http://dectec.info/>
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
I noticed that as well...
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Johnny Billquist
Sent: Thu 1/5/2012 19:16
To: hecnet at Update.UU.SE
Subject: [HECnet] STAR69
STAR69 is in serious yo-yo mode as seen from MIM right now. Anyone know why?
Johnny
The HECNET INFO.TXT files is located in the default directory for the
FAL$SERVER account, which is referenced from other nodes using
<NODENAME>::INFO.TXT - for example SLAVE::INFO.TXT
[MSW]SLAVE$ type slave::info.txt
FWIW, this is not absolutely true if the nodes have proxy logins set up.
NODE:: actually means to use the proxy account; to force the default DECnet
account to be used, it's NODE""::
If you don't have proxy access set up, then the two do the same thing.
Bob
On 2012-01-06 00.27, hvlems at zonnet.nl wrote:
More than one area router in a given area is never a problem because there is a mechanism that selects the active area router.
No. There is not just one "active" area router. But if that was the case, then it could doubly become a problem. Assume the two area routers in an area do not have direct contact with each other. How would they decide which one was active?
But correct, having multiple area routers in an area is not a problem. Level 1 routers figure out which area router is the closest, and route all out-of-area traffic to the closest area router. However, if you have two area routers, but they do not have a direct contact with each other, things can become funny.
The copy problems are observed with Legato and Star69 (from memory).
Thanks. I'll try to look at it this weekend, if it hasn't been solved before then.
By the way, does any kind of traffic work, and only file copying is an issue, or what exactly have you observed?
Johnny
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 06 Jan 2012 00:21:17
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet circuit costs
I would expect that your area should not ever be a problem. But if you
have two area routers for your area, you can potentially mess things up
for traffic going out of your area, or in to.
Well, there are other potential messups one can do as well. But could
you start by telling me between which machines you can observe the problem?
Johnny
On 2012-01-06 00.15, hvlems at zonnet.nl wrote:
Yes I agree that we have a problem. I cannot create the problem between any combination of nodes within my area. The only common factor is that both nodes I cannnot copy from all have a bridge and a tcp tunnel.
I haven't tried Ctakan yet. It's too late now.
Hans
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 06 Jan 2012 00:04:01
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet circuit costs
Ok. So we do have a problem. Time to figure out what it is, then. I can
most definitely say that multiple paths is not the problem. However,
there could be some other problem with some machine/setup/paths/whatever
that is more local to you Hans.
If it works talking to MIM, and you have the bridge running, then it
becomes a question of which machines you have problems talking to, and
we can check at both ends what the next hop is and reason if that is
reasonable and correct.
Johnny
On 2012-01-05 16.40, hvlems at zonnet.nl wrote:
Again, apologies for topposting: my cellphone is somewhat rude...
PST is UTC-8 (unless Bob lives in the Philippines, then it's UTC+8 :).
Yes I have problems wihile copying files from Legato and Star69 to Ozon.
Ozon is the area router for area 44 and uses the bridge software.
I can't access the Hecnet map but Legato has multiple paths and IIRC so does Star.
Ozon has no problem copying files from MIM or MUSIPC and both are connected with single paths (IIRC again).
Reading Bob's analysis I still think that multiple paths may lead to errors. Granted that circuit cost may fix this but right now it is, for me at least, not clear.
The area information in the output of show network/old on Ozon shows all areas and about 40% is more than 1 hop away and seen as reachable thru Legato.
Hans
-----Original Message-----
From: "Bob Armstrong"<bob at jfcl.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 5 Jan 2012 07:14:50
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] Multinet circuit costs
Why? What is the percieved problem?
I don't know about area 44, but I was talking to Hans on New Years Eve
about a problem where he could not copy files, while logged in to OZON, from
LEGATO (i.e. a "pull" transaction). According to Hans, it fails with "acp
file or directory lookup failed". If I did the same thing from my end (a
"push") it would start copying and actually create an empty file on OZON,
but then time out after a very long time with
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKABORT, network partner aborted logical link
Last I heard Hans was going to check the NETSERVER/FAL logs on his side for
any error messages, but that was New Years Eve and he was otherwise occupied
:-)
I see this morning that Hans has actually created a file "TARGET.TXT" on
LEGATO (dated 6PM PST on 12/31 even - what time is that in the
Netherlands??) so maybe he's solved the problem. If he did he didn't tell
me what he did.
Hans also mentioned to me that he was having similar problems with the
node STAR69 and CANADA. I think all this came up when Hans was trying to
write his HECnet crawler script to gather INFO.TXT files...
I don't think this is related to the Multinet/Bridge configuration, but I
can't guarantee it. One hidden "gotcha" in DECnet is that the circuit costs
are determined locally, so the routings don't have to be symmetrical (i.e.
the route from A->B might not be the same as the route from B->A).
If somebody (Johnny??) wants to try to figure it out, be my guest -
GUEST/GUEST. I'm a little busy at the moment and don't really have time to
look at it.
Bob
Mark,
If you would create a non-priv account I can log into I can take a look around.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Mark Benson
Sent: Thu 1/5/2012 18:50
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
On 5 Jan 2012, at 23:27, hvlems at zonnet.nl wrote:
More than one area router in a given area is never a problem because there is a mechanism that selects the active area router.
The copy problems are observed with Legato and Star69 (from memory).
There's a high likely hood something is misconfigured on STAR69 - I wouldn't honestly know if it was either unless someone pointed it out.
--
Mark Benson
http://DECtec.info <http://dectec.info/>
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 2012-01-06 00.26, Steve Davidson wrote:
They are valid, but not necessarily preferred. Only the site owners can determine that.
True. But if you prefer one over the other, you should not set the cost equal on your interfaces. If you really only want to use one if the other is broken, make it *very* expensive.
Johnny
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Johnny Billquist
Sent: Thu 1/5/2012 18:06
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
No. Equal cost paths are valid. DECnet will do one of two things. Either
pick one on random (well, there is some algorithm to it, but it don't
matter, it will pick one anyway), or if the DECnet is slightly more
modern than plain phase IV (it was called phase IV+ if I remember
right), then DECnet will do equal path cost splitting. That is, it will
use both paths.
Johnny
On 2012-01-05 16.58, Steve Davidson wrote:
The circuit costs here are set to 4 for LAN and 3 for tunnels. The issue may be that if a node (at the end of the chain so to speak) has 2 tunnel links of the same cost and that the final destination costs the same I could see where DECnet *might* get confused. Let's look at the following contrived example:
FRUGAL:: connects to LEGATO:: - cost of 3
FRUGAL:: connects to SG1:: - cost of 3
LEGATO:: connects to GORVAX:: - cost of 3
SG1:: connects to GORVAX:: - cost of 3
Fred, on node FRUGAL:: tries to copy a (large) file from GORVAX:: to FRUGAL:: *may* see some issues. On the other hand if Fred chooses to favor SG1:: over LEGATO:: (cost wise) he should not see any problems: Ex:
FRUGAL:: connects to LEGATO:: - cost of 3
FRUGAL:: connects to SG1:: - cost of 2
The route is guaranteed to be the same for the entire transaction. It will be (using poor man's routing to demonstrate) FRUGAL::SG1::GORVAX:: at a cost of 5, not FRUGAL::LEGATO::GORVAX:: at a cost of 6.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of hvlems at zonnet.nl
Sent: Thu 1/5/2012 10:43
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
PS
I can copy to Legato alright.
PPS
I did check the netserver.log files and found nothing out of the order.
On 5 Jan 2012, at 23:27, hvlems at zonnet.nl wrote:
More than one area router in a given area is never a problem because there is a mechanism that selects the active area router.
The copy problems are observed with Legato and Star69 (from memory).
There's a high likely hood something is misconfigured on STAR69 - I wouldn't honestly know if it was either unless someone pointed it out.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 5 Jan 2012, at 15:58, Steve Davidson wrote:
It could be the issue. If you are running Phase-IV then NETCONFIG will allow you to create the necessary account(s).
I setup a default DECNET and FAL$SERVER account on STAR69 if you want to retry the exercise...
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
Ah Johnny and you know the same applies to me as well :-)
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 06 Jan 2012 00:25:20
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Router for area 1
Hmm. I'm pretty sure that the routing priority is used to select which
router to use as the area router as well. But I should recheck
documentation.
I might be misremembering things (which aren't that unusual), and it's
been several years since I last looked at this.
Johnny
On 2012-01-06 00.17, hvlems at zonnet.nl wrote:
Routing priority doesn't affect the selection of the active area router if more than one exists in an area. The only arbitration is node address : highest address wins.
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 06 Jan 2012 00:11:54
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Router for area 1
On 2012-01-05 17.21, Bob Armstrong wrote:
I wrote-
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
....
It bugs me, although I can't point at an actual problem that it causes,
that the routing node for area 1 is seen as CTAKAH, rather than MIM. Since
CTAKAH is not actually local to Uppsula (I think that's where MIM is) but is
rather at the other end of yet another bridge, this means that any traffic
for area one, no matter what its ultimate destination, has to make an extra
round trip to Russia.
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Nah. MIM have a higher routing priority set. (Unless Oleg Safiulling
have tweaked the routing priority of CTAKAH.) However, you sometimes run
into this issue because there are so many routers on the bridge.
Depending on your configuration, some routers will be ignored, and which
ones seems to be somewhat random. So unfortunately, it can be MIM that
gets tossed, and then it don't matter that MIM have a higher priority.
But yes, CTAKAH do sit in Russia, and it causes packets to travel some
extra time to get to places. But apart from that, it should not ever be
an issue. A slight side effect of the fact that we fake a local ethernet
segment. Had it been a real one, the packets would travel the same on
the local segment, no matter which router was used.
Johnny
