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
