I am mainly reading the mail list.. It';s interesting but at this time I have no ability to participate. There is a VMS box, but no way to connect it to HECNET. So keep up the good work.
thanks,
Patrick Jankowiak
Steve Davidson wrote:
Hi,
I was wondering what use everyone is making of HECnet. My environment (DECnet area 19) has just come up. Johnny and I have done simple tests and everything that we have tried so far seems to work quite well.
Comments?
Thanks,
-Steve Davidson
Hollis, NH USA
Paul Koning wrote:
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
gerry> We still do not know how these UDP related problems would/will
gerry> impact other protocols like LAT, LAD/LAST and MOP because we
gerry> haven't experimented so much as with pure DECnet. Any
gerry> contribution and suggestions on how to force reduced frame
gerry> size for those protocols would be much appreciated. :-)
>> I can't think of any. The general rule at DEC was that some basic
>> level of design competence was assumed. Getting the Ethernet
>> frame size right was certainly part of the basic IQ test.
>> >> The only solution I can think of is to reduce the MTU of your
>> local Ethernet on the machine doing the UDP encapsulation. That
>> would force the packets to be fragmented at origination time,
>> which means your defective routers will see small-enough packets.
Johnny> If I suspect right, that won't solve it. I haven't any
Johnny> direct experience with these kind of problems, but the few
Johnny> cases that I'm semi-aware of are actually of
Johnny> bridges/gateways/routers that can't handled IP
Johnny> fragments. Forcing a fragment even earlier won't help.
Oh. I thought the issue was that those "routers" couldn't do
fragmentation right.
It could be. As I said, I'm just "guessing".
If the problem is that they look at the header to see if it's
fragmented -- which is something they should not care about -- and
then proceed to get confused, then indeed they are beyond all hope and
the only solution is to scrap them and get real routers.
Well, the problem with policy based firewalls/routers is that they inspect more (in fact, they have to) than the IP header. And some of them are too stupid to deal with fragments.
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
"Johnny" == Johnny Billquist <bqt at softjar.se> writes:
gerry> We still do not know how these UDP related problems would/will
gerry> impact other protocols like LAT, LAD/LAST and MOP because we
gerry> haven't experimented so much as with pure DECnet. Any
gerry> contribution and suggestions on how to force reduced frame
gerry> size for those protocols would be much appreciated. :-)
I can't think of any. The general rule at DEC was that some basic
level of design competence was assumed. Getting the Ethernet
frame size right was certainly part of the basic IQ test.
The only solution I can think of is to reduce the MTU of your
local Ethernet on the machine doing the UDP encapsulation. That
would force the packets to be fragmented at origination time,
which means your defective routers will see small-enough packets.
Johnny> If I suspect right, that won't solve it. I haven't any
Johnny> direct experience with these kind of problems, but the few
Johnny> cases that I'm semi-aware of are actually of
Johnny> bridges/gateways/routers that can't handled IP
Johnny> fragments. Forcing a fragment even earlier won't help.
Oh. I thought the issue was that those "routers" couldn't do
fragmentation right.
If the problem is that they look at the header to see if it's
fragmented -- which is something they should not care about -- and
then proceed to get confused, then indeed they are beyond all hope and
the only solution is to scrap them and get real routers.
paul
Paul Koning wrote:
"gerry" == gerry <gerry77 at mail.com> writes:
gerry> Really, we [1] had some problems with fragmented UDP packets,
gerry> mostly due to some cheap IP routers bundled with local ADSL
gerry> connections. Many of them seem to be unable to correctly
gerry> manage UDP fragments and/or have memory leaks which in the end
gerry> cause lockups and other nasty things after some DECnet-in-UDP
gerry> traffic has passed thru them. In at least one case, the
gerry> problem was even nailed down to some ISP apparatus sitting
gerry> between two remote bridges of ours.
Yikes.
Yeah. "Yikes" is a good word for it.
gerry> We still do not know how these UDP related problems would/will
gerry> impact other protocols like LAT, LAD/LAST and MOP because we
gerry> haven't experimented so much as with pure DECnet. Any
gerry> contribution and suggestions on how to force reduced frame
gerry> size for those protocols would be much appreciated. :-)
I can't think of any. The general rule at DEC was that some basic
level of design competence was assumed. Getting the Ethernet frame
size right was certainly part of the basic IQ test.
The only solution I can think of is to reduce the MTU of your local
Ethernet on the machine doing the UDP encapsulation. That would force
the packets to be fragmented at origination time, which means your
defective routers will see small-enough packets.
If I suspect right, that won't solve it.
I haven't any direct experience with these kind of problems, but the few cases that I'm semi-aware of are actually of bridges/gateways/routers that can't handled IP fragments. Forcing a fragment even earlier won't help.
And the problem stems from the fact that these stupid products look at the head of the packet to make some "intelligent" decision. However, in a fragmented packet, only the first packet have the header of the encapsulated protocol.
So, for UDP, only the first IP fragment have the UDP header. Any of the other fragments don't. And stupid firewalls then get really confused, because they can't deal with this.
A correct firewall will atleast remember the source and destination IP, along with the identification field of the packet, along with the decision taken for the first fragment. And then it takes the same decision for all the other fragments belonging to the same packet.
That is still not perfect, but it's usually "good enough".
The only way to avoid the problem, if you have one of those stupid products, is either to make sure all your frames are small enough to fit in inside a normal packet, or make the MTU larger.
The first is what gerry have done for DECnet. The latter is what you might do with jumbo ethernet frames. However, if you run packets to non-local destinations, you'll probably still end up with fragmented packets.
So my only solution is to get better hardware that can deal with IP fragmentation.
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
"gerry" == gerry <gerry77 at mail.com> writes:
gerry> Really, we [1] had some problems with fragmented UDP packets,
gerry> mostly due to some cheap IP routers bundled with local ADSL
gerry> connections. Many of them seem to be unable to correctly
gerry> manage UDP fragments and/or have memory leaks which in the end
gerry> cause lockups and other nasty things after some DECnet-in-UDP
gerry> traffic has passed thru them. In at least one case, the
gerry> problem was even nailed down to some ISP apparatus sitting
gerry> between two remote bridges of ours.
Yikes.
gerry> We still do not know how these UDP related problems would/will
gerry> impact other protocols like LAT, LAD/LAST and MOP because we
gerry> haven't experimented so much as with pure DECnet. Any
gerry> contribution and suggestions on how to force reduced frame
gerry> size for those protocols would be much appreciated. :-)
I can't think of any. The general rule at DEC was that some basic
level of design competence was assumed. Getting the Ethernet frame
size right was certainly part of the basic IQ test.
The only solution I can think of is to reduce the MTU of your local
Ethernet on the machine doing the UDP encapsulation. That would force
the packets to be fragmented at origination time, which means your
defective routers will see small-enough packets.
paul
I still prefer EDT. :-)
(Well, unless I have some Emacs around...)
Johnny
Steve Davidson wrote:
Close...
You will need to use SYS$MANAGER:NETCONFIG.COM. Afterwards, assuming a reasonably current version of VMS (the Open is silent :-)), you modify SYS$MANAGER:SYSTARTUP_VMS.COM to enable SYS$MANAGER:STARTNET.COM - just remove the comment. In these cases, SYS$MANAGER actually resolves to SYS$COMMON:[SYSMGR] but you'll see that. This is a chance to get reacquainted to your old friend EDT, or use the "new" kid on the block - TPU. The only reason I plugged EDT is once upon a time I was the project leader...
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Kari Uusim ki
Sent: Friday, February 27, 2009 00:38
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] What use are *you* making of HECnet?
Johnny Billquist wrote:
Jason Stevens wrote:
I see... yeah I have a VMS image, but really no idea how to setup it's
networking... I 'used' VMS as a user ages ago, although it was mostly
using EDT and fighting the gold key thing on terminals....
Anyways is there some online docs on setting up VMS's networking? I'd
love to be able to dig deeper into this....
The good thing is that playing around like this is really the best way of learning. And I think you should play more. I might be wrong, so don't take anything I write as the gospel. :-)
As for docs... Well, the full documentation for VMS is available online at HP, if you can live with fairly recent documentation.
But I seem to remember that it wasn't that difficult to get it running. I think there is a script you run to set things up, and after you've run that, you're basically set.
Quite right. Setting DECnet (Phase IV) up on a VMS machine is really simple. You have to decide your DECnet address and whether your machine is an end node or a router (L1 or L2). The script will ask all the necessary questions. You run it as follows:
$ @netconfigure.com
Further on you'll start it by running:
$ @startnet.com
Kari
But I know I'm very vague here. Better to wait for someone else to answer, perhaps. I know myself around VMS, and have been working with it on and off for over 20 years, but I'm really more familiar with RSX these days, and have to experiment a bit every time I set down with VMS before I remember how you're supposed to do it there. :-)
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
Close...
You will need to use SYS$MANAGER:NETCONFIG.COM. Afterwards, assuming a reasonably current version of VMS (the Open is silent :-)), you modify SYS$MANAGER:SYSTARTUP_VMS.COM to enable SYS$MANAGER:STARTNET.COM - just remove the comment. In these cases, SYS$MANAGER actually resolves to SYS$COMMON:[SYSMGR] but you'll see that. This is a chance to get reacquainted to your old friend EDT, or use the "new" kid on the block - TPU. The only reason I plugged EDT is once upon a time I was the project leader...
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Kari Uusim ki
Sent: Friday, February 27, 2009 00:38
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] What use are *you* making of HECnet?
Johnny Billquist wrote:
Jason Stevens wrote:
I see... yeah I have a VMS image, but really no idea how to setup it's
networking... I 'used' VMS as a user ages ago, although it was mostly
using EDT and fighting the gold key thing on terminals....
Anyways is there some online docs on setting up VMS's networking? I'd
love to be able to dig deeper into this....
The good thing is that playing around like this is really the best way
of learning. And I think you should play more. I might be wrong, so
don't take anything I write as the gospel. :-)
As for docs... Well, the full documentation for VMS is available online
at HP, if you can live with fairly recent documentation.
But I seem to remember that it wasn't that difficult to get it running.
I think there is a script you run to set things up, and after you've run
that, you're basically set.
Quite right. Setting DECnet (Phase IV) up on a VMS machine is really
simple. You have to decide your DECnet address and whether your machine
is an end node or a router (L1 or L2). The script will ask all the
necessary questions. You run it as follows:
$ @netconfigure.com
Further on you'll start it by running:
$ @startnet.com
Kari
But I know I'm very vague here. Better to wait for someone else to
answer, perhaps. I know myself around VMS, and have been working with it
on and off for over 20 years, but I'm really more familiar with RSX
these days, and have to experiment a bit every time I set down with VMS
before I remember how you're supposed to do it there. :-)
Johnny
On Thu, 26 Feb 2009 14:19:35 +0100, you wrote:
As for fragmentation... Now I assume you are talking about the
encapsulation of ethernet packets in UDP packets. Those will be a bit
larger still, and will almost certainly be fragmented when sent over the
internet, yes. I don't see a problem with that. Do you?
Really, we [1] had some problems with fragmented UDP packets, mostly due to
some cheap IP routers bundled with local ADSL connections. Many of them seem
to be unable to correctly manage UDP fragments and/or have memory leaks which
in the end cause lockups and other nasty things after some DECnet-in-UDP
traffic has passed thru them. In at least one case, the problem was even
nailed down to some ISP apparatus sitting between two remote bridges of ours.
The most common symptom is a working connection (as long as it's used only for
interactive light traffic such as CTERM) which hangs when used for bulk data
transfers like file COPY. In one specific case, a system with a very complex
announce text (the one shown before login) was actually unreachable because
the contents of the announce were so large that they caused a fragmented UDP
packet to be sent, leading to a SET HOST hang without "Username:" prompt.
Our solution was to reduce the overall size of DECnet packets.
This is for the actual live DECnet (not permanent across network restarts):
$ MCR NCP SET CIRC SVA-0 STATE OFF
$ MCR NCP SET LINE SVA-0 STATE OFF
$ MCR NCP SET LINE SVA-0 BUFF SIZE 1456
$ MCR NCP SET LINE SVA-0 STATE ON
$ MCR NCP SET CIRC SVA-0 STATE ON
This to make it a permanent change:
$ MCR NCP DEF LINE SVA-0 BUFF SIZE 1456
The actual line/circuit name (SVA-0 in the above examples) can be seen with:
$ MCR NCP SHOW KNOWN LINE
$ MCR NCP SHOW KNOWN CIRC
The 1456 bytes value was chosen (after some trial-and-error with tcpdump) so
to have 1492 bytes long UDP packets, which is exactly the local MTU of our
ADSL links. One of us had to trim even more its buffer size, down to 1428. We
don't know why, but that was the biggest size he could use without incurring
in DECnet link hangs. The latter appears to be a ISP-side problem with UDP.
We still do not know how these UDP related problems would/will impact other
protocols like LAT, LAD/LAST and MOP because we haven't experimented so much
as with pure DECnet. Any contribution and suggestions on how to force reduced
frame size for those protocols would be much appreciated. :-)
Hope this helps,
G.
[1] http://decnet.ipv7.net/
Johnny Billquist wrote:
Jason Stevens wrote:
I see... yeah I have a VMS image, but really no idea how to setup it's
networking... I 'used' VMS as a user ages ago, although it was mostly
using EDT and fighting the gold key thing on terminals....
Anyways is there some online docs on setting up VMS's networking? I'd
love to be able to dig deeper into this....
The good thing is that playing around like this is really the best way of learning. And I think you should play more. I might be wrong, so don't take anything I write as the gospel. :-)
As for docs... Well, the full documentation for VMS is available online at HP, if you can live with fairly recent documentation.
But I seem to remember that it wasn't that difficult to get it running. I think there is a script you run to set things up, and after you've run that, you're basically set.
Quite right. Setting DECnet (Phase IV) up on a VMS machine is really simple. You have to decide your DECnet address and whether your machine is an end node or a router (L1 or L2). The script will ask all the necessary questions. You run it as follows:
$ @netconfigure.com
Further on you'll start it by running:
$ @startnet.com
Kari
But I know I'm very vague here. Better to wait for someone else to answer, perhaps. I know myself around VMS, and have been working with it on and off for over 20 years, but I'm really more familiar with RSX these days, and have to experiment a bit every time I set down with VMS before I remember how you're supposed to do it there. :-)
Johnny
On Fri, 27 Feb 2009, Johnny Billquist wrote:
But I seem to remember that it wasn't that difficult to get it running. I think there is a script you run to set things up, and after you've run that, you're basically set.
I think the Hobbyist site has a couple doc's, one for VAX and one for Alpha. Really it's a piece of cake. I find a VMS install to typically be easier
than a Windows install.
But I know I'm very vague here. Better to wait for someone else to answer, perhaps. I know myself around VMS, and have been working with it on and off for over 20 years, but I'm really more familiar with RSX these days, and have to experiment a bit every time I set down with VMS before I remember how you're supposed to do it there. :-)
I assume the OP is planning on using SIMH? Other questions would revolve
around what version of VMS he has. Depending on the time of install kit, it
may or may not include the networking install kits. One such example is the
Hobbyist V1 CD-ROM, which does not include DECnet or UCX (TCP/IP) install
kits.
Zane
