Thank you foryourfeedback Yes,the KLH10istancesall run on thsame Linux Mint
host that runs the apydecanet router calledKSKAL,and I haveno additioal
hardware on that internal segment which lookslike this now:
oot@kaskal:/home/andersa# brctl show
bridge name bridge id STP enabled interfaces
bridge0 8000.26d039e4c0f4 no tap1
tap2
tap3
If that doesn't indicate that thethreetap interfaceshavbeen addedto
the bridge,I don't know what does. Are there any other diagnostics you
want me to check? I dont know whether the following add anything relevant:
root@kaskal:/home/andersa# ifconfig bridge0
bridge0: flags=4163 mtu 1500
inet 192.168.9.78 netmask 255.255.255.0 broadcast 192.168.9.255
inet6 fe80::4cf6:1fff:fe01:f257 prefixlen 64 scopeid 0x20
ether 26:d0:39:e4:c0:f4 txqueuelen 1000 (Ethernet)
RX packets 557072 bytes 143985475 (143.9 MB)
RX errors 0 dropped 450854 overruns 0 frame 0
TX packets 106193 bytes 4586565 (4.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions
0
root@kaskal:/home/andersa# ifconfig tap1
tap1: flags=4163 mtu 1500
inet6 fe80::6032:eff:fedb:7b94 prefixlen 64 scopeid 0x20
ether 62:32:0e:db:7b:94 txqueuelen 1000 (Ethernet)
RX packets 176227 bytes 46414104 (46.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 318825 bytes 90356527 (90.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@kaskal:/home/andersa# ip tuntap show
tap0: tap persist
tap1: tap
tap2: tap
tap3: tap
The threeTOPS-20 hosts arealso awareof and can communicate with each
other. When I run tcpdump -i bridge0 I do see DECnet, DEC LAT and TCP/IP
ARP traffic to or from the three TOPS-20 hosts pass by,according to the
ethertype code as well as decoding done by tcpdump.
The KLH10 instances obtain their tap interfaces as part of their
startup configuration, so I have to restart them whenever I have reset
the bridge which I haven't done in a few days now. This is a sample net
device onfiguration line from one host:
devdef ni0 564 ni20
dedic=true ifc=tap2 ifmeth=tap+bridge
ipaddr=192.168.9.72
dpdelay=3
The number of the interface specified with ifc= doesn't seem to matter the
machine
still gets assigned the next unassiged tap interface in order.And it did
work previously.
Eventually I hope to put all the bridge and pydecnet configuration into a
hecnet.service file andstart it from systemd.
Now I plan to restartpydecnet while logging bridg0 traffic using tcpdmpto
see
what comes up.
/AndersAndersson
YES! The Maneframe-Six data centre is back in operation! thanks for all
your support! And we giotome extrainfo on DECnet via CI which wasn't
plannd.thanks to serendipity!.
/Anders Andersson
pydecnet Q.Q.648Uusedto workfor me in the past,and I HAD three instances of
KLH10 running TOPS-20, talking to each and other HECnet nodes with no
visible problem.
I have sincemovedafewthings around and I'mno longerabletoget the old
configuratinstowork.
"Moved around" essentially means updating theufw firewall settings and
adjusted afew system settings such asthe SSH service parameers. When I
moved thestart script forpydecnetI hadto createasymbolic link to keep
thedecnet/applications/mirror.py script accessible (I uncommentedit in
thehopeof gaining some extradiagnostisthat way. But no, my routerKASKAL
is nolonger visible to my KLH10 hosts.
This is the kaskal.conf file(wheremost lines are ommwns):
# Configuration file
circuit tap-0 Ethernet tap:tap0 --console Plugh --random-address
#circuit tap-1 Ethernet pcap:tap0 --console Plugh --random-address
#circuit eth-1 Ethernet pcap:en1
#circuit bridged-1 Ethernet udp:7101:127.0.0.1:7001 --random
#circuit mul-0 Multinet localhost:7000
--latency 47
#circuit mul-1 Multinet localhost:700:connect
#circuit dmc-0 Multinet --mode=connect
--remote-address=hecnet-1-1023.stupi.net --remote-port=7700 --cost=3
circuit dmc-0 Multinet --mode=connect
--remote-address=hecnet-1-1023.stupi.net --remote-port=7704 --cost=3
#circuit dmc-0 DDCMP tcp:12345:localhost:32154 --cost 3
#circuit dmc-1 DDCMP udp:12345:localhost:32154 --cost 3
#circuit dmc-2 DDCMP serial:/dev/tty.usbserial-FTVSKM26:19200 --t3 120
--qmax 2
#circuit gre-0 GRE localhost
circuit dmc-1 Multinet --mode=listen -4 --local-port=7700 --cost=2
routing 1.808 --type l2router
node 1.808 KASKAL
node @flogsta.dat
node @nodenames.dat
system --ident "Flogsta HECnet router"
# This replaces the default built-in mirror object which is
# implemented as a Python module within PyDECnet by a functionally
# equivalent one that runs as a subprocess.
object --number 25 --name MIRROR --file decnet/applications/mirror.py
### end of kaskal.conf ###
Aftersetting up the virtual network
segment usng theseincantations
brctl addbr bridge0
ifconfig bridge0 192.168.9.78 up
ip tuntap add dev tap0 mode tap
ifconfig tap0 up
brctl addif bridge0 tap0
andstarting the KLH10 instances (if they weren't already running)
the following line is run under sudo:
pydecnet -d --uid decnet --gid 137 -e DEBUG -L logs/decnet.log kaskal.conf
http.
conf
This sems to be a relevant portion of thelogfile:
2022-08-25 14:25:13.770: MainThread: command line: /usr/local/bin/pydecnet
-d -
-uid decnet --gid 137 -L logs/decnet.log kaskal.conf http.conf
2022-08-25 14:25:15.446: KASKAL: Logging configuration reloaded
2022-08-25 14:25:15.446: KASKAL: Now running as daemon
2022-08-25 14:25:15.446: KASKAL: Running in as uid 129, gid 137
2022-08-25 14:25:15.447: KASKAL: Error starting datalink TAP-0
Traceback (most recent call last):
File
"/usr/local/lib/python3.8/dist-packages/decnet-1.0.596-py3.8.egg/decnet/d
atalink.py", line 73, in start
c.open ()
File
"/usr/local/lib/python3.8/dist-packages/decnet-1.0.596-py3.8.egg/decnet/e
thernet.py", line 220, in open
ioctl (fd, TUNSETIFF, ifr)
PermissionError: [Errno 1] Operation not permitted
2022-08-25 15:11:26.565: MainThread: Starting DECnet/Python DECnet/Python
V1.0-5
96
2022-08-25 15:11:26.565: MainThread: command line: /usr/local/bin/pydecnet
-d -
-uid decnet --gid 137 -L logs/decnet.log kaskal.conf http.conf
2022-08-25 15:11:28.185: KASKAL: Logging configuration reloaded
2022-08-25 15:11:28.185: KASKAL: Now running as daemon
2022-08-25 15:11:28.185: KASKAL: Running in as uid 129, gid 137
Myguess is that ioctl UNSETIFF on theethernetinterfacerquirsroottosucceed,
but
effctive UID is nowprobably 129 (my DECnet pseudou-user. Anychanceof
setting
the interface parameters beforetransfering control to UID 129)? I
haven'tlooked
hrough thecodeto findout.
Removing the --uid decnet option however lets pydecnet run as root,and now
the
error diagnstics re gonefromthelog file,but still I
can'treach KSKAL or any
other HECnetnode frommy local machines:
OPR>ENTER (command subset) NCP
NCP>LOOP NODE KASKAL::
NCP>
20:05:32 NCP
Request # 92 Accepted
20:05:32 NCP
Request # 92; Loop Node Failed, Mirror connect failed
Remote Node = 1.808 (KASKAL)
Unlooped count = 25701
NCP>EX
$I DEC
Local DECNET node: RARITY. Nodes reachable: 3.
Accessible DECNET nodes are: FLUSHY RARITY RBDASH
$
$INFORMATION (ABOUT) DECNET MIM::
%Node MIM is unreachable
$
So, now Ihavetwo problems. My pydecnet runs as root, which shouldn't be too
muchof an issue untilIstart experimentingwithcustom DECnetserver scripts on
the outer and more importantly,my configuraton is still dysfunctional,as I
have no connectivity to or via the router.
i intendthe HTTP server to beavailableat http://kaskal.pdcs.org:8036/
though
I'mnot sure my setupisstable enough for it to work allthetime,Ihavea ZTE
broadband routerreporting its IP address to dyndns.One of the KLH10 hosts
should bereachable via "ssh
rarity(a)kaskal.pdcs.org" (without apassord) to a
non-logged-in EXEC where atleast theINFORMATION (ABOUT) DECNET command is
availabe, in case anyonewants to see itscurrent status.
I can aaccess it locally however,and NSP Characteristics lists maybe a
thousand
nodes in a table.
So,theremaining issuewill likely require me to dig a little deeper in the
pydecnet debugging options, any particular feature I could investigate?
Currently, most recent portion of the log file:
2024-05-15 20:13:34.779: KASKAL: Starting node KASKAL
2024-05-15 20:13:34.779: KASKAL: Starting timer subsystem
2024-05-15 20:13:34.779: KASKAL: Starting datalink layer
2024-05-15 20:13:34.779: KASKAL: Ethernet TAP-0 hardware address is
86-fa-6f-77-4b-56
2024-05-15 20:13:34.780: KASKAL: Started datalink TAP-0
2024-05-15 20:13:34.780: KASKAL: Started datalink DMC-0
2024-05-15 20:13:34.780: KASKAL: Started datalink DMC-1
2024-05-15 20:13:34.780: KASKAL: Starting MOP layer
2024-05-15 20:13:34.780: KASKAL: Starting mop for
_TapEth TAP-0
2024-05-15 20:13:34.781: KASKAL: Initialized loop handler for TAP-0
2024-05-15 20:13:34.781: KASKAL: Initialized sysid handler for TAP-0
2024-05-15 20:13:34.781: KASKAL: Started MOP circuit TAP-0
2024-05-15 20:13:34.781: KASKAL: Starting Routing layer
2024-05-15 20:13:34.781: KASKAL: Started Routing circuit TAP-0
2024-05-15 20:13:34.781: KASKAL: Started Routing circuit DMC-0
2024-05-15 20:13:34.782: KASKAL: Started Routing circuit DMC-1
2024-05-15 20:13:34.785: KASKAL: Starting NSP
2024-05-15 20:13:34.785: KASKAL: Starting Session Control
2024-05-15 20:13:34.786: https: Starting https server on port 8443
2024-05-15 20:13:34.787: KASKAL: Starting http server on port 8000
2024-05-15 20:13:35.245: KASKAL: L2 attached state changed to True
2024-05-15 20:13:44.820: KASKAL: Designated router on TAP-0 will be self, 5
second delay
2024-05-15 20:13:49.833: KASKAL: Designated router on TAP-0 is self
Yetwhen I try to talk to KASKAL viathat very virtualetenet it hasTAP-0
on:
NCP>
10:01:59 NCP
Request # 93 Accepted
10:01:59 NCP
Request # 93; Loop Node Failed, Mirror connect failed
Remote Node = 1.808 (KASKAL)
Unlooped count = 25701
NCP>
Should I use some other server than mirror.py?
Hi,
There will be an IP address change for inbound/outbound DMC, Multinet, GRE and GRETAP connections to A29RT2 (29.2) tomorrow (27th Feb) at around 11:00 UTC.
82.70.71.174 will change to 77.104.155.22
There will be no change to the IPv6 prefix... apparently.
Please update your routers accordingly... and keep the previous config around, just in case. What could possibly go wrong?
Regards
Keith
I just wanted to let people know that I've just created a traceroute for
RSX. Available also as an RPM.
It can trace the route from yourself to somewhere, but also do tracing
from one arbitrary node to another. So you can explore the different
paths in both directions.
Example:
.trd frodo
Trace DECnet route
Tracing from 1.21 (JOCKE) to 30.1 (FRODO)
1: Tot: 0 1.21 (JOCKE)
2: Cost: 5 Tot: 5 1.13 (MIM)
3: Cost: 3 Tot: 8 1.1023 (ANKE)
4: Cost: 10 Tot: 18 30.15 (CBVRP3)
5: Cost: 3 Tot: 21 30.1 (FRODO)
Hops: 5 Total cost: 21
.trd frodo pondus
Trace DECnet route
Tracing from 30.1 (FRODO) to 1.15 (PONDUS)
1: Tot: 0 30.1 (FRODO)
2: Cost: 3 Tot: 3 30.15 (CBVRP3)
3: Cost: 6 Tot: 9 1.1023 (ANKE)
4: Cost: 3 Tot: 12 1.13 (MIM)
5: Cost: 5 Tot: 17 1.15 (PONDUS)
Hops: 5 Total cost: 17
.
A couple of comments:
1. This all works by talking to the NICE server for each node along the
path.
2. If a hop does not have a NICE server, it will not be possible to
query beyond that point. This typically happens if there is a CISCO
router in the path.
3. Your local node needs to have a nodename of all nodes along the path,
or else the program cannot connect to the NICE server of that hop.
4. If NICE do not give a next hop for a node, the program tries to
instead query about the destination area. If that also fails, then the
tracing fails. This happens with with older versions of PyDECnet.
So in order to make some diagnosing of things on HECnet a bit easier,
please update your PyDECnet routers to a somewhat recent version everybody.
Suggestions on improvements, as well as bug resports are most welcome.
The code is written in C, and isn't that large. At the moment is's a bit
hacky, but I might eventually clean it up some. But it means if someone
wants to port this, it's not completely impossible to do so.
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
Hi. I thought I'd just refresh people about how to update nodenames on
their machines with the latest information in the most simple way for
different OSes.
The basic information can be read at http://mim.stupi.net/hecdb.htm.
Note that there are specific files in the appropriate form already
prepared for most any OS, so you do not need to grab
MIM::HECNET:NODENAMES.DAT and do a bunch of parsing and processing
yourself. Doing that is just making something simple more complicated on
your side.
If you have need for other formats of the data, or spot something that
could be made smarter/better, just let me know and we can work together
to get whatever is needed.
The different files mentioned in http://mim.stupi.net/hecdb.htm are all
automatically generated whenever any change to the nodename database are
done. The actual database is in Datatrieve-11, and then I have a
makefile under RSX to generate all the different files. Doing changes to
the content of a file, or adding new files with other content/formats
are very easy for me.
Also, the mailing out to people with a notice when the database change
are also automated, and if anyone wants to be notified when the database
change, just let me know.
However, at this time, there are some issues with delivering mails to
users of gmail. Google is not accepting mails from Mim, because SPF and
DKIM is not setup for Mim. I should ping Peter about this, but until
that is resolved, be aware that mails from Mim to gmail might not get
though.
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
Hi Johnny et al.
Some new nodes to be added to the HECnet registry please.
BUZZEL 29.113
CORRIN 29.114
Both are VMS 9.2.2 x86-64 running under Debian Qemu/kvm. They are clustered together via shared virtual SCSI discs. Seem to be working quite well.
Terrible timing however, what with the bombshell VSI just dropped about the community licences. I'm tempted to become an Ambassador - I may have something to contribute in the VMS runtime department, along with LLVM. Ah well.
Regards
Keith
I discovered a pernicious boot race condition in FAL. Early in system
start up, only the boot structure (which may not be the login
structure), is recognized by Tops-20. MOUNTR has to start and identify
those other structures which should be made available and their
settings, which it does by looking at where they are persisted in
SYSTEM:DEVICE-STATUS.BIN file. Until MOUNTR has completed structure
identification, any RCDIR% might fail for a non-boot structure. This is
exactly what happens for FAL, which is running asynchronously and
sometimes crashed during start up.
One quick and dirty hack was to simply wait to start FAL, which I did,
but that has its own problems which I won't detail here. I tried some
other hacks, such as doing the mount from the EXEC, which had other
different drawbacks.
The real thing to do is to issue a mount request for the structure from
FAL itself and--once Galaxy is up and running--is processed, will make
RCDIR% safe to do (or safer, anyway). At any rate, there should be no
timing issue in this case. As Columbia's Galaxy programmer in the
1980's and having done some minor work in LCG's Galaxy group in the late
1970's, I actually knew how to do such a request and did so, having
written some sub-routines to issue queue requests for our ID system in
the 1980's.
So, I decided to fix FAL to 'do the right thing' and wound up down
another rabbit hole. I should emphasize "/knew/ how to do", as doing
that kind of Galaxy IPCF request is kind of hairy, particularly if you
haven't done it in four decades. After I looked at it for a while, I
grew despaired at having to relearn it again.
Incredibly, DEC defined a new JSYS called QUEUE% which seemed to do the
trick. Briefly, it performs certain Galaxy requests on behalf of the
user, converting it's simpler calling format to an internal Galaxy
format, getting a PID, and returning the response. QUEUE% does a lot of
cool things, including mount requests. Or at least it's documented to...
Besides having its own bugs, there is no code in Galaxy handle a mount
request from QUEUE%... The simpler format that QUEUE% is using is
actually something that Quasar internally calls a 'short' queue request,
which I had known about back in the day. What happens is that the
QSRQUE module converts it into the regular ('long') format and away you
go. This works fine for printing, plotting, punching, and other kinds
of spooling requests, including batch jobs.
There is no short format for mounting, QSRQUE has no code for this
because mount requests are dispatched to MOUNTR... Nothing is persisted
in the failsoft file. So I wrote a conversion routine to do exactly
that before the request makes it to QSRMDA and thence to MOUNTR.
Naturally doing all that resulted in a hailstorm of other issues as I
pushed things a little farther than they had been designed for.
It happens. I'm working through everything, bit by bit.
Tops-20 has a version of the VMS PHONE protocol that I look at from time
to time.
Is there a published specification for this anywhere? I'd like to maybe
do some work on the Tops-20 code, but I'd prefer not to reverse engineer
what I don't have to.
Besides VMS and Tops-20, what other systems speak PHONE?
I finally got my issues with Comcast straightened out and I now have static IP addresses. They are
IPv4: 50.185.8.122
IPv6: 2603:300b:6c4:21a0:c77b:4f58:27e4:6de2
These are also always available in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>
Hopefully, this will be the last change for a while.
Mark Berryman
Area 27
