HECnet

hecnet@lists.dfupdate.se

15586 discussions

by roll＠Stupi.SE

But it is fun to see people fail. :-) It is definitely fun to watch people try to break in to VMS. ;) On Sol.Stupi.Se (59.10) they think it understands X.86 binaries.. I'm sure tehey don't even understand the stackpointer moves UP not down on a DEC20/PDP10. -P

12 years, 11 months

SIMH + Multiple interfaces + DECnet

by Paul_Koning＠Dell.com

On Dec 29, 2012, at 2:34 PM, Johnny Billquist wrote: On 2012-12-29 20:29, Paul_Koning at Dell.com wrote: On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote: ... Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens. Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why. And I still claim that they are not bridging, but routing. They do not ignorantly repeat any packets received on one interface out on other interfaces, which is what a bridge does. I'd happily discuss this further, if you really disagree with me. :-) I quite agree with you. "Routing" nodes are routing... I just disagreed with the comment that VMS nodes don't understand bridging. They don't DO it, but they understand it... This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface. Right. Phase V is a different story again. And I assume you mean endnodes with more than one active interface, as phase IV endnodes can also have more than one interface, but only one can be active. Johnny Yes, that's what I meant. paul

12 years, 11 months

SIMH + Multiple interfaces + DECnet

by bqt＠softjar.se

On 2012-12-29 20:29, Paul_Koning at Dell.com wrote: On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote: ... Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens. Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why. And I still claim that they are not bridging, but routing. They do not ignorantly repeat any packets received on one interface out on other interfaces, which is what a bridge does. I'd happily discuss this further, if you really disagree with me. :-) This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface. Right. Phase V is a different story again. And I assume you mean endnodes with more than one active interface, as phase IV endnodes can also have more than one interface, but only one can be active. Johnny

12 years, 11 months

SIMH + Multiple interfaces + DECnet

by b4＠gewt.net

On 29 Dec 2012, at 14:29, <Paul_Koning at Dell.com> wrote: On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote: ... Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens. Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why. OpenVPN just became touchy and disallowed the MAC address change in my case. This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface. Can you have different addresses per interface in Phase V? paul -- Cory Smelosky http://gewt.net/ Personal stuff! http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.

12 years, 11 months

SIMH + Multiple interfaces + DECnet

by Paul_Koning＠Dell.com

On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote: ... Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens. Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why. This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface. paul

12 years, 11 months

Node renamings

by ppuskari＠yahoo.com

Sampsa, the bridge is now quiet on my site as well. It was like you said just spitting out hash entries left and right. Now it's quiet and just sitting at: Found match: sampsacom == sampsacom Host table: 0: local 0.0.0.0:0 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000) 1: sampsacom XX.XX.XX.XX:4711 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000) Hash of known destinations: I think all is well. I'll need to get the apps on here next right? Petar From: Johnny Billquist <bqt at softjar.se> To: hecnet at Update.UU.SE Cc: sampsa at mac.com Sent: Saturday, December 29, 2012 9:58 AM Subject: Re: [HECnet] Node renamings On 2012-12-29 15:54, sampsa at mac.com wrote: > Debug output: > > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > Setting existing hash to bridge 1 > > 20-30 / sec, at least. > > Didn't use to be this rapid. That is, I'd say, just an expected effect of having many machines and routers on the bridge... Any time a packet comes in, this message is output. And every router is regularly broadcasting packets. Add more routers, and you'll get more packets. Johnny > > Sampsa > > > > --- > Sampsa Laine <sampsa at mac.com> > > > > > > > > On 29 Dec 2012, at 16:53, Johnny Billquist <bqt at softjar.se> wrote: > >> On 2012-12-29 15:42, sampsa at mac.com wrote: >>> Johnny, >>> >>> Is everything ok on the bridge - whenever I turn mine on I get about 10-20 hashes / sec from your side and it kills my routing totally. >> >> What do you mean by "get about 10-20 hashes / sec"? >> >> Johnny >> >

12 years, 11 months

INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems

by bqt＠softjar.se

On 2012-12-29 18:57, Dave McGuire wrote: On 12/29/2012 10:00 AM, sampsa at mac.com wrote: type nikkel::info.txt %TYPE-W-SEARCHFAIL, error searching for NIKKEL::INFO.TXT; -RMS-E-FND, ACP file or directory lookup failed -SYSTEM-F-INVLOGIN, login information invalid at remote node Won't work until there's a default FAL user and an INFO.TXT... So what's supposed to be in this INFO.TXT file that everyone's been talking about lately? I think I may be too much of a newcomer here to know about it. Where should it be, and what should it contain? Actually, thanks for reminding me. This is something someone should write up a page about. I'll happily put a link to that on the hecnet webpage... (Or host it, if needed.) Johnny

12 years, 11 months

UPDATE: HECNET.HLP file for VMS systems

by b4＠gewt.net

On 29 Dec 2012, at 13:11, sampsa at mac.com wrote: Nah, that stuff is like pre-alpha stuff, was just a demo. Want me to add your nodes to the HELP scanner? For my area, scan GEWT::INFO.TXT I'll get around to updating it once I remember where all my nodes are. On 29 Dec 2012, at 20:08, Dan Williams <williams.dan at gmail.com> wrote: Hi, Area 51 now has an info.txt on every node. I am not showing up in the map you did the other day should I be worried ? Dan On 29 December 2012 10:36, <sampsa at mac.com> wrote: If you don't want to send me a HLP file I can now automatically generate one from your INFO.TXT file. Let me know if you want your node added to the automatically generated help file list. Sampsa -- Cory Smelosky http://gewt.net/ Personal stuff! http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.

12 years, 11 months

UPDATE: HECNET.HLP file for VMS systems

by sampsa＠mac.com

Nah, that stuff is like pre-alpha stuff, was just a demo. Want me to add your nodes to the HELP scanner? On 29 Dec 2012, at 20:08, Dan Williams <williams.dan at gmail.com> wrote: Hi, Area 51 now has an info.txt on every node. I am not showing up in the map you did the other day should I be worried ? Dan On 29 December 2012 10:36, <sampsa at mac.com> wrote: If you don't want to send me a HLP file I can now automatically generate one from your INFO.TXT file. Let me know if you want your node added to the automatically generated help file list. Sampsa

12 years, 11 months

INFO.TXT, was Re: [HECnet] UPDATE: HECNET.HLP file for VMS systems

by sampsa＠mac.com

Here's an example: ---- SNIP ---- Welcome to CHIMPY::, part of the SAMPSACOM network. Currently active users for email include: SAMPSA DAVIDSON We offer the following guest logons: ACCOUNT - Use this to request an account on CHIMPY:: B4BBS - Gateway to the SAMPSACOM Bulletin Board System, B4BBS. TETRIS - Awesome VT100 tetris game. PYFFLE - A Python re-implementation of the coolest BBS software ever, Waffle Thank you, Sampsa Laine (CHIMPY::SAMPSA) --- .BEGIN-HECNET-INFO ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES 8.401|CHIMPY|Sampsa Laine |sampsa at mac.com |AlphaServer DS10 |OpenVMS 8.3 |London, England |Main SAMPSACOM system, SMTP gateway (CHIMPYMAIL.COM) 8.400|GORVAX|Sampsa Laine |sampsa at mac.com |SIMH VAX on OSX/Intel |OpenVMS 7.3 |London, England |MULTINET bridge to Area 2, Area router 8.403|RHESUS|Sampsa Laine |sampsa at mac.com |HP rx2600 Dual 900MHz |OpenVMS 8.4E |London, England |File libraries available 8.500|PYFFLE|Sampsa Laine |system at pyffle.com|VMWare |Pyffle BBS |London, England |Waffle reimplementation BBS, log in as pyffle for access .END-HECNET-INFO ---- SNIP ---- --- Sampsa Laine <sampsa at mac.com> On 29 Dec 2012, at 19:57, Dave McGuire <mcguire at neurotica.com> wrote: On 12/29/2012 10:00 AM, sampsa at mac.com wrote: type nikkel::info.txt %TYPE-W-SEARCHFAIL, error searching for NIKKEL::INFO.TXT; -RMS-E-FND, ACP file or directory lookup failed -SYSTEM-F-INVLOGIN, login information invalid at remote node Won't work until there's a default FAL user and an INFO.TXT... So what's supposed to be in this INFO.TXT file that everyone's been talking about lately? I think I may be too much of a newcomer here to know about it. Where should it be, and what should it contain? -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet