Thanks. Done that one, as well as A54RTR.
Johnny
On 2012-06-11 16:01, hvlems at zonnet.nl wrote:
Johnny, 44.1023 has a new name so it fits in with current standards: A44RTR
Hans
------Origineel bericht------
Van: Johnny Billquist
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] New Nodes on Area 6
Verzonden: 11 juni 2012 15:49
On 2012-06-11 15:06, Mark Benson wrote:
I notice that there are a bunch of nodes seen from MIM that I don't know about right now... Others... 'fess up. ;-)
What, in Area 6 or just generally?
Sorry. In general. :)
5.101, 7.72, 7.90, 22.594 are the ones that I've seen on MIM recently...
Johnny
On 11 Jun 2012, at 14:49, Mark Wickens <mark at wickensonline.co.uk> wrote:
After a lot of messing to do with networking (am now using a USB network stick as a 2nd ethernet controller dedicated to the SIMH VAX instance) I have an emulated VAX on the PI:
Didn't bother with a second NIC on mine, it gives my router a headache
having one machine at 2 separate hardware MAC addresses. I'm sure I
could get around that in Linux but ultimately I couldn't be bothered.
I can talk to it locally via the OP console on screen pr remotely by
the DZ11 emulation or telnet.
msw at hpm:~$ telnet pivax
You can't use PIVAX as a node name, all my cluster nodes are all set
to be PIVAX1 to PIVAXn :P
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Johnny, 44.1023 has a new name so it fits in with current standards: A44RTR
Hans
------Origineel bericht------
Van: Johnny Billquist
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] New Nodes on Area 6
Verzonden: 11 juni 2012 15:49
On 2012-06-11 15:06, Mark Benson wrote:
I notice that there are a bunch of nodes seen from MIM that I don't know about right now... Others... 'fess up. ;-)
What, in Area 6 or just generally?
Sorry. In general. :)
5.101, 7.72, 7.90, 22.594 are the ones that I've seen on MIM recently...
Johnny
I notice that there are a bunch of nodes seen from MIM that I don't know
about right now... Others... 'fess up. ;-)
Well, there is:
54.100 A54RTR (Cisco IGS)
which is testing a GRE tunnel link for rather longer than I thought it would.
Regards,
Peter Coghlan.
On 2012-06-11 15:06, Mark Benson wrote:
I notice that there are a bunch of nodes seen from MIM that I don't know about right now... Others... 'fess up. ;-)
What, in Area 6 or just generally?
Sorry. In general. :)
5.101, 7.72, 7.90, 22.594 are the ones that I've seen on MIM recently...
Johnny
After a lot of messing to do with networking (am now using a USB network stick as a 2nd ethernet controller dedicated to the SIMH VAX instance) I have an emulated VAX on the PI:
msw at hpm:~$ telnet pivax
Trying 192.168.1.194...
Connected to pivax.hecnet.eu.
Escape character is '^]'.
Welcome to OpenVMS (TM) VAX Operating System, Version V7.3
Username: system
Password:
Welcome to OpenVMS (TM) VAX Operating System, Version V7.3
Last interactive login on Monday, 11-JUN-2012 13:51
--
http://www.wickensonline.co.ukhttp://declegacy.org.uk
I notice that there are a bunch of nodes seen from MIM that I don't know about right now... Others... 'fess up. ;-)
What, in Area 6 or just generally?
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 2012-06-09 23:13, Mark Benson wrote:
As per subject:
6.3 ITANIC (OpenVMS 8.4 I64)
6.11 BGATES (Windows XP Pro / Pathworks32)
Done. Thanks.
I notice that there are a bunch of nodes seen from MIM that I don't know about right now... Others... 'fess up. ;-)
Johnny
On 11 Jun 2012, at 12:24, Mark Wickens <mark at wickensonline.co.uk> wrote:
My comments are probably completely useless, but I'll say it anyway.
I've seen this behaviour in a box with multiple network adapters where one (or more) are not connected to a network segment.
Yes, the same happened to me when I installed OpenVMS on my Integrity
box with GBit connected and not the 10/100 MBit. However if it's not
connected on a LAN it does it every 10-30 seconds. It was so annoying
I purged the EIW-0 circuit on mine (probably never use it for DECnet
in the native OS anyway).
If it is indeed the same behaviour then it's possibly a break in the
tunnel link, the timeouts seem to be pretty strict.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On Fri, 08 Jun 2012 21:46:26 +0200, you wrote:
1) Defining the permanent node database for both TOPS10 and TOPS20. NCP
rejects the DEFINE NODE commands. I guess there is some sort of utility
like the one in RSX (CFE) to define the "permanent" node list, but I've
not been able to find that one. There is a NIPGEN in TOPS-10 to build a
CMD file with the SET NODE commands, but no NIPGEN in TOPS-20 that I've
been able to find...
Please, note that I'm really not versed in TOPS-20 configurations so I shall
write about TOPS-10 only. :)
As Peter Lothberg has already pointed out, there is no permanent database in
TOPS-10 DECnet, but just the volatile one that has to be reloaded after every
reboot. If I'm not wrong, NIPGEN was used only when setting up front-end-based
DECnet, i.e. DDCMP links and such, but not Ethernet. The official way to pass
node definitions to NCP should be to feed it with a SET NODE command for every
node to be defined, but that would be noticeably slow, in particular with long
node lists. So NODNAM was born, which uses a faster method to load the DECnet
database reading from INI:NODNAM.INI, and then optionally starts MX.
If your INI: device points to a non-existant [5,34] directory, you may use
CREDIR to create it, like this:
| .R CREDIR
| Create directory: INI:
| Created DSKB1:[5,34].UFD/PROTECTION:775
| Create directory: ^Z
Then, to have NODNAM automatically started by the monitor, just add NODNAM at
the end of SYS:SYSJOB.INI without preceding it with LOG (or LOGIN). That's
because NODNAM does not "stick" but starts, does its thing, then exits.
More details can be found in NODNAM.HLP:
http://pdp-10.trailing-edge.com/tops10_tools_bb-fp64b-sb/01/10,7/decnet/nod…
2) LAT. LAT works fine in TOPS-20. In TOPS-10 LCP tells me LAT is
active, but it does not work (does not even announce itself). How do I
enable LAT in TOPS-10?
Well, I'm using a homemade LAT-enabled monitor and I have the following in my
SYS:SYSTEM.CMD file (among other things):
| LCP SET GROUPS 0
| LCP SET SERVICE-NAME xxxxxx /RATING: DYNAMIC
| LCP SET SERVICE-NAME xxxxxx /IDENT: "Xxxxxx blah blah blah"
| LCP START
Moreover, I had to modify SYS:TTY.INI like this:
| ALL: KSYS CHECK:DEFAULT NORUN TEXT NONOTICE EDITOR
| CTY: GALOPR NOREMOTE ACCOUNT:"SYSTEM"
| APC:LAT NOCHECK TYPE:VT100
| STOMP ACCOUNT:"SYSTEM"
(Notice the NORUN parameter!)
4) A few minutes after startup of TOPS-10. I get the following message
at the console:
CCPOEF Output error on DSKB:SER001.EXE[10,1], status=40017
It does not seem to have any advert effect, but I'd like to know what's
wrong. I've not seen such a message in my KS-based TOPS-10 running under
SIMH.
That message is from the crash dump copy program (CRSCPY, message prefix CCP).
Whenever the monitor crashes and is reloaded or encounters a continuable error
for which a memory dump is taken, it then calls CRSCPY to copy the dump from
SYS:CRASH.EXE to XPN:xxxxxx.EXE (XPN: is [10,1]). The first three characters
of the copied dump file are the stopcode for which the dump was taken or SER
if the stopcode is not available or is a six-character stopcode.
Status 40017 might be "Block too large" (I'm not sure at all): a quick lookup
in alt.sys.pdp10 suggests that CRSCPY may complain with that message when some
filesystem parameters are not sized as expected.
Anyway you'd still have to discover why your monitor has crashed... You can
see a log of your dumps by running CRSCPY interactively and giving it the
REPORT command at the CRSCPY> prompt.
HTH,
G.
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens
Sent: Monday, June 11, 2012 07:24
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] netowrk flapping....
On 10/06/12 21:53, Marc Chametzky wrote:
I have increased the timeout values on the router that is
attached
to SG1::. Hopefully this improves matters.
I may have missed something, but I saw that you increased the TCP
timeouts. By default, DECnet-over-IP uses UDP packets, so that'd be
the timeout you'd want to increase.
The uplink port is a gigabit port connected to my FiOS ONT
(connected at
100 Mbps).
What does it speak to the fios NT (I knew nothing about
what strange
things local phone compnies manage to do..) Is it just DHCP or
exoting things like pppoe?
The ONT simply presents itself as a regular, routed
100Base-TX network
interface. There's no special protocol used between the
SonicWALL and
the ONT. The SonicWALL specifies 71.182.147.1 as its default route,
which is either the ONT itself or something upstream from
it. I don't
know where the fiber's IP router actually lives.
I have five static IP addresses that I manually configure,
so I'm not
using DHCP on my WAN segment.
Now, getting back to the UDP versus TCP, MultiNet does
support setting
up DECnet circuits using TCP. It's not available via MULTINET
CONFIGURE/DECNET from what I could see, but it is listed in
the online
help for MULTINET SET/DECNET as /TCP=[CONNECT|LISTEN]. TCP
connections
may prove to be more reliable under some circumstances.
--Marc
My comments are probably completely useless, but I'll say it anyway.
I've seen this behaviour in a box with multiple network
adapters where one (or more) are not connected to a network segment.
Mark.
--
http://www.wickensonline.co.ukhttp://declegacy.org.uk
SG1:: only has 1 adapter. It is a VAXstation 4000-30 (VLC). It is
connected directly to the Netgear FVS318.
-Steve
On 10/06/12 21:53, Marc Chametzky wrote:
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
I may have missed something, but I saw that you increased the TCP timeouts. By default, DECnet-over-IP uses UDP packets, so that'd be the timeout you'd want to increase.
> The uplink port is a gigabit port connected to my FiOS ONT (connected at
> 100 Mbps).
What does it speak to the fios NT (I knew nothing about what strange
things local phone compnies manage to do..) Is it just DHCP or exoting
things like pppoe?
The ONT simply presents itself as a regular, routed 100Base-TX network interface. There's no special protocol used between the SonicWALL and the ONT. The SonicWALL specifies 71.182.147.1 as its default route, which is either the ONT itself or something upstream from it. I don't know where the fiber's IP router actually lives.
I have five static IP addresses that I manually configure, so I'm not using DHCP on my WAN segment.
Now, getting back to the UDP versus TCP, MultiNet does support setting up DECnet circuits using TCP. It's not available via MULTINET CONFIGURE/DECNET from what I could see, but it is listed in the online help for MULTINET SET/DECNET as /TCP=[CONNECT|LISTEN]. TCP connections may prove to be more reliable under some circumstances.
--Marc
My comments are probably completely useless, but I'll say it anyway.
I've seen this behaviour in a box with multiple network adapters where one (or more) are not connected to a network segment.
Mark.
--
http://www.wickensonline.co.ukhttp://declegacy.org.uk
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
I may have missed something, but I saw that you increased the TCP timeouts. By default, DECnet-over-IP uses UDP packets, so that'd be the timeout you'd want to increase.
> The uplink port is a gigabit port connected to my FiOS ONT (connected at
> 100 Mbps).
What does it speak to the fios NT (I knew nothing about what strange
things local phone compnies manage to do..) Is it just DHCP or exoting
things like pppoe?
The ONT simply presents itself as a regular, routed 100Base-TX network interface. There's no special protocol used between the SonicWALL and the ONT. The SonicWALL specifies 71.182.147.1 as its default route, which is either the ONT itself or something upstream from it. I don't know where the fiber's IP router actually lives.
I have five static IP addresses that I manually configure, so I'm not using DHCP on my WAN segment.
Now, getting back to the UDP versus TCP, MultiNet does support setting up DECnet circuits using TCP. It's not available via MULTINET CONFIGURE/DECNET from what I could see, but it is listed in the online help for MULTINET SET/DECNET as /TCP=[CONNECT|LISTEN]. TCP connections may prove to be more reliable under some circumstances.
--Marc
I'm still seeing issues with STUPI:: though...
The other Multinet Tunnel connections seem to be quiet (for now...).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong
Sent: Sunday, June 10, 2012 12:08
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
... considering creating a static route to your end and to Sampsa's
end because those constitute the US backbone into Europe.
I'm not quite sure what you have in mind - in the FVS338 I
already have an inbound rule that forwards all inbound UDP
packets addressed to 64.142.52.93:700 (that's the WAN address
of decnet.jfcl.com) to 10.1.1.13:700 (that's the IP of LEGATO
on my internal network). I think that's as much of a static
route as is possible in this case.
So far, SG1 hasn't "flapped" since 7:28AM PDT.
Bob
The timeout is currently set to 2 billion seconds. This "should" not be
a problem for most people. :-)
I may reduce it to a week if this timeout causes me any grief.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Peter Lothberg
Sent: Sunday, June 10, 2012 17:02
To: hecnet at Update.UU.SE
Cc: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
I have increased the timeout values on the router that is
attached to
SG1::. Hopefully this improves matters.
Can you make the timer multiple days or weeks?
(Anyone trying to use HECnet traveling over that link will be very
frustrated....)
-P
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
Can you make the timer multiple days or weeks?
(Anyone trying to use HECnet traveling over that link will be very
frustrated....)
-P
... considering creating a static route to your end and to Sampsa's
end because those constitute the US backbone into Europe.
I'm not quite sure what you have in mind - in the FVS338 I already have an
inbound rule that forwards all inbound UDP packets addressed to
64.142.52.93:700 (that's the WAN address of decnet.jfcl.com) to
10.1.1.13:700 (that's the IP of LEGATO on my internal network). I think
that's as much of a static route as is possible in this case.
So far, SG1 hasn't "flapped" since 7:28AM PDT.
Bob
Bob,
I have the 318 - the little brother of the 338. I adjusted the TCP
timeout value (default 600 seconds). I did not touch the UDP time value
(default 75 seconds). I set the TCP timeout to the max value. If it
causes other issues I will back it off as necessary.
I was considering creating a static route to your end and to Sampsa's
end because those constitute the US backbone into Europe. I may still
do that. You might want to consider it as well. IF we do it at the
same time who knows how much better things can become. :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong
Sent: Sunday, June 10, 2012 11:00
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
Steve -
You said you have an FVS338, right? Which timeout values
on which setup screen did you change?
I want to check my FVS338 to see how it's set.
BTW, you did define (under Security >> Services) a service
for UDP 700, right? And then under Security >> Firewall, you
added incoming and outgoing rules for that service ?
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Steve Davidson
Sent: Sunday, June 10, 2012 7:45 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
I have increased the timeout values on the router that is
attached to SG1::.
Hopefully this improves matters.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Sunday, June 10, 2012 03:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] netowrk flapping....
Bob, on A44RTR is see SG1 flapping as well. After breakfast
I'll see
whether there is a pattern. Initially I thought it was the linux
laptop going to sleep after a whule. That may not be the case.
Hans
------Origineel bericht------
Van: Bob Armstrong
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] netowrk flapping....
Verzonden: 10 juni 2012 01:32
Yup, that's basically a deficiency I've got...
Yeah, but the next question is "Are you the only one", or
do other
people's routers have similar timeout issues?
Bob
Steve -
You said you have an FVS338, right? Which timeout values on which setup
screen did you change?
I want to check my FVS338 to see how it's set.
BTW, you did define (under Security >> Services) a service for UDP 700,
right? And then under Security >> Firewall, you added incoming and outgoing
rules for that service ?
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Steve Davidson
Sent: Sunday, June 10, 2012 7:45 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] netowrk flapping....
I have increased the timeout values on the router that is attached to SG1::.
Hopefully this improves matters.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Sunday, June 10, 2012 03:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] netowrk flapping....
Bob, on A44RTR is see SG1 flapping as well. After breakfast I'll see
whether there is a pattern. Initially I thought it was the linux
laptop going to sleep after a whule. That may not be the case.
Hans
------Origineel bericht------
Van: Bob Armstrong
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] netowrk flapping....
Verzonden: 10 juni 2012 01:32
Yup, that's basically a deficiency I've got...
Yeah, but the next question is "Are you the only one", or do other
people's routers have similar timeout issues?
Bob
I have increased the timeout values on the router that is attached to
SG1::. Hopefully this improves matters.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Sunday, June 10, 2012 03:08
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] netowrk flapping....
Bob, on A44RTR is see SG1 flapping as well. After breakfast
I'll see whether there is a pattern. Initially I thought it
was the linux laptop going to sleep after a whule. That may
not be the case.
Hans
------Origineel bericht------
Van: Bob Armstrong
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] netowrk flapping....
Verzonden: 10 juni 2012 01:32
Yup, that's basically a deficiency I've got...
Yeah, but the next question is "Are you the only one", or
do other people's routers have similar timeout issues?
Bob
.
BUT IT'S SO SHINY!
It isn't when unplugging a USB device crashes the OS AGAIN... but I digress.
That never happened to me... I've experienced Finder freezes when an USB/FW device fails... But usually a finder restart fixes it.
Anyway, MacOS is (more) unix cr*p. It's just the best smelling cr*p you can get right now ;)
On 10 Jun 2012, at 09:48, Sampsa Laine wrote:
On 10 Jun 2012, at 09:37, Mark Benson wrote:
I don't know of any for OS X either, it's not exactly and OS that exudes support for legacy systems.
BUT IT'S SO SHINY!
It isn't when unplugging a USB device crashes the OS AGAIN... but I digress.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 10 Jun 2012, at 09:37, Mark Benson wrote:
I don't know of any for OS X either, it's not exactly and OS that exudes support for legacy systems.
BUT IT'S SO SHINY!
On 10 Jun 2012, at 07:59, Dave McGuire wrote:
On 06/08/2012 11:08 AM, Gregg Levine wrote:
At one point in time, the OS for the Mac did speak natively to the DEC
family of hardware. It would be very interesting to find out how they
did it. This would greatly benefit Sampsa at least.
Yes, but *which one*? The "original" MacOS bears no resemblance to,
and shares no code with, the current UNIX-based OS. I know of no
MacOS-X-based DECnet implementations. (sadly)
I think we established it was Classic Mac OS and was likely using TSSnet or PWMac :)
I don't know of any for OS X either, it's not exactly and OS that exudes support for legacy systems.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
