HECnet

hecnet@lists.dfupdate.se

5 participants
15579 discussions

Start a nNew thread

Curious about DECnet/Python

by Keith.Halewood＠pitbulluk.org

Hi, Ok, so I've noticed... and I'm curious about DECnet/Python. Are there any details? Keith

5 years, 11 months

GRE mesh | Tunnel to Area 23?

by supratim＠riseup.net

My GRE tunnel to Mark Thomas' Area 23 is down for a few days now. All other tunnels are up. Here's the interface; any advice appreciated. Thank you. Tunnel23 is up, line protocol is up ? Hardware is Tunnel ? Description: HECnet tunnel for Mark G Thomas (Area 23) [Version:307] ? MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec, ???? reliability 255/255, txload 1/255, rxload 1/255 ? Encapsulation TUNNEL, loopback not set ? Keepalive not set ? Tunnel source 10.42.2.204 (FastEthernet0/1), destination 71.246.8.102 ? Tunnel protocol/transport GRE/IP ??? Key disabled, sequencing disabled ??? Checksumming of packets disabled ? Tunnel TTL 255 ? Fast tunneling enabled ? Path MTU Discovery, ager 10 mins, min MTU 92, MTU 0, expires never ? Tunnel transmit bandwidth 8000 (kbps) ? Tunnel receive bandwidth 8000 (kbps) ? Last input 1w5d, output 00:00:04, output hang never ? Last clearing of "show interface" counters never ? Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 ? Queueing strategy: fifo ? Output queue: 0/0 (size/max) ? 5 minute input rate 0 bits/sec, 0 packets/sec ? 5 minute output rate 0 bits/sec, 0 packets/sec ???? 74013 packets input, 5838030 bytes, 0 no buffer ???? Received 0 broadcasts, 0 runts, 0 giants, 0 throttles ???? 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort ???? 213256 packets output, 13234292 bytes, 0 underruns ???? 0 output errors, 0 collisions, 0 interface resets ???? 0 unknown protocol drops ???? 0 output buffer failures, 0 output buffers swapped out CISCO7204VXR_IMPRTR>show decnet route ? Area?????? Cost? Hops?????????? Next Hop to Node Expires? Prio *1??????????? 13???? 2???? FastEthernet0/0 -> IMPVAX *2??????????? 22???? 4???? FastEthernet0/0 -> IMPVAX *4??????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *5??????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *7??????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *8??????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *12?????????? 20???? 1??????????? Tunnel12 -> A12RTR 35???? 64? A+ *19?????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *22?????????? 20???? 1??????????? Tunnel22 -> A22RTR 44???? 64? A+ *23?????????? 30???? 2??????????? Tunnel22 -> A22RTR *24?????????? 16???? 3???? FastEthernet0/0 -> IMPVAX *27?????????? 10???? 2???? FastEthernet0/0 -> IMPVAX *28?????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *29?????????? 13???? 2???? FastEthernet0/0 -> IMPVAX *30?????????? 10???? 2???? FastEthernet0/0 -> IMPVAX *31??????????? 0???? 0???????????? (Local) -> IMPRTR *33?????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *34?????????? 24???? 4???? FastEthernet0/0 -> IMPVAX *39??????????? 8???? 2???? FastEthernet0/0 -> IMPVAX *41??????????? 8???? 2???? FastEthernet0/0 -> IMPVAX *42?????????? 20???? 1??????????? Tunnel42 -> HUB 32???? 64? A+ *55?????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *59?????????? 17???? 3???? FastEthernet0/0 -> IMPVAX *60?????????? 21???? 3???? FastEthernet0/0 -> IMPVAX *61?????????? 20???? 1??????????? Tunnel61 -> A61RTR 36???? 64? A+ -- Sent via Thunderbird/MX-Linux on an overheated Compaq Presario CQ61

5 years, 11 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. Highlights: . TCP have had some potential fatal bugs fixed, and some significant performance improvements. . FTP have received significant performance improvements. . Various tools and drivers have had improvements in order to support more than one ethernet interface. *** For these reasons, it is strongly recommended that systems be upgraded to the latest version at your earliest convenience. Detailed information on things that have been done since the last release: IPGEN: . Corrected IPGEN to be able to generate configurations with multiple Ethernet interfaces. . Bugfix for no purge options, which did not work. IF: . Bugfix in interface driver. IO.RIF did not return proper status. UDP: . Added ability in UDP to bind socket to specific interface. TCP: . Improved TCP retransmission strategy. . Rewrote TCP ACK generation and window update handling. . Bugfix. A TCP connection in the process of closing down would just absorb incoming SYN packets to the connection. They should be responded to with a RST. . Bugfix in some longword processing that could potentially cause wrong effects under rare circumstances. . Bugfix in TCP. I/O writes of more than 8K was accepted, but actual data was not transferred correctly. . Bugfix in TCP. I/O reads of more than 8K was accepted, but should not. This could crash the system. DHCP: . Corrected DHCP to detect if interface do not start. . Rewritten DHCP to handle interfaces properly also if there are multiple interfaces using DHCP. . Rewritten DHCP to better handle options and to try explicit renews instead of always starting over with request when time is up. IFCONFIG: . Add indication in IFCONFIG SHOW IF to indicate if interface is running, also for DHCP controlled interfaces. TELNETD: . Added additional space in telnet UCB, and telnetd now stores remote address in UCB. (Separate changes to RSX can enable reading this out via QIO to TT:) SPOOF: . Added notifying the SPOOF handler for some more TCP situations. . Bugfix in SPOOF. Under some circumstances, it could loose track of hosts it was blocking, and never unblock them. . Changed spoofer to be capable of blocking different network block sizes. FTP/FTPD: . Improved file handling in FTP for RSX and block mode. Performance is now close to 2x as fast as before in some situations. Multinet: . Improved handling of connections in Multinet. . Added ability to change mode of Multinet links to either be VMS compatible, or pure DDCMP style. . Bugfix in MLTNET. There was an odd address error in one place. . Improved MLTNET handling and recovery from some communication errors. . Updated IPNCONFIG.CMD to new version from Oleg Safiullin. MAILD: . Corrected block lock handling in MAILD, which could sometimes keep blocks locked for long times for no good reason. . Mailbox format slightly changed. MBXUPD needed for upgrade. XLISP: . Added port as a parameter to connect function in XLISP. Datatrieve-11: . Added proper interface to Datetrieve-11 from PDP-11 C. MCR: . Bugfix. DEV /FILES could crash RSX. *** Important notice about MAILD *** The changes to MAILD are not seamless. When installing the new version, the mailbox update program should be run, in order to upgrade all user mailboxes to the new mailbox format. The task for this is MBXUPD.TSK. There are no issues with running this task several times. A mailbox that has already been updates will not be modified anymore by the update task. 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 I hope people find this update useful. 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

5 years, 12 months

Another date limit?

by paulkoning＠comcast.net

In the Phase IV network management spec the description of the encoding of the event log message has this field: JULIAN HALF DAY (2) : B Number of half days since 1 Jan 1977 and before 9 Nov 2021 (0-32767). For example, the morning of Jan 1, 1977 is 0. It's a 16 bit field containing a 15 bit value; there is no explanation why the upper bit is not used even though it's marked as an unsigned integer. As shown, the field overflows in late 2021. If one ignores the arbitrary limit of 15 bits, the end date is 18 September 2066, which is more civilized. I wonder if implementations ignore the 15 bit limit. I think RSTS/E ignores it. paul

6 years

RQDX2?

by bqt＠softjar.se

I'm searching for an RQDX2 controller. I know this is maybe a bit off from normal HECnet discussions, but I'm hoping that maybe some people might happen to have some real hardware. I have a few RD53 drives I'd like to read out the contents of, and it seems they were controlled by an RQDX1 or RQDX2. I have an RQDX3 controller, however, the on disk format differs between the RQDX1/2 and the RQDX3, so I don't have any ability to read the drives right now. Since I am in Switzerland (near Zurich) someone local would be much easier, but if someone somewhere else have a card, is willing to ship it, and don't expect a bunch of money in return, I'm interested in that too. If nothing pops up, and can solve this myself at Christmas, when I go back to Sweden, where I have access to more hardware. But being an impatient guy, I'm trying this option as well... :-) Also, an RQDX1 should also work, but if possible, I prefer the RQDX2, since the RQDX1 have some additional issues... And of course, if I manage to get the data out from the drives, there might be some useful things on there that I can share in the end (I'm specifically searching for a few files needed to complete a Modula-2 compiler that exists for RSX). 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

HECnet routing costs

by bqt＠softjar.se

People, I have written a page about DECnet costs and HECnet costs, which I would recommend that anyone interested read through. It contains a bit of elaboration on how DECnet does routing, and gives some suggestions on how costs could be set on HECnet to make it perform better. I have noticed over the years that sometimes we do get really silly routing decisions just because of how people set, or do not set costs. The page I've written is by no means perfect, nor are the suggestions in there. But feel free to come with feedback, or ignore it. But I am going to try and use this myself more properly from now on, and that means that if others don't, you probably are going to get more traffic through your nodes. Traffic that probably do not make sense that it passes through you, but I just feel that I prefer to try and make it work right from my point of view, and then just at least tell people how I worked my numbers out. If someone have a different idea, I'm open to changing my settings, but I will not try and do optimizations to achieve: a) Same paths for packets in both directions - DECnet explicitly does not do this. b) Specifically penalize one type of interface because of any subjective preference about that type of interface in general. Oh - and the link to my writeup: http://mim.update.uu.se/costs.htm 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, 1 month

DECnet/E install

by paulkoning＠comcast.net

I've worked on RSTS and DECnet/E for a long time but I only very rarely do a formal install, so I don't have the knowledge handy. I just did a V10.1 install, and now would like to do the matching DECnet install, but I can't figure out how to do that and I can't find a DECnet/E installation manual. Can anyone give a quick outline of how to do this? paul

6 years, 1 month

DECnet Implementation and Productization of RSX-11M, 11S, 11D and IAS (was Re: Anonymous FAL (Tops-20))

by wilson＠dbit.com

From: John Forecast <john at forecast.name> [E11 on MIM] >Does the simulator actually simulate the caches or just the control registers >like SIMH? Just the control registers. I hate doing an emulation of a speed-up feature which actually slows it down (which is the case with the FASTBUS: emulation for dual PDP-11/45s but there was no way around that -- making the memory inherently mP-safe meant dinking with locks on every access, so it's *much* slower to touch it than non-"FAST" core). It might be interesting to do as a SET CPU option though, for testing how code would behave in nasty cases on a real 11/74. The fetch/decode/dispatch loop and the most common instructions are recompiled (from scripts) on every SET CPU command, so options like this can be added without penalty, as long as they're disabled by default. It'd be pretty painful though, since in this case *anything* that touches memory would have to be compiled at runtime, so it'd be a lot more code than it is now (less common instructions are static and check the SET CPU flags themselves on the fly rather than having their behavior hard-coded into the compiled code). John Wilson D Bit

6 years, 1 month

Anonymous FAL (Tops-20)

by tommytimesharing＠gmail.com

I have some software that I'd like to post, but don't recall how to configure FAL to allow for an anonymous connection; to download from a restricted directory. I know how to do it for the FTP server (seeing as I wrote it), but ... different code base. I can only vaguely remember what we did for CCnet at Columbia University in the 1980's, but I think it was kind of a hack.

6 years, 1 month

Windows 10 DECnet?

by bygg＠cafax.se

Johnny Billquist <bqt at softjar.se> wrote: > My experience with latd in Linux is that it sucks. It sortof works if > you are lucky, but there are problems in it, which makes it undesirable > to use with RSX at least. My experience is that for connecting to a Tops-[12]0 system it works, even if the thing, as you say, sucks in several ways. Considering myself lucky then. --Johnny (the other one)

6 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet