Nice idea. I can certainly do this. To make it work, the node database would have to list IP addresses for MIB access. The fact that the Cisco routers don't speak NICE isn't always a problem. If they have neighbors that do I still get the information, since I will chart a circuit even if only one of the two sides tells me about it. If there is a chain of Cisco routers, the one in the middle of the chain wouldn't be mapped. But, for example, an area served by a Cisco area router would be, since the mapper will try to talk to the nodes in the area and ask them what their view of the neighborhood looks like. If all I did was a recursive graph walk the Cisco issue would be serious, but that's not what the code actually does. A closer approximation is a "bulk mail" query sent to every node in Johnny's database. paul

True, and that certainly is a good argument to do the change. To make matters easy, it turns out there is an SNMP library for Python. paul

I guess a number of things might be happening to build the map, then? 1. Johnny's database gets queried for relevant data 2. A DECnet NICE query is sent, yet these data stores do not have complete information 3. SNMP query I'm asking this for two reasons. First, Tops-20 doesn't currently support SNMP.? However, I had actually architected an SNMP server a few years ago; it would grab various bits of information via GETAB%, CNFIG% and maybe Galaxy, but would have been Read-Only.? Investigating a few things I had discerned from Windows and some embedded devices (Linksys routers and some HP print servers) as well as reviewing some RFC's, it didn't seem to be that heavy a lift. I never implemented it because I didn't have any cool management software to read all of it and display it.? I believe the only stuff I was aware of were commercial offerings (perhaps Tivoli, which means "Bring Your Wallet").? Maybe there is something now. Also, Orion implements a remote (DECnet only) interface for most relevant management (except shutdown); this could be trivially expanded to handle TCP/IP.? There was also the matter of security for setting items; I'm barely started implementing cryptography on the 20. Second, some issues with MAIL-11 and DECnet SMTP on Tops-20 have caused me to believe that one solution would be to expand the DNS service (CHIVES) to handle A and MX records for DECnet.? That's not actually that big a stretch; the DNS specification has 16 bit data types for CHAOS, which would be trivially re-usable for Phase IV DECnet.? However, I'm finding the current documentation to be a chore to wade through.? The source code incomplete in certain functionality. Assuming I get this figured out, what I would do is modify SETNOD to parse a fuller version of Johnny's database.? In addition to building the binary file for importation into Tops-20's DECnet node name hash table, it would also build a binary TBLUK% table for use by COMND% instead of .CMNOD and also a zone file that CHIVES could parse for the DNS records. Right now, I'm working on SETHOST, which is a client for the earlier NRT protocol (Network Remote Terminal) that predates CTERM on the 36 bit platform.? It's more efficient than CTERM (I have yet to compare it with LAT) and will do certain things that I like that the Tops-20 implementation of CTERM doesn't.

Correct. However, there is no need to do both 2 and 3, so worrying about SNMP on TOPS-20 (or RSX) isn't necessary. I can get everything I need from a working NICE implementation. It can even be somewhat buggy; for example I have a workaround that skips some of the requests when talking to an endnode because of a RSTS bug. It does have to be minimally sane: the Linux NICE server is so utterly broken that it might as well not exist at all. The notion of using SNMP is there to handle nodes that don't do NICE, which as far as I know only applies to Cisco routers. My thinking is that I wouldn't even try to use it unless NICE fails. paul

The mapper uses "show exec char", "show act node status", and "show act circ status". For exec char, all it needs is name and type. For act node, it wants node id/name, plus the circuit and type if the node is adjacent, though it can do without since some other implementations don't implement that. For act circ it needs the node id/name. paul

That's correct, and the network management architecture spec makes this explicit -- it shows those parameters as CM-1/2. More in general, you will see CM-x/y/z in a bunch of places, to indicate that coded multiple replies are expected but the number of elements will depend on circumstances. For example the (rather obscure) "owner" and "user" parameters for circuit are CM-2/3, and there's a logging parameter described as CM-2/3/4/5. paul

Hi. On 2020-05-05 03:46, Thomas DeBellis wrote: We might be... But maybe it is TOPS-20 who is... I'll comment below... I never suggested that CHAOS would be used for transport. But trying to make use of the CHAOS class in DNS is already where I suspect you might have trouble... It sounds like the DNS lookup hang is the problem, and that should be solved. There are no good reason why it should hang, actually. But even more, it is strange if it hangs while looking up DECnet hosts, since the DECnet mapping between a host and an address in Phase IV is *always* local. There is no such thing as a networked name service. So either you have a translation locally, or it can fail immediately. There is never a reason for any kind of delay. So if you are having problems using MAIL11, then there must be something seriously broken on the TOPD-20 side. SMTP on the other would would obviously hang on DNS resolving, if there are any issues there, just as with telnet and finger. But then the solution would obviously not be to move DECnet addressing over to also use DNS. That would only make your problem worse, since DNS is the problem in the first place. But this is all for IP. This is not (or should not) be related to anything DECnet. Unless CHIVES can tell that it is a DECnet address, and then immediately do the translation or fail, then CHIVES would actually not be the right interface for resolving DECnet addresses. It don't matter that TOPS-20 thinks it can speak SMTP over anything. Nothing else understands it. And I think you might also be confusing SMTP with the standard for internet text messages. SMTP (originally RFC 821, latest being RFC 5321) deals with the basic protocol used between a client and a server. It contains the commands defined and the response codes to them, as well as which port it expected to be used. Commands are things like: HELO/EHLO MAIL FROM: RCPT TO: DATA VRFY EXPN HELP QUIT Which then have three digit response codes. The "Standard for the format of ARPA internet text messages" (originally RFC 822, latest being RFC 5322), deals with the actual content of the mail, where you have all those mail header fields. DECnet MAIL11 fills the same function as SMTP, but obviously different. In DECnet, there is no corresponding part to the format of a text message. In MAIL11, the mail body is all there is, and it is always all assumed to be meant for the recipient human being. There is a bit of additional meta-information available in MAIL11, which is carried in the connect message, which allows you to send arbitrary binary files as well, without confusing anyone. In the IP world, that is sortof solved through MIME, which is a very different mechanism. But all of this is sortof besides the point. If the recipient is a DECnet address, it is clearly visible since mail addresses in DECnet (and MAIL11) are very different from addresses in IP using SMTP. So any kind of resolving that needs to be done can easily tell in which domain the lookup should happen, and then proceed with the right kind of lookup from there. And for the reference, addresses looks like this: MAIL11: NODE::[NODE::]USER "Personal name" SMTP: "Personal name" <user at host> There can be any number of nodes in the list of nodes in a MAIL11 address. But each ends with a double colon. And the last part, after the last double colon is the username on that last machine. Anything after a space is then assumed to be the person name of that user. Addresses are parsed left to right, and for each machine, you only look at the first node, which is the next hop for a mail. You do not need to specify explicit hops, but you can, and sometimes you want to. Because, the next hop address is processed on that local machine. So you can send to a host you don't even know which address it has, since you don't have to know that. All you need to know is the address of the next hop, and anything beyond that is then the responsibility of the next hop to figure out. In SMTP, address is supposed to always be between <>, and is essentially processed right to left. While possible to give multiple explicit hops, that is generally discouraged, and often explicitly disabled in mail servers. Of course. And they could not be, since DNS do not handle DECnet, and DECnet do not use any name service at all. It seems TOPS-20 is a bit broken and confused here. It should not ever try to look up a DECnet name using DNS. It should be able to tell that this is a DECnet address, and not even think about using DNS. Uh... No. CHAOS information is not a type record in DNS. It is a CLASS. If you ever looked inside a DNS zone file, you'd see a lot of things like: FOO IN A 1.2.3.4. Well, if you have CHAOS, you'd see: FOO C A 1234. It's still a type A record, but with a class of CHAOS instead if INternet. And CHAOS addresses are supposed to be 16 bit octal addresses as one number. So yes, in a sense you could place a DECnet address in a CHAOS address, since they are both 16 bits. But you'd also need anything that deals with DNS to understand these CHAOS records and propagate them. When you start a DNS query, you might hit a local DNS server, or you might even go to some root. Queries might be recursively forwarded on your behalf. When you do the query, you need to tell what class and type you are looking for, which means that any DNS server involved needs to understand and deal with the CHAOS class. And that was my first objection. I wonder if anyone really have a DNS server today that even understands the CHAOS class. It is defined in the standard, but noone have even dreamt of testing or maintaining that for probably over 30 years. And adding a new class, DECnet, would be even more complicated, since that would then require that all DNS servers and other code were made aware of this class, or they will just drop that information on the floor. So here is where I think TOPS-20 is mixing apples and oranges. It should not mix up DECnet and IP addresses and names to start with. They are two different things. Two different domains of names, which work in different ways, and are looked up in different ways. It's rather broken, I think, of TOPS-20 to mix up the two. Like I said, I doubt you'll get this to work. :-) MAIL11 have lots of issues. But it's been the way it is for 40 years. We are not going to change it. There is plenty of software today that we don't even have the sources to. You do SMTP over IP. You do MAIL11 over DECnet. It's as simple as that. If you've seen an SMTP over DECnet implementation for VAX, that would be an interesting thing to hear about, but it won't change the basic premises. Out of curiosity, which known object did SMTP over DECnet use? 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

What's fun about the Tops-20 NRT client (SETHOST) is that it doesn't do much aside from parsing for an escape character and node name.? It builds a connection string and checks to make sure the remote system is either a 10 or a 20.? Then it twiddles a few things on the terminal (a few more if you're running my changes to handle page mode).? Finally, and this is the cool part, it issues an MTOPR% to directly connect the local user's terminal to the open DECnet connection (port 23). Thereafter, the client does nothing until the interrupt character is typed or the connection is broken.? So response can be pretty snappy because you are never running in user space; no context switching.? The CTERM client on the other hand is reading and writing data and otherwise handling the specifics of the protocol in user space.? So, more overhead and more context switching. As an experiment, I removed the checks for Tops-10 and Tops-20 and tried connecting to a few hosts on HECnet. * Tops-20; TOMMYT and TWENEX worked (of course) * Tops-10; VENTI worked * RSX-11+; MIM accepted the connection and broke it as soon as I started typing. * VMS; LEGATO accepted the connection and broke it as soon as I started typing. * RSTS; TRON accepted the connection and then did nothing.? It never broke the connection, but never displayed any banner or anything else.? It appeared hung. So it would appear that NRT servers only exist on the 36 bit line.? Perhaps it's possible to configure the service for other platforms? The first few RSTS systems I tried didn't appear to be online; MEZZO, PLUTO, RSTSE and BITXOT.? The few Windows systems I checked didn't appear to be online, either; WXP, MISSY, KIBBEH and WATAN. I'm not sure if that means they refused the connection attempt outright.

Thanks Paul, As usual, very informative.? What you've verified is Tops-20's monitor based NRT server implementation, which is good. Therefore, for the moment, I think it reasonable to assume that the monitor client implementation is also not suspect. NI1D displayed the same failure mode as Tron: report of a successful connection and then, nothing, viz: % Do not have Control-C capability, proceeding... Escape character(^Y): Host name: NI1D [Connecting to remote host: NI1D] [Remote system is running RSTS/E] [Connected: type ^Y to return to node VENTI2] This shows that the client had a successful connection and handed off to the monitor.? This was verified by further investigation (with SYSDPY which showed SETHOST in a WAIT%, pending interrupt from the MTOPR%).? Since the NRT client implementation eventually hands off to the monitor for all the data flow, for Initial investigation, I'll have a look at some that pre-MTOPR% post-connection open logic.? I'll try to do a little more trouble shooting tonight and see what might be happening. You mention four 'flavors' (?) of NRT; are these documented anywhere?? (I mean, other than in the code...) ??? ??? --T

From RSX, using the system specific tools for different OSes: .rrs ni1d MIM::RRS -- Connection established to node NI1D:: RSTS P10.1-L 03-May-20 03:02 PM User: 100,100 LAST INTERACTIVE LOGIN ON 03-MAY-20, 08:49 AM AT KB21: SET JOB/KEYB=DCL ^ ?ILLEGAL KEYBOARD MONITOR NAME $ .host venti SIMH KS10 VENTI 7.04 NET 11:40:52 TTY10 system 4999 Connected to Node MIM Please LOGIN . .host venti2 VENTI2, PANDA TOPS-20 Monitor 7.1(21741)-5 Welcome to Tommy Timesharing Test System on Neptune Hardware! This system is for testing purposes only and may immediately disappear. Be careful!! @ So working fine from RSX to both RSTS/E, Tops-10 and TOPS-20. 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

Hi. On 2020-05-05 22:08, Thomas DeBellis wrote: Oh, I wouldn't say they got things right. Just that you had some more development going on for a long time on DECnet/RSX, which comes as no surprise. However, they were unmaintained for the longest time, and I think they don't work out of the box anymore, and I had to fix a few things in the code. Yes, they are different programs. There is also RVT, for talking to VMS hosts without using CTERM. I can maybe comment on the protocol details, if I look at the sources. I do not have enough in my head, and I don't think I can share the sources at this time. I could look at that as well, but I would really recommend people to use telnet if possible instead. :-) 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

Paul, Do you have a copy of ?dnterm"? I maintain a git repository of the Linux DECnet source tree and the only remote terminal application is ?dnlogin? which only speaks CTERM. The documentation also references something called ?rmtermd/dterm? but that has gone missing too. John.

It is a DECnet/Linux application; you should be able to find it in those sources. LAT knows nothing about terminal driver semantics; it merely implements a raw data stream in both directions. But it combines data for several terminals into a single Ethernet packet if it can, and it has some holdoff to try to collect multiple characters arriving back to back. So it knows that the terminals are used by humans who won't notice delays well below 100 ms. On the subject of context switching for every character, that's certainly tricky but if you plan for it from the beginning you can make it work unusually well. A case in point is the PLATO system, which in 1976 had up to 600 logged-in terminals connected to a pair of CDC 6500 small mainframe computers. Those were graphics terminals, highly interactive; typically about 50% of keystrokes required application action (rather than simply echoing while collecting a line's worth of input). It worked very well, with delays almost always low enough that you wouldn't notice. One reason it worked is that the swapping was doing to/from high speed bulk core memory, at 600 Mbit/s. So while the application context was perhaps 200-300 words, moving that takes only 40-50 microseconds. Yes, and they are critical. The OS type is just information, but at offset 6 you'll find the protocol ID, which tells you which of the four protocols to speak. If you ignore that you will certainly get wrong results. See the doc I sent. paul

Hi. Even more things then... On 2020-05-05 07:14, Thomas DeBellis wrote: Makes sense. I think essentially all OS specific remote terminal protocols used object 23. The RSX one certainly does. The client should check that the remote system then is of the expected type, or else things will (obviously) not work well. Probably because the RSX server expects the RSX specific remote terminal protocol, which most likely do not match the 36-bit one. VMS might have something RSX-like going on there. I can't really tell, as VMS don't seem to support showing known objects. RSTS is probably using object 23 for the RSTS/E specific terminal protocol, and that server is apparently not cooperating with your SETHOST. :-) It's a bit more complicated than that, but I hope you have a better idea now... WXP is definitely not online right now. 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

I used to use set host/app=rt <rsts-host> under VMS but since I switched on LAT, I've used that almost exclusively because it's much faster, though of course it doesn't route anywhere. Keith -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul Koning Sent: 05 May 2020 14:26 To: hecnet at update.uu.se Subject: Re: [HECnet] Cisco DECnet routers and NML CTERM isn't implemented by DECnet/E (RSTS). But it does implement the older protocol, and for that matter it implements the pre-CTERM protocols used by RSX and by VMS. These are in the "unsupported" version of the set-host utility (net.tsk) which is part of the kit. The supported version only implements the RSTS remote terminal protocol. But the other one works well, as it has to -- it was the one used throughout DEC's internal network. paul

Hi. More stuff to comment on. Fun! On 2020-05-05 04:13, Thomas DeBellis wrote: Right. And RSTS/E had its own protocol, as did RSX. And they were all sortof optimal for each system. The VMS came with CTERM, and everyone was expected to do that one, and it's more akin to an RPC-based system than some kind of terminal. But, ugly as it is, it's the closest to some kind of lingua franca. But I think CTERM have issues on every system except VMS (I don't know, they might have problems even with VMS only, who knows? CTERM is ugly.) But RSX ships with the system specific remote terminal clients as well, so I have a client for talking to TOPS-20 using that protocol, and a client for talking to RSTS/E using that protocol... RSX have a client. 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

On 2020-05-05 22:55, Paul Koning wrote: Realized that later, as I started poking around at the clients I had for RSX and found RVT, which is for talking to VMS... I think I might have looked at some specs at some point, but long long ago, and I can't remember much of anything. That war would have been interesting to see. LAT performs rather well I must say, so Bruce Mann definitely did something better. CTERM definitely is overengineered, and also smells like designed by a committee... I guess that might be. It's obvious they had some grand ideas anyway. The DECnet protocols are not bad in some areas. There was definitely some good thinking going into extensibility and backward compatibility. It is, however, a bit awkward when writing programs and debugging. Maybe there were better tools available somewhere, but for the most part, I just write stuff in blindly and test until I start getting it to play. TCP/IP is nice in that way, if we talk about the old protocols. Text based, and you had telnet. So it is really easy to test and play around. I guess that is mostly going away now, with TLS and all the binary protocols coming. Yeah, all of these programs under RSX is in the "unsupported" category, but provided. Which is nice. That RSTS/E baked them all into one is definitely much nicer than the RSX solution. Not sure why they did it the way they did. 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

On 5/4/20 7:24 PM, Johnny Billquist wrote: I've made extensive use of CHAOS class records in the past. Not for CHAOSnet, but for other stuff when I was running very large nameservers at an ISP. But tonight I tried to put a CHAOS class record into my current nameserver, and it appears that BIND no longer recognizes this class. I'm running 9.12.1-P2. I was surprised to see this, though it has been probably 25 years since I'd used CHAOS. I wonder when support for this was removed. There is an "internal" special record type supported by BIND, class CHAOS, type TXT, name version.bind, that returns the version number of the BIND software, but this is not tied to zone files and I don't believe (though I've not verified this) that it supports arbitrary data of the CHAOS class. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On 5/5/20 10:42 AM, Jesper Christensen wrote: Oh, too cool! I didn't look extensively, but I stuck a CHAOS TXT record into an existing zone and reloaded, and it complained about that line (saying it wasn't class IN) and failed to load the zone. It's odd to me that it would require a separate view, but I'm glad to see it's still supported. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Well, yeah, but 'better' can be a very loaded word...? The NRT protocol certainly appears simpler than CTERM, which struck we Tops-20 developers as very VMS-centric, too. The Tops-10 and Tops-20 groups operated in a realm where a lot of money was getting spent on costly systems that were nearly always saturated with too many users.? Tops-10 SMP alleviated certain cases of this.? That functionality could have been more fully leveraged in Tops-20, which supports a richer process model, but the hardware didn't support multi-ported memory.? Multi-processor TENEX did exist.? I recall a dual KI TENX on the ARPAnet; it may have been SUMEX-AIM.? Tops-20's CI implementation was nice, but it didn't solve all the problems that SMP (or the KC) would have. Given the above, there was an emphasis on simplicity of design and code efficiency unless hair was absolutely necessary.? This isn't to say that some pretty complex code wasn't written, but this was typically to wring as much as possible out of the processor. VMS and RSX seemed to have poked their heads up in other areas of DECnet.? Tops-10's (pre-level D) file system is basically block structured.? The blocks are larger in Tops-20, I/O is more efficient, the files can have holes, a character (byte) interface exists and the lexical interface is richer.? We were aware of the richness of the MVS file formats, but had never seen any particular use for the complexity.? When we bumped into DAP, the first response was, "Gee, what do you need all this MVS stuff for?" DAP certainly does more than FTP can by far, but all the file formats were lost on (the few) developers who knew both MVS and Tops-20. The question for CTERM is what is the additional hair really getting you?? What can it do that NRT doesn't.? From the user mode, you can't tell the difference (modulo certain shortcomings in the Tops-20 implementation that I don't know if they are being caused by the protocol).? I have only a passing familiarity with CTERM, some with LAT and little with NRT; so I can't really comment on what the CTERM value add is/was.

Unfortunately this doesn't seem to be feasible. The issue is that my ISP blocks SNMP outbound -- I have no idea why they would so such a thing. And as far as I can tell there isn't any way to tell Cisco to accept incoming SNMP requests on any port other than the standard one. paul

On 5/5/20 5:22 PM, Paul Koning wrote: I would be on the phone with them cursing a blue streak. I mean, do they sell you a damn net connection, or not? There's life outside of port 80! Wow. One thing you might be able to do is create a port mapping coming into whatever terminates the "web browsing connection" from your upstream provider, on some port that they don't presume to block, forwarding back to port 161 on the Cisco. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

I'd be on those people like white on rice. Don't run Windows and it's not a problem. You should at least be able to opt out of that BS. If not, I'd suggest finding a decent upstream provider. -Dave On 5/5/20 6:15 PM, Supratim Sanyal wrote: -- Dave McGuire, AK4HZ New Kensington, PA

They are unfortunately mostly incompetent, set to watch over even more incompetent people hooking up to the internet. So they try to do what they think is right, but it's a royal pain for people who actually do know what they are doing, and who want to do some things... (I will not even tell you how much problems I have with mail in different directions...) Johnny On 2020-05-06 00:15, Supratim Sanyal wrote: -- 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

I think they just meant TCP. I'm not sure those clowns would even understand that UDP is a separate name space, separate protocol, and their firewall rules are not actually applying... (Well, ok, I would hope they understood as much, but I've had to fight ISPs enough to last me a lifetime...) Johnny On 2020-05-06 01:32, Peter Lothberg wrote: -- 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

Oh, it's not just the rules that are not understood nor kept up to date, sometimes it's the firewall software itself. One time my phone rang and it was my boss turfing an emergency on me with an EVP whose FTP "wasn't working; it just hangs".? As you can guess, it was, "Drop what you're doing and get this done now!!"? EVP's get listened to...? So I immediately tried it myself and naturally, it worked just fine.? Turns out that I was using Windows (at the time) whose clients sent RFC959 compliant data connection verbs, PORT and PASV. Some further digging with the network heroes got a trace showing that the EVP's machine was a Mac sending the IP6 compliant verbs, EPRT and EPSV, which are somewhat backwards compatible for sending IP4 addresses.? It's a very reasonable thing to do, but in retrospect, the FTP client should have issued a FEAT to see if the remote system even supported the new verbs. The problem was that the firewall software didn't know about the verbs and simply swallowed them, never giving any indication that this had happened.? After an upgrade, everybody lived happily ever after, more or less. Come to think of it, I don't think that the Windows client at the time implemented passive mode; it may still not do PASV. Had you ever gotten the impression that the overall level of competence of many technical support organizations is steadily declining?? I keep finding myself teaching these guys things... Simple things... On 5/5/20 7:36 PM, Johnny Billquist wrote:

They allow client connections to their own NTP servers. The problem is I had four servers contributing to the NTP Pool project (https://www.ntppool.org/a/chk9fxzbh9h64vbcdx6dr). Upgrading to their newer hypervisors is their solution. I have started to migrate.

Oh, there's hardly any need for such language; they'll pretty much do what you want if you threaten them with payment. For residential offerings, which what Paul probably has, certain ports are blocked for your 'benefit'; 25 being one of them for one of the local carriers here. So naturally I called up and whined about it to be promptly referred the commercial offerings department whose basic business model appears to be "Bring your wallet".? But a lot less was done for you (or to you). I only know of one carrier here who will let you do whatever you want; but they're great--no DHCP nonsense: you get a static IP for the same price.? I used them for years until I moved to an area where they didn't have service.? Darn near broke my heart... On 5/5/20 6:05 PM, Dave McGuire wrote:

Where I used to live, I had three great ISP's to chose from, so I picked two for redundancy, the secondary being the static IP ISP below, whom I had also used in NYC (actually LIC). But sometimes you don't have overall control where you wind up and now I 'only' have two ISP's that ferociously compete; one being a lot more reasonable about IP addresses and port blocking. Let's say I was more fortunate than others. If I ever move again (which I have mixed feelings about), connectivity will certainly be an important consideration.? I don't know how my wife would feel about no running water; Mrs. will have her baths...? On the other hand, she is almost as big a nerd as I am, so that conversation might be 'interesting'.? I guess if a sparkling river ran through the place and I told her I'd haul the water, she'd go for it. Hauling water in the winter is tough; particularly if you happen to slip and fall in.? WOW!? You'd think the water was colder than the ice and snow.? I made it back to the house with two buckets pretty quick. On 5/5/20 6:41 PM, Dave McGuire wrote:

On 5/5/20 6:30 PM, Tomas Prybil wrote: Well, only if we can ALSO run on 161. My upstream is bridged, and my routing is done by the same Cisco as my DECnet stuff, so I can't easily translate that for inbound requests. -Dave -- Dave McGuire, AK4HZ New Kensington, PA