- HECnet - lists @ Update

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by bob＠jfcl.com

Lunchboxes! :-) And there are images for new boot ROMs available for those which will allow you to boot from the on-board SCSI host adapter, ... I've heard of this, but I haven't seen it. As I recall, the onboard SCSI adapter uses programmed I/O (no DMA!) so it's really slow. For a TK50 nobody would ever notice, but for the system disk it's a problem. Better to cluster boot one, diskless. FWIW, an RD54 isn't necessary. The 2000 can easily be convinced to use _any_ MFM drive, DEC or not. You can get VMS V4 on a 30 meg drive, maybe even 20, if you're determined. Long ago I wrote up a little description of all the VS 2000 disk formatter parameters, what they meant, and how to fake them for non-DEC drives. Google ancient Usenet postings if you're interested. Bob

13 years, 1 month

1
0
0 0

New bridge.c feedback

by Alastair.Boyanich＠au.fujitsu.com

Ah.. newer version available. Actually.. I think I'm about 50+ emails behind -CURRENT on the list .. I'll go read through them first and catch up. Al. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Thursday, 7 June 2012 6:11 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] New bridge.c feedback On 2012-06-07 09:42, Johnny Billquist wrote: Hi, Alastair. Thanks for the feedback. Interesting... Care to help me figure some things out...? On 2012-06-07 08:33, Boyanich, Alastair wrote: cc-1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ Blech! Well, DPORT is by default set to 0. See the documentation of the define in the sources... This one will stay. Oh well. I made a conditional around this, so that if people don't change DPORT, it will not even be compiled. Warning gone... Cleaned up the code some, based on inspiration fallout here. New version available. No functional changes... Johnny

13 years, 1 month

1
0
0 0

New bridge.c feedback

by Alastair.Boyanich＠au.fujitsu.com

Hi Johnny, Yes. It seems to want <strings.h> 6.5.24 and above (or 6.5.29f in my case) was aiming at SUSv3 compliance away from base XPG4 so things were moved to strings.h (http://pubs.opengroup.org/onlinepubs/009695399/functions/index.html) .. it's also in the 3c index man page, you were right. So, compiles on IRIX 6.5.29 if the header is included. Worth gating it in via #ifdef ? I'm also a fan of enum types. Binary emitted is ~298kb. Also, your welcome to an account on the system if you wish to poke/play around, it's accessible over ssh and the general internet (it's my daily shell/hacking on code box). -Wall makes the MIPSpro runtime *extremely* chatty. It's quite anal. See below. Al. cc-3201 cc: REMARK File = bridge.c, Line = 158 The parameter "data" was never referenced. int lookup(struct sockaddr_in *sa, char *data) ^ cc-1506 cc: REMARK File = bridge.c, Line = 460 There is an implicit conversion from "unsigned long" to "long"; rounding, sign extension, or loss of accuracy may result. delta = timedelta(bridge[index].lasttime); ^ cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "r" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ cc-3201 cc: REMARK File = bridge.c, Line = 559 The parameter "d" was never referenced. void dump_nomatch(struct sockaddr_in *r, struct DATA *d) ^ cc-1185 cc: WARNING File = bridge.c, Line = 579 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ cc-1171 cc: WARNING File = bridge.c, Line = 685 The indicated expression has no effect. if (port == 0) port == DPORT; ^ cc-1498 cc: REMARK File = bridge.c, Line = 709 There is no prototype for the call to read_conf. read_conf(); ^ cc-1209 cc: REMARK File = bridge.c, Line = 715 The controlling expression is constant. while(1) { ^ jazz:~/src/HECnet[436]%

13 years, 1 month

1
0
0 0

lunchbox VAXen, was Re: [HECnet] Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/07/2012 09:13 AM, hvlems at zonnet.nl wrote: A vaxstation 2000 and a microvax 2000 run V4.7 too. With VWS instead of Motif at a reasonable speed. Lunchboxes! :-) And there are images for new boot ROMs available for those which will allow you to boot from the on-board SCSI host adapter, which is relatively slow (NCR5380-based) but still less painful than trying to find, and then afford to purchase, an RD54. I think someone even wrote a driver for VMS to use disks on that controller. I have several of those machines; I really should look into that. Does anyone have any further information on, or actual copies of, those boot ROMs and/or the VMS device driver? -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

Introducing myself... and my little network

by mcguire＠neurotica.com

On 06/07/2012 08:35 AM, Jordi Guillaumes i Pons wrote: According to this: http://h71000.www7.hp.com/openvms/os/openvms-release-history.html Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real boxen can run 4.7. Well you've gotta find yourself some more machines! 11/750s are probably the most common of the 4.x-capable machines, though there don't seem to be many left floating around. Heh, then I would have to find also a new home and probably an attorney to handle de divorce demand ;) I'll keep my mouth shut.. ;) -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

promiscuous mode, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/07/2012 08:16 AM, Johnny Billquist wrote: Any program that needs access to raw ethernet packets needs to run as root. Promiscuous mode or not. Promiscuous mode itself has little to do with this. So if you want to run anything like a bridge or a router, you will need to run it as root. Promiscuous mode is basically just allowing you to share the same interface as the system is otherwise using, instead of having to dedicate a separate ethernet interface for this. Maybe you're just putting this another way, but promiscuous mode is correctly defined a bit differently than this. When an Ethernet controller is placed into promiscuous mode, its on-chip MAC address filters, which normally either select or ignore inbound packets based on their MAC address, are disabled. ALL packets are received by the hardware and passed to the Ethernet driver in the OS, rather than only the ones destined for that specific interface as defined by its MAC address. I'm reasonably certain that you know this but were just explaining it in a more abstract way...? -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/07/2012 08:23 AM, Johnny Billquist 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. I think it would help if you actually explained a little more what you actually want to accomplish, and what you see as the problems...? We're just batting some ideas around. One problem is that the current DECnet stack for Linux has fallen into dismaintenance, and if that can't be changed, it will eventually stop working on current-ish kernels. The idea is to write a userland (meaning outside the kernel, not running under a non-root UID) implementation of DECnet and have non-root users' apps (dncopy, etc) talk to it via a local socket. Of course it'd be preferable in a dozen ways to have the native kernel-based DECnet support continue to be maintained, alongside IPv4, IPv6, etc where it belongs...but if we can't find anyone to do that work, we'll have to solve the problem some other way, when it actually becomes a problem. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

DECnet-DOS, was Re: [HECnet] Size of HECnet

by gregg.drwho8＠gmail.com

On Thu, Jun 7, 2012 at 6:58 PM, Dave McGuire <mcguire at neurotica.com> wrote: On 06/07/2012 12:11 PM, Kari Uusim ki wrote: There is a DECnet stack for DOS and Windows in the Pathworks V5 or V6 client kit. Those versions were meant to be used on Windows'es before Windows NT4. Then the Pathworks32 kit was released and that could be used on WNT4.0 and Windows 2000. Maybe on XP as well. Don't remember for sure. Is this the same as DECnet-DOS? I ran that a long time ago. Does anyone have a copy? It included drivers for that weird DEC ISA Ethernet card, the DEPCA, which was a full-length 8-bit board that also included (strangely) a mouse interface. -Dave -- Dave McGuire, AK4HZ New Kensington, PA Hello! Oh my aching field density equalizers! I have the programs for that thing. (Don't have the card.) I, ah, made a copy of the programs onto a floppy from a PC/AT that I was repairing for a customer, oh say about twenty years ago. The customer, (not mine Dave the store I was working at) was a student at one of the schools, (college) who had a remarkable DEC installation running at it, it might have been Columbia. I found the card in it, and asked the manager who was double checking my work, as was his wont, and of course he didn't know what it was. I found out later what it was, and yes it was what you've described. Some years later I tracked down an old RACAL networking card and its software, and they included a binary who took over for the code that supported the hardware to talk to that stuff. Obviously I never got the stuff to connect to a for real DEC setup, but heck it would be fun to try and do so. By the way Dave outside your door is a well dressed gentleman in a suit that looks like something a certain outrageous poet and author wore, and has hair to match. (Hint: its the same daft stuff I sometimes pull on Sampsa.) There's also a blue colored box outside......... ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

13 years, 1 month

1
0
0 0

DECnet-DOS, was Re: [HECnet] Size of HECnet

by mcguire＠neurotica.com

On 06/07/2012 12:11 PM, Kari Uusim ki wrote: There is a DECnet stack for DOS and Windows in the Pathworks V5 or V6 client kit. Those versions were meant to be used on Windows'es before Windows NT4. Then the Pathworks32 kit was released and that could be used on WNT4.0 and Windows 2000. Maybe on XP as well. Don't remember for sure. Is this the same as DECnet-DOS? I ran that a long time ago. Does anyone have a copy? It included drivers for that weird DEC ISA Ethernet card, the DEPCA, which was a full-length 8-bit board that also included (strangely) a mouse interface. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/07/2012 01:12 PM, Paul_Koning at Dell.com 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. Hmm. Suddenly that approach doesn't sound very appetizing. :-( -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Mark Benson Sent: 07 June 2012 07:27 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Connections to SG1:: Now, you have due permission to beat me with a dried haddock if I'm being naive (I'm not a programmer, just a user observing a conversation that's 50% over my head) but... Wouldn't a kernel-agnostic DECnet implementation be a better shot? I mean if you can skim DECnet packets using libpcap (which is kernel agnostic as far as I can tell, hell it even works on Windows :)) and use that to handle DECnet for the bridge or SimH what's stopping it being used for a full DECnet comms package? It might not be very *fast* and it's sure as hell not secure but it'd work, right? With the fast pace of kernel change and the dropping of kernel support (and OSs like Ubuntu update the kernel regularly which will break things) for DECnet in the 3.x kernel it may be that kernel-based support is no longer practicable on modern Linux. Just a thought... This is such a big thread that it breached my attention span limit, so apologies if I miss something. This was exactly my plan, and I intend to give it a go, but no promises on when I will have something. I think it would be running a user-mode program running as root, use promiscuous mode, and on linux/unix run as a daemon, while on Windows it would run as a service. Being user mode it would be possible to run it on multiple platforms with ease. I am no DECnet expert, so I don't fully understand why I would need some kind of other interface to the routing function, I got a bit lost when people started talking about needing sockets to talk to the daemon. I think I would probably just use a config file to drive it, rather than provide some kind of command interface. Not sure if this would break something? Regards Rob

13 years, 1 month

1
0
0 0

The bridge program...

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: 07 June 2012 01:30 To: hecnet at Update.UU.SE Subject: Re: [HECnet] The bridge program... On 2012-06-07 01:29, Rob Jarratt wrote: As I have hacked my own copy around a bit to make it work on Windows, can you tell me what the fix was as I may find it hard to locate your change? The port variable in the struct BRIDGE should be unsigned... :-) What changes have you made? Maybe something that should be incorporated in my sources? Johnny I can't remember exactly now, but it was mostly to get it to work on Windows. I didn't do any fancy conditional compilation stuff on it for the most part. I have attached it here. Regards Rob

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

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, 1 month

1
0
0 0

Size of HECnet

by md.benson＠gmail.com

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. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson

13 years, 1 month

1
0
0 0

Multinet Tunnel Connections to SG1::

by wonko＠4amlunch.net

On 6/6/2012 10:31 PM, Dave McGuire wrote: On 06/06/2012 10:11 PM, Joe Ferraro wrote: This isn't the thread for it, I realize.... the product slick states that the switch does BGP, HSRP, OSPF, VRRP, etc.. again, not my area of expertise... is this still considered a switch? Hmm, it may actually be ok then. I've not worked with any of the 49xx series. Supporting those dynamic routing protocols certainly suggests that it knows how to route! ;) Hey Brian, have you ever worked with those hybrid router/switch boxen? Ok, I stand somewhat corrected. IP SERVICES can do tunnels on switches. Interesting. My 3560g can't do decnet routing, however. (not that i need it to) Just FYI, the 4948 is a BAD ASS switch. It's basically a single sup Cat 4500 with a single line card crammed into a 1U case. When you say hybrid router/switch boxes your talking about the ISR stuff like George was talking about recently, yes? I now have THREE of those in the forms of an 1811w, and 1841 and the recent acquisition of a 2851. The ones George has are the bigger ones, the 3000 series I believe. Interesting beasts. -brian

13 years, 1 month

1
0
0 0

User mode DECnet (was Multinet Tunnel Connections to SG1::)

by bqt＠softjar.se

On 2012-06-07 18:18, Bob Armstrong wrote: I was meaning as in non-root. Ah, well, but that's good because it means kernel hacks are not required. Right. Basically, you need to interface to ethernet. That you do the same way as my bridge, for instance. All the rest is just massaging the data in the packet, and eventually passing data to the next higher/lower level. The one semi-sensitive thing is that there are timers that needs to be kept, and things that needs to happen at times. But I think they all have such tolerances that you will be good even running it all in userland. Johnny

13 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet