HECnet

hecnet@lists.dfupdate.se

15589 discussions

by bqt＠softjar.se

Hi, Alastair. Thanks for the feedback. Interesting... Care to help me figure some things out...? On 2012-06-07 08:33, Boyanich, Alastair wrote: Hi Johnny. New bridge.c compiled. Seems fine in GCC, MIPSpro is still too strict. Build output and config are as follows: jazz:~/src/HECnet[97]%cc -O2 -o bridge bridge.c -I/opt/skunkware/include -L/opt/skunkware/lib -lpcap cc-1515 cc: ERROR File = bridge.c, Line = 229 A value of type "int" cannot be assigned to an entity of type "char *". p = index(dst,':'); ^ Eh... So your compiler thinks that index() returns an int? Is there another include file needed to get the right index() function prototype? What does your documentation (or man-page) say about index() ? Either it has a different (and strange) definition of index(), or else this is the default assumption in C that unknown functions return an int. But in that case, it might also have been nice if it complained about the unknown function. Either way, there is nothing wrong in the code, with the possible exception that some file needs to be included to fix this. cc-1185 cc: WARNING File = bridge.c, Line = 578 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ Ah. Thanks. Fixed. Silly of me. I moved to the enums several years ago, but didn't do it proper all the way. 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. 1 error detected in the compilation of "bridge.c". gmake: *** [bridge] Error 2 I've added -Wall to my Makefile now (that checks a lot), and the only warning I get here is about this last one... (which was expected) jazz:~/src/HECnet[98]%gcc -O2 -o bridge bridge.c -I/opt/skunkware/include -L/opt/skunkware/lib -lpcap bridge.c: In function 'add_bridge': bridge.c:218: warning: incompatible implicit declaration of built-in function 'bzero' bridge.c:229: warning: incompatible implicit declaration of built-in function 'index' It would definitely appear that some include file is needed to make the compilation happy on your system. Care to find out which file defines bzero() and index()? jazz:~/src/HECnet[99]%file bridge;ls -l bridge bridge: ELF N32 MSB mips-4 dynamic executable MIPS - version 1 -rwxr-xr-x 1 uridium clowns 302060 Jun 7 16:25 bridge jazz:~/src/HECnet[100]%cat bridge.conf [bridge] local ec0 update tempo.update.uu.se:4711 [decnet] local update [lat] local update #### Looks like some casting might be in order. I think I'm ready to go with the port forwarding and bridge setup on this end. Spotted a nice guide a while ago as to how to configure the decnet side of things. I'll follow that guide once the bridge is up. :) Looks good, yes... Johnny

13 years, 8 months

Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/07/2012 03:28 AM, Johnny Billquist wrote: SIMH uses libpcap and implements networking for emulated machines by kicking the interface into promiscuous mode. That's a bit dangerous from a traffic perspective; I'm not certain that'd be a good idea for anything other than the most casual use on a quiet network. Dangerous in which way? Traffic. My main desktop machine sits on a busy network, and I am uncomfortable with the notion of it sitting in promiscuous mode. Remember that I also do all of my work (meaning "make money for food" work) on this system. It will create a larger load on the system, but that's about it. And todays machines are fast enough that you really need a lot of traffic before it will become a serious problem from that point of view. Remember that most of the filtering out of unwanted packets are done in the kernel anyway, and not in user space. That's what the bpf interface and filter programs do for you. Yes I understand, but while not in promiscuous mode, the filtering is done by the network interface chip, rather than by one of my cores which are typically pretty busy doing other things. I have a very fast machine on my desk, but that doesn't mean I want to waste the cycles...I use those cycles for lots of stuff. ;) The main reason in the past for changing the MAC address has been that you want to control the source MAC address. However, most systems now allows you to spoof the source MAC when outputting packets on the ethernet, so that problem is solved. Well, and to receive those packets! Load is the one remaining reason to even worry, and that is a rather small worry for most people. I agree, but it is a bigger concern for me as above. There is also a "purist" aspect...I also eschew things like "winprinters" (if you remember those!)...my main CPU cores have other work to be doing. With todays network gear, you will not get most packets to your machine anyway, the switches are already doing the filtering for you, so promiscuous mode don't hurt much from that point either. ...and this is the only thing that makes me more comfortable with the idea. The switch will just have more than one entry in its MAC table for this port. But I still don't like it. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 8 months

Multinet Tunnel Connections to SG1::

by bqt＠softjar.se

On 2012-06-07 08:39, Dave McGuire wrote: On 06/07/2012 02:26 AM, Mark Benson wrote: 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... It's a good idea, but I'm not sure it can be done. We need to change the MAC address on the interface...can that be done outside the kernel? No need. See below. SIMH uses libpcap and implements networking for emulated machines by kicking the interface into promiscuous mode. That's a bit dangerous from a traffic perspective; I'm not certain that'd be a good idea for anything other than the most casual use on a quiet network. Dangerous in which way? It will create a larger load on the system, but that's about it. And todays machines are fast enough that you really need a lot of traffic before it will become a serious problem from that point of view. Remember that most of the filtering out of unwanted packets are done in the kernel anyway, and not in user space. That's what the bpf interface and filter programs do for you. The main reason in the past for changing the MAC address has been that you want to control the source MAC address. However, most systems now allows you to spoof the source MAC when outputting packets on the ethernet, so that problem is solved. Load is the one remaining reason to even worry, and that is a rather small worry for most people. With todays network gear, you will not get most packets to your machine anyway, the switches are already doing the filtering for you, so promiscuous mode don't hurt much from that point either. Johnny

13 years, 8 months

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

On 7 Jun 2012, at 07:39, Dave McGuire wrote: It's a good idea, but I'm not sure it can be done. We need to change the MAC address on the interface...can that be done outside the kernel? SimH does it by building a virtual interface attached to the real ethernet device with it's own MAC address. While it can't communicate with TCP/IP on the same machine it works just fine for DECnet. Would it work if you created a Sandbox with a virtual DEC network interface and modified MAC address then worked out from there? SIMH uses libpcap and implements networking for emulated machines by kicking the interface into promiscuous mode. That's a bit dangerous from a traffic perspective; I'm not certain that'd be a good idea for anything other than the most casual use on a quiet network. I think Johnny's bridge uses PCAP in promiscuous mode too and most of us use that and/or SimH. Like I said it's not optimal, probably isn't secure and won't be that fast, but as a compromise it's worth thinking about, because the kernel based solution is not optimal either anymore, especially if like me you run up-to-date Linux machines. -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts.

13 years, 8 months

Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/07/2012 02:26 AM, Mark Benson wrote: 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... It's a good idea, but I'm not sure it can be done. We need to change the MAC address on the interface...can that be done outside the kernel? SIMH uses libpcap and implements networking for emulated machines by kicking the interface into promiscuous mode. That's a bit dangerous from a traffic perspective; I'm not certain that'd be a good idea for anything other than the most casual use on a quiet network. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 8 months

New bridge.c feedback

by Alastair.Boyanich＠au.fujitsu.com

Hi Johnny. New bridge.c compiled. Seems fine in GCC, MIPSpro is still too strict. Build output and config are as follows: jazz:~/src/HECnet[97]%cc -O2 -o bridge bridge.c -I/opt/skunkware/include -L/opt/skunkware/lib -lpcap cc-1515 cc: ERROR File = bridge.c, Line = 229 A value of type "int" cannot be assigned to an entity of type "char *". p = index(dst,':'); ^ cc-1185 cc: WARNING File = bridge.c, Line = 578 An enumerated type is mixed with another type. d->type = classify_packet(d); ^ cc-1171 cc: WARNING File = bridge.c, Line = 684 The indicated expression has no effect. if (port == 0) port == DPORT; ^ 1 error detected in the compilation of "bridge.c". gmake: *** [bridge] Error 2 jazz:~/src/HECnet[98]%gcc -O2 -o bridge bridge.c -I/opt/skunkware/include -L/opt/skunkware/lib -lpcap bridge.c: In function 'add_bridge': bridge.c:218: warning: incompatible implicit declaration of built-in function 'bzero' bridge.c:229: warning: incompatible implicit declaration of built-in function 'index' jazz:~/src/HECnet[99]%file bridge;ls -l bridge bridge: ELF N32 MSB mips-4 dynamic executable MIPS - version 1 -rwxr-xr-x 1 uridium clowns 302060 Jun 7 16:25 bridge jazz:~/src/HECnet[100]%cat bridge.conf [bridge] local ec0 update tempo.update.uu.se:4711 [decnet] local update [lat] local update #### Looks like some casting might be in order. I think I'm ready to go with the port forwarding and bridge setup on this end. Spotted a nice guide a while ago as to how to configure the decnet side of things. I'll follow that guide once the bridge is up. :) Al.

13 years, 8 months

Multinet Tunnel Connections to SG1::

by md.benson＠gmail.com

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... -- Mark Benson http://DECtec.info Twitter: @DECtecInfo HECnet: STAR69::MARK Online Resource & Mailing List for DEC Enthusiasts.

13 years, 8 months

Size of HECnet

by Alastair.Boyanich＠au.fujitsu.com

Hi Johnny, Great! Shall do this weekend. Will get the new bridge.c compiled first. Also it'll be good to see if it builds under MIPSPro on IRIX now instead of gcc. 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 3:46 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] Size of HECnet I don't know of any .au on HECnet, so that would be cool... Let me know when you want to work on this, and I'll try to help from my end. Johnny On 2012-06-07 03:53, Boyanich, Alastair wrote: Johnny, Sounds fun. Do you have any other systems down here in .au ? If not and you have some spare time this weekend, I'd love a bit of a hand getting initially one of my systems online. We have a 3 day weekend/long weekend so I'll have more time. I'll try building the newer version of the bridge.c on the SGI, but the old one appears to function. Ports are all still setup as per instructions. 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 9:01 AM To: hecnet at Update.UU.SE Subject: [HECnet] Size of HECnet Just some fun details... As of today, there are 321 nodes in the nodename database. They are spread out over 16 areas. We have machines located on (at least) three continents, if I remember right. While not online all the time, I think we currently have atleast the following OSes represented: RSX RSTS/E VMS Ultrix Linux OSF/1 TOPS-10 Tops-20 Windows XP IOS If you know of any errors in this information, more fun facts, or anything else you'd like to share, feel free to do so. Johnny

13 years, 8 months

Multinet Tunnel Connections to SG1::

by jg＠jordi.guillaumes.name

Hi list. I'll introduce myself later when I get a proper keyboard to type (right now I'm typing on an iPhone while riding a bus to my workplace...). I' the proud manager for the new HECnet area 7. El 07/06/2012, a les 3:02, Dave McGuire <mcguire at neurotica.com> va escriure: On 06/06/2012 08:59 PM, Johnny Billquist wrote: On 2012-06-07 02:10, Dave McGuire wrote: On 06/06/2012 06:11 PM, Johnny Billquist wrote: By the way, as a warning... I seem to remember that DECnet support now have been dropped from Linux. So it might not be in there anymore, if you look at recent versions. It's still there, at least in the new Ubuntu version (12.04). The routing support is not compiled in (it's marked as experimental) so you need to build the kernel if you want to try to use it as a router. I'm pretty sure it's a way to compile just de decnet modules instead of rebuilding all the kernel, but I don't know how to do it (I tried the obvious way and failed). I planned to use Linux as my area route. It does not work. If you configure it as a level 2 router it generates corrupted packets (they have 4 additional bytes at the header, it looks like it gets wrong some offset so it should be potentially easy to fix). It SEEMS to work as level 1 router and I was using it to link together multiple tap virtual devices... until I discovered the VDE support in the 3.9 version of SIMH and started using it to have all my emulated toys in the same Ethernet segment as all the real iron (VDE is cool, I recommend you to try it :)). Well, we'll either have to talk her into re-owning it (Hi Chrissie! 8-)) or someone else will have to take up its maintenance. At least eventually, when someone breaks the kernel networking APIs again. -Dave -- Dave McGuire, AK4HZ New Kensington, PA Jordi Guillaumes i Pons Barcelona - Catalunya - Europa BITXOV::JGUILLAUMES

13 years, 8 months

Reaching SOL::, was Re: [HECnet] Multinet Tunnel Connections to SG1::

by mcguire＠neurotica.com

On 06/07/2012 02:14 AM, Peter Lothberg wrote: Can you talk to sol:: I can't seem to get to it from my Linux desktop machine, no, but I can SET HOST to it from my Alpha running VMS. (which I'm reaching from the aforementioned Linux machine!) It seems that off-net DECnet routing isn't happening from the Linux machine..? What's up with this, does anyone know? (and...an SC-40, VERY VERY nice!!) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet