Am I right in thinking that LAT is only suitable for the local network?
I just tried
Local> connect pdxvax
from the DECserver 90M just for a laugh.
Regards, Mark.
Except that LAT is currently turned off on PDXVAX, you could try MONK and see what happens.
Zane
At 3:23 PM +0000 11/10/09, Sampsa Laine wrote:
But Johnny's bridge does however support bridging it so in practice it can be used for long distance connections on HECnet...
Sampsa
On 10 Nov 2009, at 15:21, Paul Koning wrote:
Yes, LAT is a layer 2 protocol so it's not routable, and its timers and delay assumptions are for LANs, not for long distance networks.
paul
-----Original Message-----
Behalf Of Mark Wickens
Am I right in thinking that LAT is only suitable for the local network?
I just tried
Local> connect pdxvax
from the DECserver 90M just for a laugh.
Regards, Mark.
--
| 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/ |
You can use two OpenBSD systems to tunnel Ethernet-over-IP. I did this
between two sites each with a 2M/256K ADSL cct (same ISP), and clustered an
Alphastation at one site to SimH VAX at another (remote disk access was
slow...)
Simple PF rules would block all IP on the tunnel, but not sure if you could
specify to allow only DECnet frames across.
Cheers,
Andrew
On (15:31 09/11/09), Sampsa Laine wrote:
Guys,
I realise that at the moment there aren't many people involved that do
not have static IPs but I think as time goes on consumer grade ISPs
are going to start cutting back on the amount of IPs a residential
customer can have.
With this in mind, might there be some mileage in setting up a VPN for
HECnet use? This way we would not need to worry about whether we have
public static IPs in the future (most VPNs are happy to work with
DYNDNS etc) and it would also add a layer of security to HECnet
without any changes needed to the bridge etc.
Sampsa
--
Andrew Back
a at smokebelch.org
Sampsa Laine wrote:
Maybe it would be more worthwile for someone to hack my bridge just a
little, so that changes in DNS names were discovered, and automatically
handled.
Heck, you don't even have to change my bridge program. Just add a small
monitoring program, who don't do anything else than regularly check if
any of the names in the bridge.conf file have changed to resolve to a
different IP address, and if so, send a HUP to the bridge program, and
we'll be back in business.
I'm all for this...
Start hacking your small monitor daemon! :-)
Let it do name lookups once an hour, perhaps (configurable), and have
the bridge process as a fork. Then it's easy to just send the HUPs
whenever needed. The program should be pretty small, I'd guess. I just
don't have any time to do this myself right now. And it's a good
exercise for someone.
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
Add security?
You mean as in me opening my internal network to all kind of IP traffic
from any other HECnet user? As opposed to today, when they can only
transmit DECnet packets to my internal network?
Not forgetting that we'd still need the bridge software, since no VPN
solution I know of, is able to route DECnet natively.
Well I was personally gonna move my HECNET stuff onto a separate VLAN, what I meant was that running the bridge say over a VPN would add some security from the outside world - obviously this is probably pretty negligible anyway.
And not to forget that DYNDNS is a security problem in itself. :-)
And we'd also still get the occasional disruption in traffic when
someones address do change, until the DNS is updated and propagated.
Fair point.
Maybe it would be more worthwile for someone to hack my bridge just a
little, so that changes in DNS names were discovered, and automatically
handled.
Heck, you don't even have to change my bridge program. Just add a small
monitoring program, who don't do anything else than regularly check if
any of the names in the bridge.conf file have changed to resolve to a
different IP address, and if so, send a HUP to the bridge program, and
we'll be back in business.
I'm all for this...
Sampsa
Feel free. But please don't involve HECnet with that.
Not only do I want to keep the number of protocols running over the
bridges low in order to keep atleast a semblance of control of what is
happening, if I don't remember wrong, IPX/SPX are very ugly protocols,
who are using broadcasts for a lot of stuff. Meaning it can really bog
down systems who don't even care about it.
In short - it is a protocol that should have been banned! :-)
Johnny
Sampsa Laine wrote:
Yeah, I'd be up for rolling out a Novell server - never done it before.
Sampsa
On 9 Nov 2009, at 16:13, neozeed wrote:
I found my notes on OpenVPN & bridging...
http://virtuallyfun.blogspot.com/2008/10/some-fun-networking-with-ms-dos-no…
<http://virtuallyfun.blogspot.com/2008/10/some-fun-networking-with-ms-dos-no…>if it helps any, the only 'static' ip that would be needed would be the server that is bridging its tap/tun to the hecnet.... And even that could be on dyndns...
I'm fishing around for my old Netware 3.12 diskettes to rebuild it for the heck of it today.
speaking of which, in the quest for alternate protocols, why not IPX/SPX?
On Mon, Nov 9, 2009 at 11:10 AM, Brian Hechinger <wonko at 4amlunch.net <mailto:wonko at 4amlunch.net>> wrote:
On Mon, Nov 09, 2009 at 07:58:59AM -0700, Zane H. Healy wrote:
> At 3:31 PM +0000 11/9/09, Sampsa Laine wrote:
> >I realise that at the moment there aren't many people involved that
> >do not have static IPs but I think as time goes on consumer grade
> >ISPs are going to start cutting back on the amount of IPs a
> >residential customer can have.
> >
> >With this in mind, might there be some mileage in setting up a VPN
> >for HECnet use? This way we would not need to worry about
whether we
> >have public static IPs in the future (most VPNs are happy to work
> >with DYNDNS etc) and it would also add a layer of security to
HECnet
> >without any changes needed to the bridge etc.
>
> I have to pay for a commercial line, and not simply the low-end
> commercial line, but a higher-grade one in order to get a static IP.
> That's part of why I have such a fast connection now. Honestly
> between the cost of the commercial line and the added
electricity use
> it really isn't worth what it's costing me each month to keep this
> going since I don't really have time to mess with such things. :-(
Does it matter if the "client" end of the tunnel has a dynamic IP?
If not
we only need a handful of static IPs. Once the new box gets put
into place
at colo i was going to setup simh on it. I could be a massive
routing hub
if people wanted to connect their tunnels to me.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard
full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
--
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
Can you make it only bridge specific ethernet type packets, and not
transfer anything else?
If so, that could be a good replacement for my bridge program.
Johnny
neozeed wrote:
OpenVPN will bridge, as I've done IPX/SPX over it... On Mon, Nov 9, 2009 at 10:31 AM, Sampsa Laine <sampsa at mac.com <mailto:sampsa at mac.com>> wrote:
Guys,
I realise that at the moment there aren't many people involved that
do not have static IPs but I think as time goes on consumer grade
ISPs are going to start cutting back on the amount of IPs a
residential customer can have.
With this in mind, might there be some mileage in setting up a VPN
for HECnet use? This way we would not need to worry about whether we
have public static IPs in the future (most VPNs are happy to work
with DYNDNS etc) and it would also add a layer of security to HECnet
without any changes needed to the bridge etc.
Sampsa
--
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
Sampsa Laine wrote:
Guys,
I realise that at the moment there aren't many people involved that do not have static IPs but I think as time goes on consumer grade ISPs are going to start cutting back on the amount of IPs a residential customer can have.
With this in mind, might there be some mileage in setting up a VPN for HECnet use? This way we would not need to worry about whether we have public static IPs in the future (most VPNs are happy to work with DYNDNS etc) and it would also add a layer of security to HECnet without any changes needed to the bridge etc.
Add security?
You mean as in me opening my internal network to all kind of IP traffic
from any other HECnet user? As opposed to today, when they can only
transmit DECnet packets to my internal network?
Not forgetting that we'd still need the bridge software, since no VPN
solution I know of, is able to route DECnet natively.
And not to forget that DYNDNS is a security problem in itself. :-)
And we'd also still get the occasional disruption in traffic when
someones address do change, until the DNS is updated and propagated.
What we would gain would be an automatic recovery, which we don't have
today.
Maybe it would be more worthwile for someone to hack my bridge just a
little, so that changes in DNS names were discovered, and automatically
handled.
Heck, you don't even have to change my bridge program. Just add a small
monitoring program, who don't do anything else than regularly check if
any of the names in the bridge.conf file have changed to resolve to a
different IP address, and if so, send a HUP to the bridge program, and
we'll be back in business.
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
Anyone try it of VMWare yet?
Sampsa
On 9 Nov 2009, at 17:46, neozeed wrote:
Speaking of Netware, I was attempting to install a relatively recent version of Netware on Sun's VirtualBox and it would always abort when detecting drives ... anyone on the list ever successfully get that working? (under any kind of VM?)
Cheers,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
I know qemu 0.9.0 can run it fine... I just tried 0.11 and the disk driver trips it up, just like Virtual box trips up on it as well....
the default isadisk sees no drives, and the ide doesn't work. Now I bet there is some 'fixes' out there but the netware people never were the good at making things.... sane.
I kicked off my install like this:
..\090\qemu-img.exe create -f qcow netware.disk 2G Formating 'netware.disk', fmt=qcow, size=2097152 kB
..\090\qemu.exe -L ..\090 -M isapc -m 16 -hda netware.disk -fda INSTALL.vfd -boot a
I'll have to get back on the networking though....
Speaking of Netware, I was attempting to install a relatively recent version of Netware on Sun's VirtualBox and it would always abort when detecting drives ... anyone on the list ever successfully get that working? (under any kind of VM?)
Cheers,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
I know qemu 0.9.0 can run it fine... I just tried 0.11 and the disk driver trips it up, just like Virtual box trips up on it as well....
the default isadisk sees no drives, and the ide doesn't work. Now I bet there is some 'fixes' out there but the netware people never were the good at making things.... sane.
I kicked off my install like this:
..\090\qemu-img.exe create -f qcow netware.disk 2G Formating 'netware.disk', fmt=qcow, size=2097152 kB
..\090\qemu.exe -L ..\090 -M isapc -m 16 -hda netware.disk -fda INSTALL.vfd -boot a
I'll have to get back on the networking though....
