Weirdly enough, I have no problem with running the bridge and SIMH on the same machine - caveat: I am running on OS X.
At the moment, I have the following:
- Gorilla (OS X 10.4.something) running the bridge on interface 0
- GORVAX (SIMH, OpenVMS 7.3, MULTINET) running on interface 0, acting as a router between the bridge and a MULTINET tunnel to the outside
- CHIMPY (running VMS 8.3, TCP/IP services), acting as an end node on the bridged network
So on the main host, there's only one interface and it all works (all = DECNET, I can't get IP traffic from Gorilla to GORVAX).
Sampsa
On 2 Mar 2009, at 09:50, Angela Kahealani wrote:
On Sunday, 2009-03-01 21:50:24 Johnny Billquist wrote:
The one limitation is that it is usually problematic to have the same
machine that is running the bridge also participate as a DECnet node
on the same interface. Because then you need to see all your own
outgoing packets. Not all hardware will do that for you.
So, if you try to run in one machine,
with hardware that can't see its own packets,
then you need 3 interfaces,
1: To talk TCP/IP / UDP for main interface plus UDP side of bridge
2: DECnet side of bridge
3: DECnet speaking software
or
a machine with only one interface running the bridge program, and
a machine with two interfaces, one for TCP/IP/UDP and one DECnet.
Or have I still misunderstood?
Aloha, Angela
--
"(I'll) Be Seeing You..." All information and transactions are
private between the parties, and are non negotiable. All rights
reserve without prejudice, Angela Kahealani. http://kahealani.com
On Sunday, 2009-03-01 21:50:24 Johnny Billquist wrote:
The one limitation is that it is usually problematic to have the same
machine that is running the bridge also participate as a DECnet node
on the same interface. Because then you need to see all your own
outgoing packets. Not all hardware will do that for you.
So, if you try to run in one machine,
with hardware that can't see its own packets,
then you need 3 interfaces,
1: To talk TCP/IP / UDP for main interface plus UDP side of bridge
2: DECnet side of bridge
3: DECnet speaking software
or
a machine with only one interface running the bridge program, and
a machine with two interfaces, one for TCP/IP/UDP and one DECnet.
Or have I still misunderstood?
You're making things over-complex.
I can't ever imagine a scenario in which you need more than two interfaces.
In your first example above, 1 and 2 can be on the same interface with
no problems.
The only time you even need more than one interface is if the machine
running the bridge program is itself also a DECnet node, in which case
the machines own DECnet traffic can't be on the same interface as the
bridge is capturing DECnet traffic. All other stuff can be shared on any
of the interfaces.
In short. bridge can coexist with any TCP/IP traffic. DECnet can coexist
with any TCP/IP traffic. bridge and DECnet can't coexist.
And in all of these sentences I'm talking about that specific machines
protocols/applications running. It is not relevant if another machine
talks DECnet when we're talking about the bridge program. The bridge
program is not a DECnet program, and should not be confused with them. The
bridge is just a cable extension. A repeater. A hub.
Johnny
On Sunday, 2009-03-01 21:50:24 Johnny Billquist wrote:
The one limitation is that it is usually problematic to have the same
machine that is running the bridge also participate as a DECnet node
on the same interface. Because then you need to see all your own
outgoing packets. Not all hardware will do that for you.
So, if you try to run in one machine,
with hardware that can't see its own packets,
then you need 3 interfaces,
1: To talk TCP/IP / UDP for main interface plus UDP side of bridge
2: DECnet side of bridge
3: DECnet speaking software
or
a machine with only one interface running the bridge program, and
a machine with two interfaces, one for TCP/IP/UDP and one DECnet.
Or have I still misunderstood?
Aloha, Angela
--
"(I'll) Be Seeing You..." All information and transactions are
private between the parties, and are non negotiable. All rights
reserve without prejudice, Angela Kahealani. http://kahealani.com
Done.
Sampsa
On 2 Mar 2009, at 01:17, Steve Davidson wrote:
Sampsa,
Could you update the DECnet database using MIM:: please. Area 19
appears to be unknown to your system.
Thanks.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Sampsa Laine
Sent: Sunday, March 01, 2009 19:09
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] What use are *you* making of HECnet?
Ok, so I just realised CHIMPY is in fact acting as a gateway into and
out of HECnet already :)
To send mail in:
Address the message to "<HECNET NODE>::
<USER>"@chimpymail.sampsa.com
To send mail out
Address the message to CHIMPY::SMTP%"<Internet email address>"
Sampsa
On 1 Mar 2009, at 23:53, Peter Lothberg wrote:
If I remember right, it was/is Robert Armstrong who had that up and
running.
LEGATO used to relay email between HECnet (using MAIL11) and the
Internet/SMTP, but I quit doing that last fall when I switched
registrars.
There's no reason I couldn't - I just never bothered to set up the
necessary
domain name and mail routing again.
It was pretty much never used, even by me - after all, everyone
with a
HECnet connection already has an Internet connection.
Bob
We could talk "SMTP" over DECnet.....
-P
Angela Kahealani wrote:
I'm connecting via a NetBSD 4.0 system with two (2) NIC's. One NIC
is connected to the Internet router, the other is managed entirely by
Johnny's bridge program.
Does the bridge program need two NIC's?
one for DECnet (with the necessarily forced MAC)
2nd for UDP? can the UDP port share with TCP/IP functionality?
i.e., to get from
"Internet" <--> Bridge <--> DECnet <--> DECnet-consuming-application
how many NICs do I need? Since the DECnet-consuming-application
must have a DECnet address, I know it needs it's own NIC on which
it can own a corresponding MAC in the DECnet address range, but
does the DECnet side of the Bridge program need it's own DECnet
address also?
Is the short answer to go read some documentation on the bridge program?
No. The short answer is "no". :-)
One NIC is enough. The bridge program isn't visible to DECnet. Think of it as a cord extension. It grabs all the "correct" ethernet packets on an interface, and sends them out as UDP packets to the IP stack. What the IP stack choose to use for interface is none of it's concern. The same for the other direction. UDP packet is received, and sent out on a specified ethernet interface.
The one limitation is that it is usually problematic to have the same machine that is running the bridge also participate as a DECnet node on the same interface. Because then you need to see all your own outgoing packets. Not all hardware will do that for you.
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
At 10:44 PM -0500 3/1/09, Steve Davidson wrote:
Something that Zane mentioned suggested this question. How are you
connecting to HECnet?
The following is how I was connecting until everything went into storage last September.
Pentium III running OpenBSD with two NIC's. This is my firewall, and it runs the bridge. I'd like to upgrade this soon to a low-power Mini-ITX system as the Pentium III system was getting flaky when I had to shut it down last September.
DEC VAXstation 4000 (I'm drawing a blank as to if it's a 60 or 90 since it's in storage, was a VLC till it developed PS issues) running VAX/VMS 5.5-2. This is PDXVAX my DECnet Area router, and it also runs Multinet for a Multinet bridge to LEGATO.
My main VMS system is MONK which is a Compaq XP1000/667 running OpenVMS 8.3 with DECnet phase IV (was originally running Phase V).
Yes, the Multinet link provides a second connection into HECnet, Christine and I have been the sites routing between the two types of connections. There were also one or two people using Cisco router links as well, but I don't know if anyone still has those links up.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
I'm connecting via a NetBSD 4.0 system with two (2) NIC's. One NIC
is connected to the Internet router, the other is managed entirely by
Johnny's bridge program.
Does the bridge program need two NIC's?
one for DECnet (with the necessarily forced MAC)
2nd for UDP? can the UDP port share with TCP/IP functionality?
i.e., to get from
"Internet" <--> Bridge <--> DECnet <--> DECnet-consuming-application
how many NICs do I need? Since the DECnet-consuming-application
must have a DECnet address, I know it needs it's own NIC on which
it can own a corresponding MAC in the DECnet address range, but
does the DECnet side of the Bridge program need it's own DECnet
address also?
Is the short answer to go read some documentation on the bridge program?
Aloha, Angela Kahealani
--
"(I'll) Be Seeing You..." All information and transactions are
private between the parties, and are non negotiable. All rights
reserve without prejudice, Angela Kahealani. http://kahealani.com
Something that Zane mentioned suggested this question. How are you
connecting to HECnet?
I'm connecting via a NetBSD 4.0 system with two (2) NIC's. One NIC is
connected to the Internet router, the other is managed entirely by
Johnny's bridge program. It only sees DECnet traffic through the
bridge, no IP at all. It works quite well for what it is. I should
mention that the NetBSD system is a Pentium 166 with 32MB of memory.
What others see is a VAXstation 4000 Model 60 (AGENA::) running VMS 7.3.
It works for me!
-Steve
At 5:44 PM -0600 3/1/09, Patrick J. Jankowiak wrote:
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
What is your TCP stack? If you're using Multinet you can use it to connect.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Sampsa,
Could you update the DECnet database using MIM:: please. Area 19
appears to be unknown to your system.
Thanks.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Sampsa Laine
Sent: Sunday, March 01, 2009 19:09
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] What use are *you* making of HECnet?
Ok, so I just realised CHIMPY is in fact acting as a gateway into and
out of HECnet already :)
To send mail in:
Address the message to "<HECNET NODE>::
<USER>"@chimpymail.sampsa.com
To send mail out
Address the message to CHIMPY::SMTP%"<Internet email address>"
Sampsa
On 1 Mar 2009, at 23:53, Peter Lothberg wrote:
If I remember right, it was/is Robert Armstrong who had that up and
running.
LEGATO used to relay email between HECnet (using MAIL11) and the
Internet/SMTP, but I quit doing that last fall when I switched
registrars.
There's no reason I couldn't - I just never bothered to set up the
necessary
domain name and mail routing again.
It was pretty much never used, even by me - after all, everyone
with a
HECnet connection already has an Internet connection.
Bob
We could talk "SMTP" over DECnet.....
-P
Ok, so I just realised CHIMPY is in fact acting as a gateway into and out of HECnet already :)
To send mail in:
Address the message to "<HECNET NODE>:: <USER>"@chimpymail.sampsa.com
To send mail out
Address the message to CHIMPY::SMTP%"<Internet email address>"
Sampsa
On 1 Mar 2009, at 23:53, Peter Lothberg wrote:
If I remember right, it was/is Robert Armstrong who had that up and
running.
LEGATO used to relay email between HECnet (using MAIL11) and the
Internet/SMTP, but I quit doing that last fall when I switched registrars.
There's no reason I couldn't - I just never bothered to set up the necessary
domain name and mail routing again.
It was pretty much never used, even by me - after all, everyone with a
HECnet connection already has an Internet connection.
Bob
We could talk "SMTP" over DECnet.....
-P
Most real core IP networks have MTU=4470 or bigger (10GE 9K), but as soon as you
hit a 100Mbit ethernet thing or so, you loose...
-P
Paul Koning wrote:
"Jason" == Jason Stevens <neozeed at gmail.com> writes:
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?
Jason> Well if you were trying to send the whole 1500 bytes of data +
Jason> headers in the UDP packet won't it cut stuff off?
No, not unless it's either IPv6, or you set the "don't fragment" flag
in the IP header. IPv4 will fragment oversized packets no matter
what's inside, and indeed this is the only way for random size
UDPgrams to get where they are going. It should work fine. Note that
fragmentation is often not all that efficient. Compared with the
performance of old 10Mb/s DEC Ethernet gear, that's unlikely to be an
issue.
Actually, since there isn't a good way of finding out how large packets
you can send, fragmentation is almost neccesary. It can occur anywhere
along the way from source to destination, not only at the start or end.
And fragmentation is actually the most efficient way of getting data
across. The problem is if one fragment is lost, which will cause
retransmission of a lot of fragments. That's the reason TCP tries to
avoid it.
But with large IP packets, you get a lower protocol overhead compared to
actual data transferred.
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
If I remember right, it was/is Robert Armstrong who had that up and
running.
LEGATO used to relay email between HECnet (using MAIL11) and the
Internet/SMTP, but I quit doing that last fall when I switched registrars.
There's no reason I couldn't - I just never bothered to set up the necessary
domain name and mail routing again.
It was pretty much never used, even by me - after all, everyone with a
HECnet connection already has an Internet connection.
Bob
We could talk "SMTP" over DECnet.....
-P
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
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.
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
TCP/IP don't care about the source MAC address. And destination MAC address
is just used to make the packet end up at the right destination, without any
other meaning to it. And the mapping between destination IP address and MAC
address is solved by ARP. And several different IP addresses can use the
same MAC address. Exactly how that MAC address looks like isn't an issue
either. So, for TCP/IP, everything will work fine if you just use the actual
MAC address the card have, even though you might be doing traffic both from
the host, and from a simulator within the host. Reception is a bit worse,
since you need to figure out if the received packet should go to the host or
the simulator.
DECnet works in a very different way, where each host *must* have a unique
MAC address, and where the recipient really checks that the source MAC
address is consistent with what was expected, or else the packet is dropped
(yes, I'm writing and meaning source address here). And sending data is done
to a specific MAC address without ARP. Instead the MAC address is calculated
from the DECnet address, and is thus "known" already. For all hosts on the
network.
Believe me. You are not really seeing or understanding the problem yet, with
the tests you are doing.
Parts are things you need to read up on, on how DECnet works. And parts
you'll only find out the hard way, as I 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
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....
