Well static and static, but I mean there must be an IP address for configuration of our side as the original MULTINET stack's UDP tunnel does not to DNS lookups...
Sampsa
On 13 Jun 2010, at 16:07, Steve Davidson wrote:
Actually, for this short duration, who cares about a static address. Fred and
I use dedicated VS4000/VLC's as Multinet tunnel routers. We reboot as
necessary and ignore everyone's complaints. SG1 actually has a script that
deals with some of this automatically. If I have time today I may even finish
it. It deals with the burden of changing the address entry in Multinet and
reboots. Total turn-around is under 5 minutes, actually more like 3 minutes.
I noticed that Johnny has made changes to the bridge. I do not have these
changes. My version is different than his to begin with. Fred and I run
my version but it could probably use Johnny's fixes. I'm now wondering if
some of the "surprises" we have been running into have to do with these
"fixes". Do either of you know? I have not approached Johnny about getting
these changes.
-Steve
Yup, that's correct.
Now we will need a static IP to make this work, unless we set up my
end on a Linux box - the MULTINET Linux port knows how to look up
hostnames, the original VMS one needs a static IP.
Steve is right about the bridge and LAT however, we COULD set up the
bridge as a backup and try the MULTINET tunnel as a primary method of
connection.
Sampsa
On 13 Jun 2010, at 07:50, Mark Wickens wrote:
I've been talking to Steve Davidson and it crossed my mind that if we
use multinet to connect we won't need a separate unix box as we
wouldn't
require Johnny's bridge. Is that correct? Might be worth going through
the motions if you have time, (a) to get the process documented and
(b)
to provide a good fallback strategy if option 1 using the bridge to
connect through to you doesn't work.
Regards, Mark.
Actually, for this short duration, who cares about a static address. Fred and
I use dedicated VS4000/VLC's as Multinet tunnel routers. We reboot as
necessary and ignore everyone's complaints. SG1 actually has a script that
deals with some of this automatically. If I have time today I may even finish
it. It deals with the burden of changing the address entry in Multinet and
reboots. Total turn-around is under 5 minutes, actually more like 3 minutes.
I noticed that Johnny has made changes to the bridge. I do not have these
changes. My version is different than his to begin with. Fred and I run
my version but it could probably use Johnny's fixes. I'm now wondering if
some of the "surprises" we have been running into have to do with these
"fixes". Do either of you know? I have not approached Johnny about getting
these changes.
-Steve
Yup, that's correct.
Now we will need a static IP to make this work, unless we set up my
end on a Linux box - the MULTINET Linux port knows how to look up
hostnames, the original VMS one needs a static IP.
Steve is right about the bridge and LAT however, we COULD set up the
bridge as a backup and try the MULTINET tunnel as a primary method of
connection.
Sampsa
On 13 Jun 2010, at 07:50, Mark Wickens wrote:
I've been talking to Steve Davidson and it crossed my mind that if we
use multinet to connect we won't need a separate unix box as we
wouldn't
require Johnny's bridge. Is that correct? Might be worth going through
the motions if you have time, (a) to get the process documented and
(b)
to provide a good fallback strategy if option 1 using the bridge to
connect through to you doesn't work.
Regards, Mark.
Yup, that's correct.
Now we will need a static IP to make this work, unless we set up my end on a Linux box - the MULTINET Linux port knows how to look up hostnames, the original VMS one needs a static IP.
Steve is right about the bridge and LAT however, we COULD set up the bridge as a backup and try the MULTINET tunnel as a primary method of connection.
Sampsa
On 13 Jun 2010, at 07:50, Mark Wickens wrote:
I've been talking to Steve Davidson and it crossed my mind that if we
use multinet to connect we won't need a separate unix box as we wouldn't
require Johnny's bridge. Is that correct? Might be worth going through
the motions if you have time, (a) to get the process documented and (b)
to provide a good fallback strategy if option 1 using the bridge to
connect through to you doesn't work.
Regards, Mark.
On Sun, Jun 13, 2010 at 2:56 AM, Mark Wickens <mark at wickensonline.co.uk> wrote:
On Sun, 2010-06-13 at 07:50 +0100, Mark Wickens wrote:
I've been talking to Steve Davidson and it crossed my mind that if we
use multinet to connect we won't need a separate unix box as we wouldn't
require Johnny's bridge. Is that correct? Might be worth going through
the motions if you have time, (a) to get the process documented and (b)
to provide a good fallback strategy if option 1 using the bridge to
connect through to you doesn't work.
Regards, Mark.
Sorry, that was meant for Sampsa. Wickens steps into the bear trap by
mistake...
Hello!
But Mark you don't look like the Road Runner? I had Wile Coyote setup
that bear trap.
And you're not him since his traps always trap him.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sun, 2010-06-13 at 07:50 +0100, Mark Wickens wrote:
I've been talking to Steve Davidson and it crossed my mind that if we
use multinet to connect we won't need a separate unix box as we wouldn't
require Johnny's bridge. Is that correct? Might be worth going through
the motions if you have time, (a) to get the process documented and (b)
to provide a good fallback strategy if option 1 using the bridge to
connect through to you doesn't work.
Regards, Mark.
Sorry, that was meant for Sampsa. Wickens steps into the bear trap by
mistake...
I've been talking to Steve Davidson and it crossed my mind that if we
use multinet to connect we won't need a separate unix box as we wouldn't
require Johnny's bridge. Is that correct? Might be worth going through
the motions if you have time, (a) to get the process documented and (b)
to provide a good fallback strategy if option 1 using the bridge to
connect through to you doesn't work.
Regards, Mark.
Yes, that went in quite a while ago... :)
I don't remember what I've put up for upload to others though. I might have several things fixed in my "private" version which aren't out there yet.
I should check that...
Johnny
Oleg Safiullin wrote:
BTW, did you apply my patch to bridge program?
Packets sent by SimH at the time of `attach xq ...' command may cause `bridge' to crash without this patch :)
At least, the following code should be fixed:
---
@@ -497,8 +651,8 @@ void process_packet(struct DATA *d)
if (is_decnet(d)) d->type = DECnet;
if (is_lat(d)) d->type = LAT;
- if (bridge[d->source].types[d->type] == 0) return;
if (d->type == -1) return;
+ if (bridge[d->source].types[d->type] == 0) return;
bridge[d->source].xcount++;
---
On 12.06.2010 6:02, Johnny Billquist wrote:
Please do.
As a side note, if psilo.update.uu.se is down, then nothing of the
bridged network will work, since that is the true hub of things.
MIM and PONDUS can both be working perfectly fine, but without psilo
they can't even talk to each other.
However, at the moment PONDUS is turned off. I'm in the US for three
weeks, and figured that I might spear my wife the hum of PONDUS when I'm
not around. :-)
All that said, I can't seem to get contact with psilo either right now,
so it do seem to be some general network problems somewhere.
Johnny
Pontus Pihlgren wrote:
Hmm, there seems to be some issues with our network in general.. I'll
se what I can do.
On Fri, Jun 11, 2010 at 11:31:40PM +0100, Sampsa Laine wrote:
Is MIM down? I can't see it (or PONDUS)..
Sampsa
I was browsing through the OpenVMS manuals and started thinking about
distributed programs. Has anyone tried running a DECnet based
distributed program (for example using the $IPC programming interface)
across HECnet?
Hello!
I don't know about your patch, but at the moment I can reach the
server described there. It even responded to my requests for a
webpage. It also confirmed that you do have a positively eclectic
collection of hardware.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
I sent my patch to Johnny few months ago.
Patch attached to this message fixes possible crashes,
prevents `bridge' from receiving packets just sent out via pcap (OpenBSD-specific),
adds support for L2 `tun' interfaces (OpenBSD only).
