HECnet

hecnet@lists.dfupdate.se

3 participants
15561 discussions

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Peter Lothberg Sent: 07 June 2012 03:02 To: hecnet at Update.UU.SE Cc: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Connections to SG1:: Hmm. Sure. But if you go the Linux routing route, then you instead get into the problem that it don't have a point-to-point connection to another Linux box on the Internet... If anyone makes a Linux implemenation, I'll suggest that it would be made to support the Cisco/GRE and Multinet/UDP formats, and you could also have Johnny's bridge on the other side.... -P That is a good idea, I will take a look at doing that. Regards Rob

13 years

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-07 19:40, Sampsa Laine wrote: On 7 Jun 2012, at 18:12, Paul_Koning at Dell.com wrote: The main difference I can see vs. having the implementation in the kernel is that the kernel one gives you an integrated API. DecNET/Linux uses sockets, so an existing socket based app can be made to run over DECnet with potentially very little work. On the other hand, a userland implementation would need a different mechanism for the communication between the application and the DECnet daemon. Again it was suggested that the DECNET daemon listens on a socket, then you just plop the destination and/or listening details in via that mechanism - it's one line or so of code :) But that is not enough. You need to read/write data, get notifications somehow, do out of band transmissions, accept, reject, connect and get information, and some more stuff. You need a protocol for talking to the daemon, no matter which way the communication actually pass back and forth between user programs and the daemon. Johnny

13 years

Size of HECnet

by md.benson＠gmail.com

On 7 Jun 2012, at 20:18, Kari Uusim ki wrote: On 7.6.2012 20:12, Mark Benson wrote: The last version of HP Pathworks 32 (7.2 I think?) works well in Windows XP 32-bit. I have a node that uses it but it's not switched on much. The last version of Pathworks32 is V7.4 (I have the installation medium). Haven't used Pathworks32 for many years anymore. Maybe I would take it up again. :) That's the one I meant :) -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts.

13 years

Size of HECnet

by uusimaki＠exdecfinland.org

On 7.6.2012 20:12, Mark Benson wrote: The last version of HP Pathworks 32 (7.2 I think?) works well in Windows XP 32-bit. I have a node that uses it but it's not switched on much. The last version of Pathworks32 is V7.4 (I have the installation medium). Haven't used Pathworks32 for many years anymore. Maybe I would take it up again. :)

13 years

Multinet Tunnel Connections to SG1::

by sampsa＠mac.com

On 7 Jun 2012, at 18:12, Paul_Koning at Dell.com wrote: The main difference I can see vs. having the implementation in the kernel is that the kernel one gives you an integrated API. DecNET/Linux uses sockets, so an existing socket based app can be made to run over DECnet with potentially very little work. On the other hand, a userland implementation would need a different mechanism for the communication between the application and the DECnet daemon. Again it was suggested that the DECNET daemon listens on a socket, then you just plop the destination and/or listening details in via that mechanism - it's one line or so of code :) Sampsa

13 years

PDP-11 GCC back-end, was Re: [HECnet] Raspberry Pi + SIMH VAX?

by Paul_Koning＠Dell.com

On Jun 6, 2012, at 9:21 PM, Dave McGuire wrote: On 06/06/2012 09:01 PM, Paul_Koning at Dell.com wrote: Strange that gcc has so much trouble for VAX. I thought that had gotten a fair amount of care & feeding lately. pdp11, that's a different story, though I do try to do some more bits from time to time... Are you working on that?? I recently ran across this page: http://www.diane-neisius.de/pdp11/index_E.html ...in which a very enthusiastic person got it running some time ago, but with some pretty significant restrictions. I'd truly love to see the PDP-11 GCC back-end be resurrected and made to be fully functional. It may have a very limited appeal, but I already use GCC-based cross-compilers for many different architectures in both my work and recreational activities (both mostly ARM7), and would love to be able to do some bare-metal PDP-11 work with GCC as well. If you're working on this, allow me to voice my heartfelt support for this effort! -Dave Thanks. Yes, pdp11 for gcc is an actual maintained port, given that I volunteered to be the port maintainer. I've done work to clean it up, in spurts. At this point it usually generates good code. I actually have it pass a fair fraction of the GCC test suite (execution, not just compilation). Still there are issues; for example, the AC4/AC5 handling is not 100%. But at least simple mistakes like assuming that BIC does the "and" operation have been cured. :-) You can grab a recent GCC (say, 4.7.0, or gcc trunk) and configure it --target=pdp11-aout, and that will build you a GCC that produces pdp11 code (standalone as opposed to for a particular OS). Binutils can also be configured that way, and if you have that, then you can have GNU tools compile, assemble, and link for you. One unfortunate thing is that the pdp11-bsd2 flavor was removed some time ago; I haven't looked into what it would take to bring it back. (I have near-zero experience with BSD 2.) paul

13 years

Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 7, 2012, at 1:27 PM, Johnny Billquist wrote: On 2012-06-07 19:18, Paul_Koning at Dell.com wrote: On Jun 7, 2012, at 9:48 AM, Mark Benson wrote: ... We established that, yes. That's where my idea of using pcap and running the interface in promicuous mode came out of. Why promiscuous? So long as you can get the DECnet style individual address delivered, and the multicast addresses that DECnet would register, I don't see a need for promiscuous mode. Right. There is only need for promiscous mode if you sit on an interface with the "wrong" MAC address. However, if you want to have your DECnet stack portable, you will need to go down that path, as some Unixes don't have a way to change the MAC address of an interface at all. Also, to comment on your previous post, Paul. Correct, the API of the current Linux DECnet is not possible to adopt to a new user-level DECnet implementation, as they use explicit system calls, and you can't siphon those off. Had it all been done through a decnet library, it would have been easier. But the current Linux solution is (I think) similar to the Ultrix one. And it do make sense from a pure interface point of view. Johnny Yes, I believe the socket approach is at least similar to the Ultrix one. It would be possible to create a more implementation-neutral library style API. Behind that would be your choice of a thin wrapper around DECnet sockets (for the existing DECnet/Linux) or some suitable inter-process communication to talk to a user-mode DECnet daemon. Either that, or maybe FUSE could be abused for this? paul

13 years

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-07 19:18, Paul_Koning at Dell.com wrote: On Jun 7, 2012, at 9:48 AM, Mark Benson wrote: ... We established that, yes. That's where my idea of using pcap and running the interface in promicuous mode came out of. Why promiscuous? So long as you can get the DECnet style individual address delivered, and the multicast addresses that DECnet would register, I don't see a need for promiscuous mode. Right. There is only need for promiscous mode if you sit on an interface with the "wrong" MAC address. However, if you want to have your DECnet stack portable, you will need to go down that path, as some Unixes don't have a way to change the MAC address of an interface at all. Also, to comment on your previous post, Paul. Correct, the API of the current Linux DECnet is not possible to adopt to a new user-level DECnet implementation, as they use explicit system calls, and you can't siphon those off. Had it all been done through a decnet library, it would have been easier. But the current Linux solution is (I think) similar to the Ultrix one. And it do make sense from a pure interface point of view. Johnny

13 years

Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 7, 2012, at 9:48 AM, Mark Benson wrote: ... We established that, yes. That's where my idea of using pcap and running the interface in promicuous mode came out of. Why promiscuous? So long as you can get the DECnet style individual address delivered, and the multicast addresses that DECnet would register, I don't see a need for promiscuous mode. paul

13 years

Multinet Tunnel Connections to SG1::

by Paul_Koning＠Dell.com

On Jun 7, 2012, at 6:55 AM, Mark Benson wrote: On 7 Jun 2012, at 11:42, Dave McGuire <mcguire at neurotica.com> wrote: On 06/07/2012 06:37 AM, Sampsa Laine wrote: Howabout starting it as a daemon (running as root) via the boot scripts, and have non-root users's programs access it via a socket? Cool idea - you could even have multiple hosts connect this way but export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to Box B, and MAIL to Box C :) Yes, you could multiplex/demultiplex it any way you wanted. It would open up all sorts of interesting configuration possibilities. ... and all this without needing to dick with the kernel? Sounds like a plan gentlemen, so now all we need is a long suffering coder type to do all the hard work ;) The main difference I can see vs. having the implementation in the kernel is that the kernel one gives you an integrated API. DecNET/Linux uses sockets, so an existing socket based app can be made to run over DECnet with potentially very little work. On the other hand, a userland implementation would need a different mechanism for the communication between the application and the DECnet daemon. paul

13 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet