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....
Jason Stevens wrote:
Well, normally libpcap is used to recieve packets, so it don't neccesarily
help with sending them.
Second, sending packets is one thing, sending packets with a "fake" source
MAC address is yet another thing (as a short note, the DEUNA and DELUA
ethernet controllers for the Unibus can never do this. They set the source
MAC address from the controller, no matter what you place in the packet you
want to send).
But please report if you have success with this.
This is what i'm using right now to have two versions of SIMH send
pings to eachother... I added the tcp/ip stuff, and removed all of
the libpcap parts of the code.. I also noticed it uses blocking
sockets so it'll get 'stuck' from time to time reading stuff. I
started work on porting it to windows but I've been away on vacation
so it didn't get any work done...
"ping" sortof implies that you are talking tcp/ip. If so, the test is meaningless.
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
