On 7 Jun 2012, at 11:29, Dave McGuire 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 :)
Sampsa
On 06/07/2012 06:24 AM, Mark Benson wrote:
So we agree security is a storm in an espresso cup.
Well put. :)
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
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?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
So we agree security is a storm in an espresso cup.
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 06/07/2012 06:15 AM, Mark Benson wrote:
Yup, we are in agreement..."practically nonexistent". ;)
It's the sort of thing *I* don't care about but someone else might get
unduly upset about.
Like me being unduly upset about the additional system load incurred
by running the interface in promiscuous mode. ;)
Yes, 'practically' non-existant.
See above. =)
I think it is time for sleep!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 11:05, Dave McGuire <mcguire at neurotica.com> wrote:
Yup, we are in agreement..."practically nonexistent". ;)
It's the sort of thing *I* don't care about but someone else might get
unduly upset about.
Yes, 'practically' non-existant.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD.
Hans
-----Original Message-----
From: Jordi Guillaumes i Pons <jg at jordi.guillaumes.name>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 07 Jun 2012 11:32:40
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: [HECnet] Introducing myself... and my little network
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce
myself and my little puppies :)
My first computer (apart from the 8-bit home stuff) was a VAX-8250
running VAX/VMS 4.7. It was back in 1987, and it was a departamental
machine which was going to replace a PDP11/60, which, regretabily, I
didn't pay a lot of attention to. I was involved professionally with DEC
machines until 1992. My "last" machine was a VAXServer 4000 mod. 200,
which eventually ended living at my home :). I did plenty of stuff at
that time, from system managing to application design (and programming).
I had the pleasure to work with the DEC development environment, which I
still miss these days: VAXSet, CDD, the consistent VAX Calling
standard... I've not seen something so well integrated since those days.
Just to complete the picture, when I left the DEC environment, and after
a short time working with DOS (fortunately it was a SHORT time) I ended
working in the mainframe world, beginning in the applications
programming area (PLI, IMS/DB-DC, DB2...) and ending in the systems
programming area (mostly in the IMS environment). Right now I'm a
"software architect", whatever that means.
As I said before, when my company got rid of that 4000/200 I toke care
of it, as well as a uVAX 3300... those two machines now live happyly at
my home, forming a DSSI cluster which I power up from time to time (too
much noisy and hot for a home environment). I've tried to keep them in
working state (had to replace a fan in the 3300 and some minor stuff),
and they indeed work.
I got some vaxStations from eBay, and some other classical stuff (2 old
sun stations). I had diverse luck with those machines. I've got a
perfectly functioning VS 4000 mod. 60, and a broken VS 4000 mod 90
(that's unfortunate). The '90 has its NIC physically broken. It boots
but I can't network it, so its utility is limited (I don't own the
graphics display, and I've just got a VT320 which I have to switch
between all my boxen...). There is also a broken VS 3100; that machine
has a cache problem and does boot VMS; however it boots NetBSD (weird!).
I don't use it a lot, to say something :)
After I learnt the existence of HECnet researching some PDP11 stuff, I
asked Johnny to join. He has been -of course- very helpful, as well as
other members of the net, to whom I want to say thanks for the support.
Right now, area 7 is formed by these nodes:
7.6 MBSERV Linux Machine, host of my simulated boxen
7.60 BITXOV SIMH 3900 running openVMS 7.3
7.70 BITXOT SIMH PDP11 running RSTS/E 10.1
7.71 BITXOR SIMH PDP11 running RSXM+ 4.6
7.64 BITXO1 4000/200 running openVMS 7.3
7.65 BITXO2 3300 running openVMS 7.3
7.68 BITXO5 4000/60 running openVMS 7.3
I've got also some emulated PDP10 which I've not networked (yet). I'm
having trouble plugging into DECNET a TOPS20/Panda machine... If someone
could point me to any docs I would appreciate it a lot. I'm trying too
to DECNETize a TOPS10 running on a KLH10 simulated machine; this one
kinda works... I get the adjacency up messages but I can't talk to the
machine (neither FROM the machine). The only docs I've found are for the
7.03 version of the monitor, but I've got 7.04. Again, any pointers to
docs will be appreciated.
I'm still working on the setup. I intend to have the virtual machines up
most of the time. The physical ones are down most of the time, with the
exception of the 4000/60 (right now, it is up). I plan to add a SIMH 780
running VMS 4.7 soon. By the way, if someone could point me to pre-5.0
software kits I'd be very happy. I've got some stuff in the usual sites,
but I'd like to find BASIC, FMS, TDMS and BLISS for pre-5.0 VMS (I've
got the full CD consolidated distribution, circa 1992, and the hobbyist
kit so I've got covered the "modern" stuff :)). Same thing for RSX
software: I'd like to get a working COBOL (C81) for RSX11MPlus, as well
as DECNET for RSX11M (NOT plus). I really love to tinker with these
classical OSes :)
Well,tha'ts all for now. I've been reading the last message interchanges
in the list, and I think you could get a real boost to solve your
networking/interface sharing issues if you used VDE for the SIMH
machines. It's really easy to set up and you can do things like hooking
to your home DECnet network when you are on the road, using NATed
networks in which you can't control the port redirctions. Right now I'm
doing just that, extending my laptop "ethernet" to home using a ssh
tunneled vde plug thru a tethered iphone (whoa!). I've got the recipes
to make it work more or less automatically on ubuntu machines. If
someone is interested just ask.
Have a nice day, and enjoy!
On 06/07/2012 06:02 AM, Mark Benson wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
Yup, we are in agreement..."practically nonexistent". ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 10:32, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/07/2012 05:09 AM, Johnny Billquist wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 7 Jun 2012, at 10:09, Johnny Billquist <bqt at softjar.se> wrote:
Yeah, I'm also starting to wonder if we're talking about different things...
I wouldn't be surprised if I am totally across-purposes as I am just a
user with a little knowledge (and we all know about a little
knowledge?) in this argument.
Maybe someone can explain to me the worries they have with this "wide open" thing, and how that improves by having the bridge (or router) running on a separate machine?
As far as I see it, using pcap and promiscuous mode creates 2 potential issues:
Security is possibly compromised, but promiscuous mode is only
activated as root so rhis isn't a big concern.
There is an increase in traffic and filtering loads on the CPU because
the LAN interface is no longer filtering packets in hardware.
Using a separate 'appliance' to do the work presents these possible solutions:
There is nothing of import on the appliance so immediate security is
not a problem. Packets from or intended for other destinations can
still be sniffed but you still need root access to the device.
Traffic through the device and using the CPU to filter it is the
intended purpose of the 'appliance' thus it is not invading your other
tasks on a user-centric machine and it is also not compromised by
other heavy tasks absorbing CPU cycles for other things.
Indeed. In addition to the fact that I'm not clear what security threat we're talking about here...
It's minimal, but it shouldn't be totally ignored unless it's an
acceptable risk to the users concerned. Usual security caveats apply
i.e. use good passwords on the router device etc.
It's just anal-retentive perfectionism, nothing more, no REAL impact,
no REAL casualties...but it makes me sleep better at night, and I can
usually achieve it pretty much everywhere else. :)
No objections to that one. Except I don't loose sleep over a few CPU cycles here, since they are pretty much zero anyway. But like I said before, I don't mind clean stuff.
Again, shut it in a small box on it's own with a single-purpose OS and
it becomes a clean(er) solution.
--
Mark
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :)
My first computer (apart from the 8-bit home stuff) was a VAX-8250 running VAX/VMS 4.7. It was back in 1987, and it was a departamental machine which was going to replace a PDP11/60, which, regretabily, I didn't pay a lot of attention to. I was involved professionally with DEC machines until 1992. My "last" machine was a VAXServer 4000 mod. 200, which eventually ended living at my home :). I did plenty of stuff at that time, from system managing to application design (and programming). I had the pleasure to work with the DEC development environment, which I still miss these days: VAXSet, CDD, the consistent VAX Calling standard... I've not seen something so well integrated since those days.
Just to complete the picture, when I left the DEC environment, and after a short time working with DOS (fortunately it was a SHORT time) I ended working in the mainframe world, beginning in the applications programming area (PLI, IMS/DB-DC, DB2...) and ending in the systems programming area (mostly in the IMS environment). Right now I'm a "software architect", whatever that means.
As I said before, when my company got rid of that 4000/200 I toke care of it, as well as a uVAX 3300... those two machines now live happyly at my home, forming a DSSI cluster which I power up from time to time (too much noisy and hot for a home environment). I've tried to keep them in working state (had to replace a fan in the 3300 and some minor stuff), and they indeed work.
I got some vaxStations from eBay, and some other classical stuff (2 old sun stations). I had diverse luck with those machines. I've got a perfectly functioning VS 4000 mod. 60, and a broken VS 4000 mod 90 (that's unfortunate). The '90 has its NIC physically broken. It boots but I can't network it, so its utility is limited (I don't own the graphics display, and I've just got a VT320 which I have to switch between all my boxen...). There is also a broken VS 3100; that machine has a cache problem and does boot VMS; however it boots NetBSD (weird!). I don't use it a lot, to say something :)
After I learnt the existence of HECnet researching some PDP11 stuff, I asked Johnny to join. He has been -of course- very helpful, as well as other members of the net, to whom I want to say thanks for the support.
Right now, area 7 is formed by these nodes:
7.6 MBSERV Linux Machine, host of my simulated boxen
7.60 BITXOV SIMH 3900 running openVMS 7.3
7.70 BITXOT SIMH PDP11 running RSTS/E 10.1
7.71 BITXOR SIMH PDP11 running RSXM+ 4.6
7.64 BITXO1 4000/200 running openVMS 7.3
7.65 BITXO2 3300 running openVMS 7.3
7.68 BITXO5 4000/60 running openVMS 7.3
I've got also some emulated PDP10 which I've not networked (yet). I'm having trouble plugging into DECNET a TOPS20/Panda machine... If someone could point me to any docs I would appreciate it a lot. I'm trying too to DECNETize a TOPS10 running on a KLH10 simulated machine; this one kinda works... I get the adjacency up messages but I can't talk to the machine (neither FROM the machine). The only docs I've found are for the 7.03 version of the monitor, but I've got 7.04. Again, any pointers to docs will be appreciated.
I'm still working on the setup. I intend to have the virtual machines up most of the time. The physical ones are down most of the time, with the exception of the 4000/60 (right now, it is up). I plan to add a SIMH 780 running VMS 4.7 soon. By the way, if someone could point me to pre-5.0 software kits I'd be very happy. I've got some stuff in the usual sites, but I'd like to find BASIC, FMS, TDMS and BLISS for pre-5.0 VMS (I've got the full CD consolidated distribution, circa 1992, and the hobbyist kit so I've got covered the "modern" stuff :)). Same thing for RSX software: I'd like to get a working COBOL (C81) for RSX11MPlus, as well as DECNET for RSX11M (NOT plus). I really love to tinker with these classical OSes :)
Well,tha'ts all for now. I've been reading the last message interchanges in the list, and I think you could get a real boost to solve your networking/interface sharing issues if you used VDE for the SIMH machines. It's really easy to set up and you can do things like hooking to your home DECnet network when you are on the road, using NATed networks in which you can't control the port redirctions. Right now I'm doing just that, extending my laptop "ethernet" to home using a ssh tunneled vde plug thru a tethered iphone (whoa!). I've got the recipes to make it work more or less automatically on ubuntu machines. If someone is interested just ask.
Have a nice day, and enjoy!
On 06/07/2012 05:09 AM, Johnny Billquist wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2012-06-07 10:46, Dave McGuire wrote:
On 06/07/2012 04:40 AM, Mark Benson wrote:
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.
Hence my proposal to use a dedicated low-cost platform to perform the
work instead.
I like you feel uncomfortable having my main computers wide open so I
don't run it on my Mac Pro, MacBook or games PC. I have an old dual
PIII for Windows stuff and a HP Microserver and (soon to be numerous)
Raspberry Pi for Linux and a Atom D410 for NetBSD.
Ahh, we are talking about different things. I'm using a Cisco 7206VXR
as my DECnet router, but when I'm at my desk, I'm sitting in front of
this computer right here, and I ssh/telnet/dnlogin/llogin from here.
I'm talking about having direct DECnet support from here.
Yeah, I'm also starting to wonder if we're talking about different things...
Maybe someone can explain to me the worries they have with this "wide open" thing, and how that improves by having the bridge (or router) running on a separate machine?
Of course I could just bring up a virtual machine on the VMware host
down in the racks, but then I'd have to hop through that...not difficult
at all, but still very "unclean" to me.
Indeed. In addition to the fact that I'm not clear what security threat we're talking about here...
It's just anal-retentive perfectionism, nothing more, no REAL impact,
no REAL casualties...but it makes me sleep better at night, and I can
usually achieve it pretty much everywhere else. :)
No objections to that one. Except I don't loose sleep over a few CPU cycles here, since they are pretty much zero anyway. But like I said before, I don't mind clean stuff.
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
On 06/07/2012 03:50 AM, Johnny Billquist wrote:
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. ;)
Your machine is most likely wasting lots of cycles. You probably don't
even want to know... ;-)
Networks are slow, compared to CPUs.
A friend of mine wrote his PhD about the concept that you basically can
increase network bandwidth by just compressing data you want to send as
much as humanly possible for this simple reason. The CPU will wait on
data anyway, so why not use that time to compress the data to send,
which means you get more data through on the same network bandwidth.
In nearly all cases, yes I agree. Desktop OSs, even the "lean" ones,
are becoming fatter with each release though. And I do actually keep my
CPUs pretty busy, doing large compiles and PCB routing.
But, see my other mail, it is perfectionism more than fear of actual
visible impact. But on the other hand, this is my NEW desktop system,
less than a year old, and I used my last one for about seven years with
only minor upgrades...I get a lot of mileage out of my hardware.
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.
On 06/07/2012 04:40 AM, Mark Benson wrote:
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.
Hence my proposal to use a dedicated low-cost platform to perform the
work instead.
I like you feel uncomfortable having my main computers wide open so I
don't run it on my Mac Pro, MacBook or games PC. I have an old dual
PIII for Windows stuff and a HP Microserver and (soon to be numerous)
Raspberry Pi for Linux and a Atom D410 for NetBSD.
Ahh, we are talking about different things. I'm using a Cisco 7206VXR
as my DECnet router, but when I'm at my desk, I'm sitting in front of
this computer right here, and I ssh/telnet/dnlogin/llogin from here.
I'm talking about having direct DECnet support from here.
Of course I could just bring up a virtual machine on the VMware host
down in the racks, but then I'd have to hop through that...not difficult
at all, but still very "unclean" to me.
It's just anal-retentive perfectionism, nothing more, no REAL impact,
no REAL casualties...but it makes me sleep better at night, and I can
usually achieve it pretty much everywhere else. :)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 08:33, Dave McGuire <mcguire at neurotica.com>
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.
Hence my proposal to use a dedicated low-cost platform to perform the
work instead.
I like you feel uncomfortable having my main computers wide open so I
don't run it on my Mac Pro, MacBook or games PC. I have an old dual
PIII for Windows stuff and a HP Microserver and (soon to be numerous)
Raspberry Pi for Linux and a Atom D410 for NetBSD.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 2012-06-07 10:30, Mark Benson wrote:
On 7 Jun 2012, at 08:28, Johnny Billquist<bqt at softjar.se> wrote:
Dangerous in which way?
Promiscuous mode is considered a security risk because it can be used
to expose other packets not intended for viewing, which is why it's
restricted to root. BUT I, at least, am intending to use such a
service on a dedicated single purpose box, so that's not a big issue
for me.
Well, if you intend to run a bridge, router or whatever, you need to be root anyway, so from a security point of view, this is a non-issue.
Changing the MAC address also requires you to be root... :-)
But yes, normal users are not allowed to sniff the network, and even less so allowed to change the interface setup.
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.
I run both my Linux boxes with SimH running 24/7 and the interface in
promiscuous mode as a result. They are behind a gigabit switch Netgear
switch. The resulting extra network traffic as a result is... well non
existant. My network isn't exactly busy but there are other machines
on the switch that have constant traffic.
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.
This also occured to me. MAC address spoofing is pretty easy in most
UNIX variants unless it is strictly disallowed.
Right. And it's hard to disallow, since you need to be root to even inject an ethernet packet to begin with. At that point trying to prevent source spoofing is pointless.
The one environment where this is not possible is when you have hardware that enforce the source address. Such as the DEC ethernet controllers for PDP-11s... You cannot spoof the source MAC on those, as that is a piece of data that is inserted by the controller at the time of transmission...
Load is the one remaining reason to even worry, and that is a rather small worry for most people.
It's a risk anyone using DECnet via libpcap already accepts, anyway.
Yes. But load is the only real worry anyway. Security is not, in this case.
Johnny
On 7 Jun 2012, at 08:28, Johnny Billquist <bqt at softjar.se> wrote:
Dangerous in which way?
Promiscuous mode is considered a security risk because it can be used
to expose other packets not intended for viewing, which is why it's
restricted to root. BUT I, at least, am intending to use such a
service on a dedicated single purpose box, so that's not a big issue
for me.
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.
I run both my Linux boxes with SimH running 24/7 and the interface in
promiscuous mode as a result. They are behind a gigabit switch Netgear
switch. The resulting extra network traffic as a result is... well non
existant. My network isn't exactly busy but there are other machines
on the switch that have constant traffic.
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.
This also occured to me. MAC address spoofing is pretty easy in most
UNIX variants unless it is strictly disallowed.
Load is the one remaining reason to even worry, and that is a rather small worry for most people.
It's a risk anyone using DECnet via libpcap already accepts, anyway.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
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
On 2012-06-07 09:33, Dave McGuire wrote:
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.
Ok. Good. We're on the same page about where the potential problem lies then.
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. ;)
Your machine is most likely wasting lots of cycles. You probably don't even want to know... ;-)
Networks are slow, compared to CPUs.
A friend of mine wrote his PhD about the concept that you basically can increase network bandwidth by just compressing data you want to send as much as humanly possible for this simple reason. The CPU will wait on data anyway, so why not use that time to compress the data to send, which means you get more data through on the same network bandwidth.
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!
Right.
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.
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
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
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
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.
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
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.
