On 8 Jun 2012, at 16:58, Steve Davidson wrote:
PATHWORKS for MAC V1.3...
That's one option. Alternatively, I have White Pine Softwares Mac320 Terminal emulation package in a box on my shelf (original complete and working) which includes Thursby's DECnet stack, TSSnet (although I don't think/know if it is capable of file sharing in the Mac320 package). It works well as a terminal program but it's pretty antiquated and barely works on Macintosh System 7.0 (it was originally designed for Macintosh System 6.0). I have it installed on my SE/30 50MHz and it did okay. Wasn't anything special though.
Some guy gave me that about 12 years ago. I had no idea what it was but he insisted. Kind a cool I eventually got to use it :)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On Jun 8, 2012, at 10:50 AM, Johnny Billquist wrote:
On 2012-06-08 16:42, Paul_Koning at Dell.com wrote:
...
That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do.
Interesting. I wasn't aware that NICs had filters that didn't make a difference between multicast and unicast anymore... Seems potentially bad if you start using IP multicast, since that can easily become a whole bunch of multicast addresses, and then I guess you'll have to turn on promiscuous mode anyway.
A typical modern NIC has (a) a modest-sized list of exact match filters, (b) a hash (CRC) based multicast filter, and usually (c) a separate flag to enable broadcast. So if you have at most, say, 16 unicast + multicast addresses enabled, it uses (a); if you have at most 16 unicast but too many multicast addresses, it uses (b) to do an approximate filter of the multicasts with the exact match done in the driver, and if you ask for more than 16 unicasts it will tell you that it can't do that.
The old DEC controllers for PDP-11s have a list of multicast addresses that you want to receive, so they do filter on multicast, but that list is for multicast only. There is only one unicast address.
(Those controllers also have a separate multicast promiscuous mode, except it don't work on the DEQNA and DELQA...)
Johnny
That's not quite true. DEC, not surprisingly, was the first to identify the need for multiple unicast support in NICs, so the DECnet Ethernet datalink spec calls for it and all except the very oldest DEC NICs support that. Specifically, QNA and LQA do, because they take a 16 entry address filter. The QNA manual says that you put in the MAC address, broadcast, multicast addresses, plus extra copies of the MAC address, but in fact the device is perfectly happy to accept additional individual addresses. I believe VMS (and possibly other OSs) took advantage of this to allow LAT to come up first with the ROM based MAC address, then enable DECnet with its address without disturbing LAT.
paul
I wonder if that'll run in Basilisk - could pop up an emulated 68k classic System Mac on HECnet too..
Sampsa
On 8 Jun 2012, at 16:58, Steve Davidson wrote:
PATHWORKS for MAC V1.3...
-Steve
On Fri, Jun 08, 2012 at 12:32:04PM +0100, Peter Coghlan wrote:
(How come I can remember this stuff and I have trouble remembering what
happened yesterday!)
That condition is a "medical" impairment whereby your brain is unable to
successfuly transfer information from short term memory to long term memory,
because you have a combination of too many toxins and not enough of the necessary
nutrients to support building new neuronal pathways. Modern toxins are:
MonoSodium Glutamate, Aspartame, Fluoride, Cesium, Plutonium, Uranium, etc...
and the nutrients you need are not likely in the modern version of what people
mistakenly call "food" but is mostly devoid of anything due to soil depletion.
An example of something intended to help people like you (including all of us)
is "cognition ignition" product from http://www.nutrimedical.com/
I have no relationship with Dr. Deagle's operations other than that I am a
customer of some of his products. He is a leader in anti-aging research.
Since mostly only us old-school old-farts care about DECtech, I considered
the relevancy factor high enough here to venture a bit "off topic".
--
Aloha, Avination: Celestial Angela; 2ndLife: Celeste Python; Angela Kahealani
"(I'll) Be Seeing You..." All information and transactions are private between
the parties, and are non negotiable. All rights reserve without prejudice by
Angela Kahealani http://www.kahealani.com/kahealani/angela_kahealani.html
PATHWORKS for MAC V1.3...
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Gregg Levine
Sent: Friday, June 08, 2012 11:09
To: hecnet at update.uu.se
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
On Fri, Jun 8, 2012 at 4:06 AM, Sampsa Laine <sampsa at mac.com> wrote:
On 8 Jun 2012, at 00:10, Dave McGuire wrote:
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.
The upside of this solution is that it's relatively
portable though - I'd love to have a DECNET stack on my OS X
boxes, for example (in fact as mentioned before latd DOES
work on OS X as it's kinda implemented in a similar way)..
Sampsa
Hello!
At one point in time, the OS for the Mac did speak natively
to the DEC family of hardware. It would be very interesting
to find out how they did it. This would greatly benefit
Sampsa at least.
As for us? Excellent question.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Fri, Jun 8, 2012 at 11:21 AM, Mark Benson <md.benson at gmail.com> wrote:
On 8 Jun 2012, at 16:09, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
Hello!
At one point in time, the OS for the Mac did speak natively to the DEC
family of hardware.
Do you mean OS X ir Classic Mac OS?
It would be very interesting to find out how they
did it. This would greatly benefit Sampsa at least.
If it's OS X It'd benefit me too provided it still works on modern versions.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Hello!
Oh okay. Consider this, it was for the classic Mac. And the big guys.
Shortly before the PowerPC processor was released. I remember going to
a trade show that showed just such a network being there. They had
everything named, including a VAX named VAX Masterston. I pointed out
that the original name retired from being a gunfighter and ended up
becoming a New York sportswriter.
He died soon after that and ended up in Woodlawn. I can't recall if he
was present at that gunfight.
All of that took place sometime in the late 80s.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 8 Jun 2012, at 16:09, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
Hello!
At one point in time, the OS for the Mac did speak natively to the DEC
family of hardware.
Do you mean OS X ir Classic Mac OS?
It would be very interesting to find out how they
did it. This would greatly benefit Sampsa at least.
If it's OS X It'd benefit me too provided it still works on modern versions.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On Fri, Jun 8, 2012 at 4:06 AM, Sampsa Laine <sampsa at mac.com> wrote:
On 8 Jun 2012, at 00:10, Dave McGuire wrote:
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.
The upside of this solution is that it's relatively portable though - I'd love to have a DECNET stack on my OS X boxes, for example (in fact as mentioned before latd DOES work on OS X as it's kinda implemented in a similar way)..
Sampsa
Hello!
At one point in time, the OS for the Mac did speak natively to the DEC
family of hardware. It would be very interesting to find out how they
did it. This would greatly benefit Sampsa at least.
As for us? Excellent question.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 2012-06-08 16:42, Paul_Koning at Dell.com wrote:
On Jun 8, 2012, at 2:00 AM, Johnny Billquist wrote:
On 2012-06-08 01:13, Dave McGuire wrote:
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...?
Yes. Well, actually I wasn't describing it in a more abstract way, but in a way more in terms of why you need promiscuous mode instead of what it actually does on the interface.
But reading it through now, I see that there was one implicit assumption in my text which I could have pointed out.
If you need to share the device with the system, while using a different MAC address, you need to place the device in promiscuous mode. And such is the case if we talk DECnet, since DECnet requires that you use a specific MAC address which is not the same as the default MAC address of a device.
That's true if you have a NIC and driver that only allows one individual address per physical MAC. Most modern NICs allow multiple individual addresses since the address filter is an exact match on N (say, 16 or so) addresses, and it doesn't care whether those are individual or multicast. The host OS drivers may or may not export that feature. If they do, then you don't need promiscuous mode. If they don't, or if the NIC is old enough that it can't do this, then you do.
Interesting. I wasn't aware that NICs had filters that didn't make a difference between multicast and unicast anymore... Seems potentially bad if you start using IP multicast, since that can easily become a whole bunch of multicast addresses, and then I guess you'll have to turn on promiscuous mode anyway.
The old DEC controllers for PDP-11s have a list of multicast addresses that you want to receive, so they do filter on multicast, but that list is for multicast only. There is only one unicast address.
(Those controllers also have a separate multicast promiscuous mode, except it don't work on the DEQNA and DELQA...)
Johnny