HECnet

hecnet@lists.dfupdate.se

6 participants
15552 discussions

Automatic Orderly Shutdown of Emulated VAX/VMS System in SIMH

by nf6x＠nf6x.net

I'm not sure if the HECnet list is the best place to ask this, but hopefully it's not too far off topic. Let's say that I want to run a full-time SIMH emulation of a VAX running VMS (because I do). This would be my full-time DECnet presence on my local network, my primary means of moving things between my DECnet-speaking computers and my modern machines, and my full-time HECnet presence if I ever find a good way to have persistent internet access at my rural home. The SIMH emulation would be hosted on a Linux server. It's easy enough to set up the host server to automatically launch a SIMH emulation at boot time, but I don't know yet how to deal with automatically and cleanly shutting down the emulation when the host server needs to shut down. In particular, I'd want to somehow trigger an orderly VMS shutdown when the host server needs to perform an unattended shutdown, such as when the UPS signals a power failure. If there's a way to checkpoint the entire emulation and then restore it later, that might also be a good option, as long as I can prevent corrupting the emulated system's filesystems by suddenly yanking the virtual power plug. Is there any prior art for setting up an unattended SIMH-based VAX/VMS emulation like this? -- Mark J. Blair <nf6x at nf6x.net> http://www.nf6x.net/

6 years, 5 months

RVDSXL

by rok.vidmar＠gmail.com

Can somebory try to login via Hecnet to RVDSXL (3.47) please and report the result? There is no GUEST account on it, as far as I know. The machine is responding to ping, but telnet and SSH time out. -- Regards, Rok

6 years, 5 months

help finding DECUS stuff

by mcguire＠neurotica.com

Hi folks. I've found something that I'm looking for listed in the SIGTAPES.SUM file in the rsx freeware CD v2, but I can't find the actual software anywhere. It's from the European 1984 RSX SIG Tape, Amsterdam. Maybe I'm being dense but I can't find that stuff anywhere. The specific software I'm looking for is called CCDRV; if you search for that in SIGTAPES.SUM it's listed there. Can anyone help? Thanks, -Dave -- Dave McGuire, AK4HZ New Kensington, PA

6 years, 5 months

Announcing TCP/IP for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. I usually try to avoid spamming lists with release announcements, and the previous announcement was only a month ago, so I apologize in advance for the noise. However, I have a really good reason for this announcement. In the last few days I identified a bug within RSX, that has been latent for many years, but which gets activated when TCP/IP is installed. Because of this, I've cut a new distribution of BQTCP, which now also includes some patches to RSX, which I really implore everyone to install. Highlights: - Stability and reliability improvements in RSX. - Improved stability of Multinet. - Improved stability of MAILD. Detailed information on things that have been done since the last release: RSX: - The MCR REMOVE command have an interaction with the IP: device driver, which have a bug. Traditionally, the IP: device driver was for the IP11 device, which I doubt anyone have used in many years, so this bug have probably been around a long time without detection. The result of it is that low core and pool will get corrupted when giving the REMOVE command, and IP: exists. BQTCP now includes an optional "patch RSX" section in IPGEN, which will install a new version of MCR on the system. This is only needed to be run once, as the patching is installing new tasks, and changing the bootable image to use these new tasks, which is a more permanent change. Along with the fix for the memory corruption issues, the new version of MCR will also fix a few other issues that people might or might not have noticed. There is some more details in the BQTCP documentation. Multinet: - Some transmit errors should restart the link, but this was not done. Fixed now. MAILD: - Added paging to mail reader. - Improved remote node system type detection for DECnet. - Improved the memory layout of MAILD, to avoid some crash situation. As usual, the distribution is available from: ftp://mim.update.uu.se/bqtcp.dsk ftp://mim.update.uu.se/bqtcp.tap ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk The documentation is also available through ftp on Mim, or also at http://mim.update.uu.se/tcpipdoc The firewall for Mim have now been removed, so no need for the alternate ports, but Mim is still listening to the alternate ports as well. ftp: 10021 telnet: 10023 Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 6 months

Multinet IPv6 DNS lookup Induced Delay

by dwe-6006＠philtest.org

I have seen this elsewhere but I see no reference to a fix to the problem on Multinet. I have a Multinet SSHD agent running and when I attempt to do a connection the connection does succeed but it can take 90 seconds. I put a Sniffer on the line and the SSHD agent is attempting to do reverse DNS lookup on the incoming address. This is normal, but it is doing 6 IPv6 resolution attempts (3 to each of the 2 DNS servers) before it makes the first IPv4 request. I do not have IPv6 configured on the interface (or any interface) and I need to find a way to suppress all IPv6 DNS queries( PTR or AAAA) is here a magic incantation or a logical name that makes this happen? Dave

6 years, 6 months

Connections?

by bqt＠softjar.se

Guys. I figure I should try to get a more formalized handling of connections to HECnet. With my bridge, it's mostly just people connecting to me, but this is not a solution that scales very well, so in general I now try to discourage people from this option. When possible, I prefer to move people away from it. Multinet on the other hand scales well. And is possible to use directly both in VMS and RSX. However, it is silly and inefficient if all multinet links are to go to me. So I'm thinking about identifying a few people/places elsewhere in the world, which can be used for connections where it makes more sense for a somewhat closer point of connection. So, I would go on dealing with Europe. Might at some point be that we'd like a second point in the south of Europe, but that is not a high priority right now. However, for the US, it would be nice if we could identify a location on each coast, which have a capable system, and normally is always online, and which have a good bandwidth, and would be willing to setup connections to new machines that want to come online. So, are there any takers? I'll continue to be the first point of contact when people come asking, but I'd be happy if I could redirect them to the appropriate person once we have figured out a few basic details. And then these two persons can work on establishing the actual link. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 6 months

Ready to test | Re: Connections?

by supratim＠riseup.net

On 5/4/18 6:16 PM, Johnny Billquist wrote >>> I have a candidate... ;-) >>> >>> ? Johnny Johnny - can we ask this person to try a Multinet connection to 45.62.248.66 port 60001 and see if HECnet can be reached? If running OpenVMS, MULTINET:DECNET-CIRCUITS.COM should contain (needs editing by hand after MULTINET CONFIGURE /DECNET creates the skeleton without /TCP): $ multinet set /decnet /remote=45.62.248.66 /port=60001 /device=tcpa0: /connect /tcp=connect /buffers=24 I tested it successfully. Others can be added too (on different port numbers to be assigned). Thanks, Supratim -- Sent via Thunderbird/macOS High Sierra on Lenovo Legion Y720/Windows 10/VirtualBox

6 years, 6 months

Connections?

by bygg＠cafax.se

The other Johnny wrote: > Just realized I should maybe make another comment here. > I don't fully know how Multinet under VMS is managed, or what > limitations there might be. > My Multinet compatible implementation under RSX might have some issues > communicating with VMS nodes, but in general it seems to be working just > fine. > The setup under RSX do not really have any problems with dynamic IP > addresses. But it does introduce a bit of exposure, since when the other > end has a dynamic address, Multinet will have to be able to accept > connections from anywhere. I have been pondering whether to enable > passwords on those links. But until now, it's not been a real problem, > since people scanning and probing ports have no clue about DECnet over > IP to start with. Shameless plug or something here: I have a program called anftunnel which as the name suggests initially was used to handle ANF-10 packets. It has grown a bit from that, and can do other things as well now. Amongst what it can do is: * Set up a tunnel between two machines, with optional crypto and auth. The passive (listening) end needs a static address, the other don't. * Talk to an ethernet interface (via libpcap) and tunnel ethernet frames. * Terminate a (virtual) sync line and tunnel the frames. Handle TCP and UDP encapsulated DDCMP lines of the SIMH variety. * Terminate a MULTINET DECnet-over-IP link. (untested, but given how simple the encapsulation is...) * For ANF-10, it can connect an ethernet to a sync line. This requires slightly molesting the packets involved. It should be possible to use this to tunnel DECnet/Multinet between two nodes and keep the Multinet part local to each host. A slight perversion would be to connect a Multinet link to a DDCMP one... Source tarball can be found at: https://www.pdc.kth.se/~bygg/tops/anftunnel.tar > Johnny --Johnny (another one of them)

6 years, 6 months

RSX software...

by bqt＠softjar.se

Someone asked a while ago about DECUS software for RSX. I've now set things up on Mim. So pretty much all DECUS software can be found at MIM::DECUS: While I was at it I also decided that I might as well make some of the DEC software available as well to people on HECnet. So, there is also MIM::KITS:, which have various layered products I have tape images for. I would actually suggest people fetch things through TCP/IP and not DECnet when possible, since TCP/IP is both more efficient, and also preserves meta information better on transferred files. (But both ways will work.) So, have fun installing all kind of stuff. Also, for most things I also have manuals at http://mim.update.uu.se/manuals I have some more manuals that I have not scanned yet, and I know that some of the manuals in there are not really well scanned, and might lack a page or two. Let me know if you have any issues, and I'll try to help. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 6 months

Announcing TCP/IP for RSX-11M-PLUS

by bqt＠softjar.se

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This release contains a lot of fixes and improvements in many areas. There are a couple of very serious bugs in TCP that is fixed in this release which is why I really encourage people to upgrade. (They do not happen often, but if they happen, they have a high chance of crashing the system.) Highlights: - Stability and reliability improvements in TCP. - Improved logic for TCP probing, keepalive and retransmits. Magica (a real PDP-11/70) and Mim (an emulated PDP-11/74) have been serving traffic for several weeks without any issues, and I think I have finally found and fixed a very obscure problem that occasionally could crash the system. (And both of these machines are more or less fully exposed to the internet, so they see a *lot* of connections and random attempts to compromise them all the time.) Detailed information on things that have been done since the last release: TCP: - Correct TCP reception. It could stop the retransmit timer even if there was still data outstanding under some circumstances. - Bugfix in data resend in TCP. Under some circumstances the retransmit timer stopped even though there was data to send. - Improved TCP retransmit timers to better handle probing and keepalive. - Improved TCP keepalive timer handling. - Improved TCP timeout handling for closing sockets. - Improved TCP retransmit timer restart logic in received TCP ACK processing. - General rework of TCP retransmit logic. - Bugfix. In TCP TimeWait state, received FIN packets did not result in an RST packet. - Changed TCP FinwWait2 to use keepalive timer to probe connections. - Improvement to TCP reception to dedup received packets also for packets that are pending. - Bugfix in TCP packet sending. If we ran out of IP POOL, memory got corrupted. - Improved handling of TCP receive window if TCP receive size is shrunk. - Add probing of socket during closing stages, since we have no other way to tell if the remote end is still around. - Change how TCP decides if it should probe a connection. - Bugfix in TCP. If a socket had no window but outstanding data, and was closed, and other end never opened up a window (for example if the remote end is gone), then the socket would get stuck in Fin-Wait-1. - Changed TC driver so that user ASTs are generated immediately if there is data to be read and the AST address is changed. - Improve TCP options processing. Some badly formatted tcp options packets could crash the system. - Improved TCP handling of ICMP error packets. UDP: - Bugfix in UDP. If several error packets were received for a socket, several ASTs were queued, but only one error is saved, meaning the additional ASTs could make code try to read several times, when all except the first would not have anything to actually read. TELNET/TELNETD: - Improved abort handling in telnet client. - Changed TELNETD do do spoof notifications in a simpler way. - Rewritten TELNETD to handle fast input without loosing characters. - Fix mapping error under special circumstances in telnetd, which could corrupt the system. - Added more IAC options processing in telnet and telnetd. DNS: - Improved name resolution handling if no UDP available. - Improve resolver domain I/O error handling. RWHOD: - Added handling of no UDP available in RWHOD. MAILD: - Improve MAILD handling of DECnet connections. - Improved privilege handling in MAILD. - Improved maild unread message function. - Added manual holding of mails. General: - Improved ability to stop protocols from IFCONFIG. As usual, the distribution is available from: ftp://mim.update.uu.se/bqtcp.dsk ftp://mim.update.uu.se/bqtcp.tap ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk The documentation is also available through ftp on Mim, or also at http://mim.update.uu.se/tcpipdoc The firewall for Mim have now been removed, so no need for the alternate ports, but Mim is still listening to the alternate ports as well. ftp: 10021 telnet: 10023 Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet