HECnet

hecnet@lists.dfupdate.se

5 participants
15580 discussions

by Anders Andersson

My zpologies everyone for having youspendtime on what seems tohave been a totally self-inflicted problemonmypart. My earlier "moving around" invlvedtrying to findheapprpriatecommands to bring downthe bridge toits defaultstatein orderto performacleanrestart. Itturnsoutthat I failed to bringdown some tapinterfacesbefore deleing thebridge,which led to a defective bridge configuration being left running. Then I tried restarting pydecnet and that's when theproblems showed up. Thanks to Thomas, Johnny and David for putting me on the right track. Several of you askedfor how I configuredthe KLH10 networkinterfaces, and I remarked on that while hinting on my icompletetesting procedure.Ishould have taken down the bridgecompletely, andrestarted the KLH10 instances, which sould have resolved theproblem before asking the list: >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: Asto that question however, the network configuration looksasfollows: devdef ni0 564 ni20 dedic=true ifc=tap2 ifmeth=tap+bridge ipaddr=192.168.9.72 dpdelay=3 then I havea local file in SYSTEM with the node number usedby 7-CONFIG.CMD which I believe makes KLH10 setthe correctethernet addresson itsinerface. $TYPE (FILE) NODE.IND.1 RARITY 1.802 I haveyet to chck a fewthings before can say forsurethatthe issueis resolved, butthankyou fior yourquestions and feedback, itwasvery helpful. /AndersAndersson

1 year, 4 months

Re: pydecnet on LinuxMint

by Anders Andersson

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

1 year, 4 months

Re: pydecnet on LinuxMint

by Anders Andersson

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

1 year, 4 months

pydecnet on LinuxMint

by 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?

1 year, 4 months

IP Address change for A29RT2 (29.2) tomorrow (27th Feb) at 11:00 UTC

by Keith Halewood

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

1 year, 4 months

DECnet traceroute for RSX

by Johnny Billquist

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

1 year, 4 months

Reminder about nodename updates

by Johnny Billquist

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

1 year, 5 months

Some new nodes

by Keith Halewood

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

1 year, 5 months

PANDA II Current Status

by Thomas DeBellis

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.

1 year, 6 months

VMS Phone Protocol

by Thomas DeBellis

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?

1 year, 6 months

← Newer
1
...
4
5
6
7
8
9
10
...
1558
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet