Hi folks, has anyone here used a Lantronix ETS-series or similar
terminal server for LAT connections to RSX? We're having a strange
problem at LSSM and could use some info.
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Time for a new release announcement of TCP/IP for RSX-11M-PLUS.
This is version 2.18 of BQTCP/IP.
It's been a while since the last release, and quite some improvements
have been done in several subsystems. Some of them are rather
significant, and a recommendation to update to this new version soon is
recommended.
Highlights:
. IP logging facility have been added, logging various bad packets.
. Improved IP multicast handling.
. Added functionality to have system not respond to Multicast packets
that could potentially be abused for DDoS attacks.
Detailed information on things that have been done since the last release:
Ethernet:
. Bugfix. The initial multicast list enabled on ethernet was wrong at
the MAC level.
. Bugfix. Network directed broadcasts did not get correct dst MAC.
. Various optimizations and improvements handling broadcasts, multicasts
and route lookup processing.
. Bugfix. ETHACP didn't properly pick up ethernet multicast indication.
IP:
. Improved statistics around IP fragmentation.
. Added IP transmit broadcast statistic
ICMP:
. Bugfix. ECMP ECHO requests to broadcast was responded with a MAC
broadcast, even though we had an IP address it should go to.
. Improved ICMP histogram statistics handling.
IGMP:
. Bugfix in IGMP. Timer processing for IGMP reports didn't work properly.
UDP:
. Added information about broadcast and multicast response block to UDP
receive IOSB.
TCP:
. Changed TCP to still deliver received data if remote does an RST after.
. Clean up TCP reset handling.
. Cleaned up TCP counters.
. Improved TCP QIO write operations to include CR+LF if VFC says so for
any mode.
. Changed conditions for TCP keepalive vs. window probe.
DHCP:
. Improved DHCP client to do broadcasts that are not looped back.
. Improved handling of address changes in DHCP and router table.
. Changed resolver to not use DHCP provided resolvers, if a more
specific resolver have been requested by logical name.
DNS:
. Added more logging about tracking bad server in DNS.
. Bugfix in DNS. Under some circumstances, the parsing could reject
correct packets.
. Changed DNS to better handle CNAMEs.
. Improved handling of non-responding DNS servers in resolver.
. Bugfix. RESACP didn't properly detect truncated responses.
. Bugfix. RESACP failed to properly handle F11 hostnames.
IFCONFIG:
. Added HELP command to IFCONFIG.
. Added IFC SET IP MULTICAST RESPONSE ENABLE/DISABLE and IFC SHOW IP
MULTICAST.
. Bugfix in IFCONFIG with SHOW LOG failing.
. Changed IFCONFIG to always show interface network mask numeric.
FTP/FTPD:
. Bugfix. FTPD got into a bad state if a directory listing was requested
with an illegal file name, or other error.
. FTP improved error handling in communication.
. Bugfix. FTP/FTPD could get the wrong file if a directory operation was
done before reading a file.
Multinet:
. Added handling of transmit errors in Multinet.
. Added calling SPOOF from Multinet when there seems to be bad behavior
from a remote host.
RWHOD:
. Improved rwhod error reporting.
SMTP:
. Improved SMTP send hostname processing.
. Improved SMTP mail sending.
LOGGER:
. Added IP LOGGING task and functionality.
TELNETD:
. Bugfix in TELNETD. Under some circumstances, TELNETD could crash the
system.
LPT/LPQ:
. Improved LPT and LPQ printer logical name processing.
RMD:
. Changed RMD task header page to show more information on TC:
Some additional notes:
As usual, I would recommend people to update as soon as possible.
The changes are somewhat critical, but will also lead to a much better
experience.
The patches to the TT: driver cannot be applied automatically, but
requires users to apply the patches themselves, and then run SYSGEN to
generate a new system.
Once added, the TNC2 task can be run at login, and will define logical
names for the user telling where he is connected from, if using telnet,
DECnet or LAT.
TNC2 can get information about remote connections over DECnet as well,
but this requires updates to DECnet. Such patches are not available
separately at this time, but are included in the RSX image provided from
Johnny Billquist.
The TT: driver patches also allows the updated MCR to give more
information with the DEV command (SHOW TERMINAL in DCL).
The patched TT: driver also makes is possible to get telnetd fully
vectorized, as this version provides two more addresses that are
required by telnetd to access information in the kernel.
The other patches to RSX can be applied automatically by IPGEN, either
if used interactively when answering YES to the question about applying
RSX patches, or by running IPGEN explicitly to do the patches, with the
command:
@IPGEN PATCH
Specific information about the patches:
LAT: Fixes a memory leak, and adds the ability to read where a terminal
connection comes from when using LAT, using SF.GMC.
RMSDAP: Fixes a bug in getting the file protection, so the XAB gets
filled in correctly for remote files.
RMSDSP: Fixes that some numbers were displayed in signed octal, which
should have been displayed in decimal or unsigned octal, depending on
number.
DCL: Added terminal attributes for COLOR.
MCR: Too many fixes to be listed here...
INS: Fixes that users cannot circumvent protection on common regions.
HEL: Fix that users can login with session ID, or with directory, in
addition to name and UIC.
ACNT: Add no password change attribute to accounts.
PSW: Add no password change handling.
SYL (SYSLOG): Add terminal idle tracking on accounts without idle logout.
ECL: If the receiving machine is very slow, and the sending machine is
very fast, and the receiver announce several large buffers available,
ECL cannot keep up, and drops packets. This is a problem with the DECnet
flow control, as it is used in RSX. The simple solution is to allow more
outstanding buffers when receiving. A more complex solution would be to
change how RSX DECnet do flow control, but that would require rewriting
a fair chunk of the ECL module.
NMVACP: Fix handling of "show known nodes" command, which could skip
some nodes.
NVP: Add ability to use session ID or directory name for user identity
in DECnet nodename specifications.
EPM: Fix handling of ethernet multicast.
NTDEMO: Fix that hosts without names should display DECnet address.
NCP: Parse of additional information types in NICE messages.
*** NOTE ***
MIM have moved to a new address, and a new name. The correct name is now
Mim.SoftJAR.SE. I hope that this will now not need to change again.
*** NOTE ***
As usual, the distribution is available from:
ftp://mim.softjar.se/bqtcp.dsk
ftp://mim.softjar.se/bqtcp.tap
!!! BQTCP is also available through RPM !!!
(As an additional note, if there are any problems communicating with Mim
using port 21, the ftp service is also available at port 10021)
The documentation is also available through ftp on Mim, or also at
http://mim.softjar.se/tcpipdoc
I hope people find this update useful.
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
Hey, fellow DECheads! I'm proud to announce that the Large Scale
Systems Museum is approaching the 10th anniversary of its first public
opening. We are doing a fundraiser event on October 17th and 18th, and
we have a few slots left. If you can't make it in person but still want
to contribute, there's a way to purchase a "non-attendance" ticket.
LSSM is a 100% donor-funded 501(c)(3) nonprofit public museum based
in Pittsburgh, PA, USA. All fundraiser proceeds to directly to funding
museum operations.
Sign up here: http://www.lssmuseum.org/10
Thanks,
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
MIM needs to be taken down for about 1 hour on Fre Sep 12, at 9PM UTC.
Just a heads up for all people, so they know it's happening.
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
[I mistakenly sent this reply to an address not subscribed to the list.]
On 2025-09-06 16:30, Brian Roth wrote:
> This is really kicking me. I have a rack with 5 Pi's in it. All are
> going to the same switch. 2 of them have 4 simh instances each that are
> working fine (DECNET). TCP-IP is working fine on all of them. They are
> all wired. On the Pi thats running SCOOBY I created a 11/780 running
> VMS 5.5. It does not communicate as well even though it says circuit up
> (same problem as SCOOBY) OK, I created another instance on an entirely
> different Pi with the same results. I have changed around the assigned
> MAC address's in the simh ini files, swapped switch ports. Running out
> of idea's here. I have Wireshark on one of the Pi's but have no
> experience using it. Guess I better learn.
Remember, DECnet (assuming Phase IV) is going to change the MAC address
to one derived from the assigned DECnet address. The DECnet address
should also match SCSSYSTEMID, although I believe it will complain if
they don't.
Unique MAC addresses in the SIMH config prevent multiple nodes from
clashing with each other before DECnet starts, as well as confusing the
switche(s) that the nodes are connected to.
> On Friday, September 5, 2025 at 02:10:04 PM EDT, Johnny Billquist
> <bqt(a)softjar.se> wrote:
>
> I would probably guess at a problem with the actual MAC address used by
> that MicroVMS system, but it's pretty hard to troubleshoot this
> remotely.
>
> But it's very clear that all the other nodes are not seeing 31.282 as
> up, and so any communication will be failing.
>
> Other possible problems could be if the connection to the outside
> network is actually configured differently on this instance than the
> others, for example.
>
> Trying to think of other possible problems it could be. Maybe posting
> the simh config for the failing machine, as well as for one working,
> could be helpful.
>
> Johnny
>
> On 2025-09-05 20:04, Johnny Billquist wrote:
>> I've seen issues sometimes, but I don't know the full extent of what
>> the
>> exact results might be.
>>
>> But don't matter. Now we know they are all simh instances.
>>
>> Johnny
>>
>> On 2025-09-05 19:57, Paul Koning wrote:
>>> I thought SQE failure is only a warning and would not stop the device
>>> from working.
>>>
>>> pul
>>>
>>>> On Sep 5, 2025, at 1:27 PM, Johnny Billquist <bqt(a)softjar.se>wrote:
>>>>
>>>> That's one possibility. Another if he's running on some kind of
>>>> emulator on a system that don't actually allow programmatic change
>>>> of
>>>> the MAC address, and you need to set the MAC correctly in the
>>>> emulator before starting up. And if it is real hardware, is it
>>>> connected to some switch then?10baseT? Does he have an adapter that
>>>> can do SQE?
>>>>
>>>> There are many possible ways things could not work. What we can see
>>>> isjust that incoming broadcast/multicast packets work, but so far
>>>> nothing else.
>>>>
>>>> Johnny
>>>>
>>>> On 2025-09-05 19:22, Paul Koning wrote:
>>>>> Is it WiFi? That doesn't work with DECnet MAC addresses (it
>>>>> doesn't
>>>>> like it when the NIC changes its address to aa-00-04-00-xx-yy).
>>>>> paul
>>>>>> On Sep 5, 2025, at 1:14 PM, Johnny Billquist <bqt(a)softjar.se>
>>>>>> wrote:
>>>>>>
>>>>>> Well, GEEZER (31.278) is not seeing 31.282 as up. So that's why
>>>>>> you
>>>>>> have a problem. This usually means that packets are working in one
>>>>>> direction, but not the other.
>>>>>>
>>>>>> Was this a real machine? How have you connected it to the rest of
>>>>>> the network?
>>>>>>
>>>>>> Johnny
>>>>>>
>>>>>> On 2025-09-05 18:45, Brian Roth wrote:
>>>>>>> The address is 31.282. No File access, Phone or NCP Tell to other
>>>>>>> nodes but it is still able to go out and find a router. It
>>>>>>> (31.282) can phone itself and set host but other nodes it just
>>>>>>> hangs. If I phone anothernode it will just sit at "Establishing
>>>>>>> Decnet Link and then error to "Node is not reachable.
>>>>>>> Brian.
>>>>>>> On Friday, September 5, 2025 at 12:38:11 PM EDT, Johnny Billquist
>>>>>>> <bqt(a)softjar.se <mailto:bqt@softjar.se>> wrote:
>>>>>>> No. Qbus ethernet or Unibus ethernet makes no difference here.
>>>>>>> Does anything else work? NCP to other nodes? Phone? File access?
>>>>>>> What's the address of that microvax?
>>>>>>> Johnny
>>>>>>> On 2025-09-05 17:59, Brian Roth wrote:
>>>>>>>> Hello, I currently have 8 simh vax machines on Hecnet all
>>>>>>>> working
>>>>>>>> fine.
>>>>>>>> Its a mix of machines running VMS 3.5 to 7.3 and while some were
>>>>>>>> abit
>>>>>>>> of a challenge they all talk. I recently configured a Microvax
>>>>>>>> II
>>>>>>>> with
>>>>>>>> MicroVMS 4.6 as well as Decnet 4.6 and assigned it to my area
>>>>>>>> 31.
>>>>>>>> The
>>>>>>>> network loads without errors and I am able to SET HOST to itself
>>>>>>>> butto
>>>>>>>> no other nodes in my area or vice versa. SHOW KNOWN CIRCUITS
>>>>>>>> showsthe
>>>>>>>> hosts I manually defined. SHOW KNOWN CIRCUITS CHARACTERISTICS
>>>>>>>> showsa
>>>>>>>> designated router in my area so its finding that. If I bring a
>>>>>>>> router
>>>>>>>> node down it successfully finds another in the area.
>>>>>>>>
>>>>>>>> The microvax node:
>>>>>>>>
>>>>>>>> Known Circuit Volatile Characteristics as of 5-SEP-1987
>>>>>>>> 11:37:16
>>>>>>>>
>>>>>>>> Circuit = QNA-0
>>>>>>>>
>>>>>>>> State = on
>>>>>>>> Service = disabled
>>>>>>>> Designated router = 31.278
>>>>>>>> Cost =4
>>>>>>>> Router priority =64
>>>>>>>> Hello timer = 15
>>>>>>>> Type = Ethernet
>>>>>>>> Adjacent node =31.278
>>>>>>>> Listen timer = 45
>>>>>>>>
>>>>>>>> The working nodes match with the exception of the circuit. All
>>>>>>>> theother
>>>>>>>> machines are UNA-0 (UNIBUS) and this one is of course QNA-0
>>>>>>>> Couldthis
>>>>>>>> be the problem?
>>>>>>>>
>>>>>>>> Brian.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> HECnet mailing list --hecnet(a)lists.dfupdate.se
>>>>>>>> <mailto:hecnet@lists.dfupdate.se><mailto:hecnet@lists.dfupdate.se
>>>>>>>> <mailto:hecnet@lists.dfupdate.se>>
>>>>>>>> To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
>>>>>>>> <mailto:hecnet-leave@lists.dfupdate.se><mailto:hecnet-
>>>>>>>> leave(a)lists.dfupdate.se <mailto:hecnet-leave@lists.dfupdate.se>>
>>>>>>> --
>>>>>>> Johnny Billquist || "I'm on a bus
>>>>>>> || on a psychedelic trip
>>>>>>> email:bqt@softjar.se
>>>>>>> <mailto:bqt@softjar.se><mailto:bqt@softjar.se
>>>>>>> <mailto:bqt@softjar.se>> || Reading murder books
>>>>>>> pdp is alive! || tryin' to stay hip" - B.
>>>>>>> Idol
>>>>>>> _______________________________________________
>>>>>>> HECnet mailing list --hecnet(a)lists.dfupdate.se
>>>>>>> <mailto:hecnet@lists.dfupdate.se><mailto:hecnet@lists.dfupdate.se
>>>>>>> <mailto:hecnet@lists.dfupdate.se>>
>>>>>>> To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
>>>>>>> <mailto:hecnet-leave@lists.dfupdate.se><mailto:hecnet-
>>>>>>> leave(a)lists.dfupdate.se<mailto:hecnet-leave@lists.dfupdate.se>>
>>>>>>> _______________________________________________
>>>>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>>> _______________________________________________
>>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>>
>>>> --
>>>> 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
>>>>
>>>> _______________________________________________
>>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>>
>>> _______________________________________________
>>> HECnet mailing list -- hecnet(a)lists.dfupdate.se
>>> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
>>
>
> --
> 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
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
Hello, I currently have 8 simh vax machines on Hecnet all working fine. Its a mix of machines running VMS 3.5 to 7.3 and while some were a bit of a challenge they all talk. I recently configured a Microvax II with MicroVMS 4.6 as well as Decnet 4.6 and assigned it to my area 31. The network loads without errors and I am able to SET HOST to itself but to no other nodes in my area or vice versa. SHOW KNOWN CIRCUITS shows the hosts I manually defined. SHOW KNOWN CIRCUITS CHARACTERISTICS shows a designated router in my area so its finding that. If I bring a router node down it successfully finds another in the area.
The microvax node:
Known Circuit Volatile Characteristics as of 5-SEP-1987 11:37:16
Circuit = QNA-0
State = on
Service = disabled
Designated router = 31.278
Cost = 4
Router priority = 64
Hello timer = 15
Type = Ethernet
Adjacent node = 31.278
Listen timer = 45
The working nodes match with the exception of the circuit. All the other machines are UNA-0 (UNIBUS) and this one is of course QNA-0 Could this be the problem?
Brian.
Hello,
We had a power outage last night and now bringing all my nodes back up I am getting "Error initializing Multinet datalink" to area 31 specifically Supratim Sanyal 31.3 PYRTR. I wanted to see if there was a circuit down before I start troubleshooting this.
Thanks,Brian.
Hi,
It’s been a long while.
Slightly off-topic but this is the best DEC group I am still part of so here goes…
A friend and I might well be about to rescue a pair of VAX 4000/500 systems. We aren’t sure how much we’ll be able to transport in one go but we have them earmarked at least.
Firstly are there any “gotchas” to look out for on these fridge-sized absolute units? I know little aside from what I’ve read in the DEC documentation so far.
Secondly, I am aware these are DSSI based systems. We aren’t sure if the owners will release the disks yet as they could insist on retaining them for data destruction. If we lose them are we completely shanghai’d? Are there and modern solutions for DSSI emulation around at non-stupendous (i.e. hobbyist) prices?
If we need to net-boot them the what’s the skinny on that? I think you can do it using a SimH VAX and some clustering magic IIRC?
All help is greatly appreciated. If we get these I want to put a big effort into saving them and getting them running. I will need a lot of help as I am not at all well versed in VAX hardware.
Thanks!
As some people have noticed the last few months, MIM have been difficult
to reach.
It has come to the point where I just have to move the machine to a new
place, as I'm not having much success solving the current situation.
For people who maybe don't know, Mim is a PDP-11/74 (simulated) which
runs RSX-11M+. It is kindof a hub for Hecnet, as well as a resource for
anyone who wants to find documentation or information about RSX, and
also to find various software for RSX.
I will move Mim this weekend, and so it will be down for a while.
Hopefully this will be a fairly smooth operation, but I'll let people
know when it's going on, and my expectation is that it shouldn't be more
than a couple of hours.
Mim will also change address and name because of this. The new address
to reach Mim on will be Mim.SoftJAR.SE. This name should be stable for
the forseeable future. Physically Mim will move from Sweden to the US
east cost, and be living at LSSM. A big thank you to LSSM and Dave
McGuire in particular for helping out with resources for this.
In practice, for everyone else, once the move is done, it means that:
. Any reference to Mim.Stupi.NET needs to be changed to Mim.SoftJAR.SE.
. Any multinet circuits connecting to Mim should adjust their costs. See
the HECnet information page on Mim about this.
. I will also create a new PyDECnet node at LSSM to act as another
connection point for people who might not be able to connect to
hecnet-1-1023.stupi.net, but which are still in area 1.
. hecnet-1-1023.stupi.net will still be around, and will still be
possible to use.
This do mean that area 1 will be more geographically spread out. Not
ideal, but I'm not expecting this to cause any major issues. Performance
for some might get a bit better or worse, depending on various aspects
and conditions. But in general, if people just keep costs aligned with
recommendations, things should work well.
Best regards,
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
And now I see what you guys were/are doing.
You're trying to use https. I don't have any https server, and when you
try that, you are essentially repeatedly hitting a port that do not
provide any service, and eventually you get blocked.
Stop trying to use https against Mim. :-D
Johnny
On 2025-07-29 20:46, Wilm Boerhout wrote:
> I was out too doing some garden work...
>
> Just cleared my cache and revisited mim.softjar.se -- no response, eventually timed out with "server took too long to respond" or such (translated from Dutch)
>
> -----Original Message-----
> From: Johnny Billquist <bqt(a)softjar.se>
> Sent: Tuesday, July 29, 2025 7:08 PM
> To: Wilm Boerhout <wboerhout(a)mailbox.org>
> Subject: Re: [simh] MIM move...
>
> Yeah, you're also blocked.
>
> I was out for a few hours. I'll lift your block now, and you can try again, and I'll have some stuff captured that should allow me to understand what is triggering it.
>
> Johnny
>
> On 2025-07-29 18:40, Wilm Boerhout wrote:
>> Johnny,
>>
>> The DECnet circuit is still up without failure, but I too, get no response at all from the mim.softjar.se website. I'm using Firefox on Windows.
>>
>> My external IP is 95.98.255.226 (odsw48.mywire.org)
>>
>> Wilm
>>
>> -----Original Message-----
>> From: simh(a)groups.io <simh(a)groups.io> On Behalf Of Johnny Billquist
>> via groups.io
>> Sent: Friday, July 25, 2025 6:35 PM
>> To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>;
>> [PiDP-11] <pidp-11(a)googlegroups.com>; simh(a)groups.io;
>> Info-PDP11(a)dbit.com
>> Subject: [simh] MIM move...
>>
>> As some people have noticed the last few months, MIM have been difficult to reach.
>> It has come to the point where I just have to move the machine to a new place, as I'm not having much success solving the current situation.
>>
>> For people who maybe don't know, Mim is a PDP-11/74 (simulated) which runs RSX-11M+. It is kindof a hub for Hecnet, as well as a resource for anyone who wants to find documentation or information about RSX, and also to find various software for RSX.
>>
>> I will move Mim this weekend, and so it will be down for a while.
>> Hopefully this will be a fairly smooth operation, but I'll let people know when it's going on, and my expectation is that it shouldn't be more than a couple of hours.
>>
>> Mim will also change address and name because of this. The new address to reach Mim on will be Mim.SoftJAR.SE. This name should be stable for the forseeable future. Physically Mim will move from Sweden to the US east cost, and be living at LSSM. A big thank you to LSSM and Dave McGuire in particular for helping out with resources for this.
>>
>> In practice, for everyone else, once the move is done, it means that:
>>
>> . Any reference to Mim.Stupi.NET needs to be changed to Mim.SoftJAR.SE.
>>
>> . Any multinet circuits connecting to Mim should adjust their costs. See the HECnet information page on Mim about this.
>>
>> . I will also create a new PyDECnet node at LSSM to act as another connection point for people who might not be able to connect to hecnet-1-1023.stupi.net, but which are still in area 1.
>>
>> . hecnet-1-1023.stupi.net will still be around, and will still be possible to use.
>>
>>
>> This do mean that area 1 will be more geographically spread out. Not
>> ideal, but I'm not expecting this to cause any major issues.
>> Performance for some might get a bit better or worse, depending on
>> various aspects and conditions. But in general, if people just keep
>> costs aligned with recommendations, things should work well.
>>
>> Best regards,
>> 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
