At 11:54 AM +0100 2/16/10, Johnny Billquist wrote:
When a packets is sent from machine B it goes to the switch. The switch
either sees a broadcast packet, and forwards it to all ports, or a
packet for a specific MAC address, and forwards it to the port of
machine A.
Well, I suppose the bridge had announced over the LAN that it is DECNET
nodes such, then machine B "believes" A hosts those nodes, right? So the
bridge has NOT to sniff unicast traffic, because packets are addressed to
it.
When a packet is received by machine A by the bridge from another place,
the bridge program then injects the ethernet packet on the local
network.
Catched it.
No need for EDT clones when you have EDT... :-)
EDT is excellent but being jailed to 24 lines is terrible nowdays.
We also have a TU77 and a TU78. But for those I need to
connect and fix things up.
The TU81 can do fit. I've seen it on your pictures.
We have succesfully recovered data from DC600 cartridges written circa 90,
but my tapes were written in 1985 so chances are low. They have been stored
in a dry and cold place, however.
The 11/60 don't need 3-phase.
I'm puzzled here.
A general question: this is HECNET list, are non-networking RSX questions
off topic? I have a lot, but i don't want to bother :-)
--
Jean-Yves Bernier
Just a followup on my pcap problems.
Trying the actual ethernet port works just fine.
So there is nothing seriously wrong with libpcap on MAC OS X.
So my only problem now is why tcpdump manages to capture more packets
than I do when I run over wireless. But I'll save that for another day...
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
Hi.
Jean-Yves Bernier wrote:
At 12:48 AM +0100 2/16/10, Johnny Billquist wrote:
Hi, Jean. Looks like we could have some fun... ;-)
I'm sure we can.
[sniffing DECNET packets]
That is only as to be expected, and you cannot draw any conclusions from that.
Except I have to buy a managed switch if I want to join HECNET. NETGEAR has
a small, inexpensive 5-port Gigabit with port mirorring, the GS105E, and I
like their little blue boxes.
Uh? Why?
Let me put it this way:
Machine A talks TCP/IP, and runs bridge. It has one ethernet connection
to a switch.
Machine B talks DECnet. It has one connection to the switch.
Machine C is your router/firewall/whatever, that talks to the outside
world. It also have a connection on the switch.
When a packets is sent from machine B it goes to the switch. The switch
either sees a broadcast packet, and forwards it to all ports, or a
packet for a specific MAC address, and forwards it to the port of
machine A. The bridge program on machine A receives the packet, and
sents it via UDP to another bridge. Done. All works as expected.
When a packet is received by machine A by the bridge from another place,
the bridge program then injects the ethernet packet on the local
network. The switch sees the packet from machine A, with a mac source
address which is actually the address of whatever DECnet machine that
*really* originated the packet. The switch stores this address for
future use, and forwards the packet to machine B, assuming that was the
destination of it.
All works as expected.
After a while, the switch will have a whole bunch of DECnet machines
that it thinks are all located on the same port as machine A. All is
good, because from the switches point of view, this is correct.
More editors would always be fun.
That was one of the first programs I've written for the PDP-11, before EDT
existed, to get rid of those pesky line editors. I miss it because it could
handle more than 24 lines. We had a full-page VT with 60 or so lines i
can't remember the brand, and that was a real delight compared to the
TV100s.
Facit Twist? I think it ran as 24x80 or 72x80.
I have found 3 portable EDT clones on the Internet, see bottom of page:
http://en.wikipedia.org/wiki/EDT_(text_editor)
No need for EDT clones when you have EDT... :-)
One of them is written in pre-ANSI C (func(a, b) int a, b;) but the best
candidate to porting is written with ANSI prototypes. I have the old DECUS
C, invoked by C.. with the proto thing (CN.PRO). Although the proto refers
to a 'std' flag, pretending to "force the input to conform to ANSI C draft
standard", this doesn't work. I've tried with your version this afternoon
(XCC on MIME) with a same result.
Oh well... :-)
By the way, there is also a ANSI C compiler on MIM... Just invoke with CC.
I'm trying to use Linux's deprotoize tool to pre-process the source.
If you have 1/2" tapes you want read, I can do that.
I have a 11/70 with a TU81 ready for such occasions. :-)
A REAL TU81? I can't believe it... Perhaps you can save my tapes.
No problema. We also have a TU77 and a TU78. But for those I need to
connect and fix things up.
Here is my regretted 11/60: http://www2.pescadoo.net/pdp/11-60.jpg with
dual RK07, home-build A/D and D/A, 2 RP storing (imagine that) 20 minutes
of stereo sound each, well before the Compact Disc. It has been donated to
a school, which could never power it up, lacking a tri-phase power supply.
The 11/60 don't need 3-phase. I used to play extensively with an 11/60
25 years ago. Ahhh... Memories...
I still have an extra set of CPU boards for an 11/60 lying around.
I was assuming matapes were a safe backup. I learned that paper was better,
as the only piece of software which survived is the listing of a terminal
driver.
:-)
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
At 12:48 AM +0100 2/16/10, Johnny Billquist wrote:
Hi, Jean. Looks like we could have some fun... ;-)
I'm sure we can.
[sniffing DECNET packets]
That is only as to be expected, and you cannot draw any conclusions from that.
Except I have to buy a managed switch if I want to join HECNET. NETGEAR has
a small, inexpensive 5-port Gigabit with port mirorring, the GS105E, and I
like their little blue boxes.
More editors would always be fun.
That was one of the first programs I've written for the PDP-11, before EDT
existed, to get rid of those pesky line editors. I miss it because it could
handle more than 24 lines. We had a full-page VT with 60 or so lines i
can't remember the brand, and that was a real delight compared to the
TV100s.
I have found 3 portable EDT clones on the Internet, see bottom of page:
http://en.wikipedia.org/wiki/EDT_(text_editor)
One of them is written in pre-ANSI C (func(a, b) int a, b;) but the best
candidate to porting is written with ANSI prototypes. I have the old DECUS
C, invoked by C.. with the proto thing (CN.PRO). Although the proto refers
to a 'std' flag, pretending to "force the input to conform to ANSI C draft
standard", this doesn't work. I've tried with your version this afternoon
(XCC on MIME) with a same result.
I'm trying to use Linux's deprotoize tool to pre-process the source.
If you have 1/2" tapes you want read, I can do that.
I have a 11/70 with a TU81 ready for such occasions. :-)
A REAL TU81? I can't believe it... Perhaps you can save my tapes.
Here is my regretted 11/60: http://www2.pescadoo.net/pdp/11-60.jpg with
dual RK07, home-build A/D and D/A, 2 RP storing (imagine that) 20 minutes
of stereo sound each, well before the Compact Disc. It has been donated to
a school, which could never power it up, lacking a tri-phase power supply.
I was assuming matapes were a safe backup. I learned that paper was better,
as the only piece of software which survived is the listing of a terminal
driver.
--
Jean-Yves Bernier
Hi, Jean. Looks like we could have some fun... ;-)
Jean-Yves Bernier wrote:
At 7:59 PM +0100 2/15/10, Johnny Billquist wrote:
I'll try with a cable tonight to see if that works better than wireless...
I was busy unprotoizing some C sources to feed the pre-ANSI DECUS C
compiler. Since I see you are working on the bridge, I have made some
further tests tonight.
Hmm. The DECUS C compiler have some nice corners, but much of it is a
headache. I'm trying to remember if I ever published all my patches and
fixes for it. I made it work fine with split I/D-space, extended it a
little, and fooled around in general a number of years ago...
One thing I forgot to mention in my previous mail : On Mac OS/darwin, eth0
is enO.
So, bridge.conf must contain 'local en0'.
Correct. And en1 is normally the wireless port, but these can be changed
if the user is "creative".
However, it is just a string in the config file, so the most important
thing is just to get it right, and then you don't have to think about it.
In NetBSD (for instance) the ethernet ports can be many different
strings, but most definitely are not ever either eth<n> or en<n>. So it
can differ by a lot depending on what OS you are using.
The program I use is not your bridge but a very similar one, intended to
see how much work it would be for a Unix box to pretend to be a DECNET
node. Indeed, I copied your pcap initialization part, filter included, then
added my code.
Assume
machine A running node 1.1,
machine B running node 1.2,
machine C running nothing,
all on a wired, switched LAN.
When my program is running on machine C, I see all broadcast packets:
Router-hello l2rout (DECNET packets, size 60)
Lev-1-routing (DECNET packets, size 386 and 590x)
Lev-2-routing (DECNET packets, size 152)
A few LAN packets, size 60.
Since I am on a switched network, I see none of the unicast packets, for
example when I initiate a DECNET transfer between A and B.
When my program is running on machine B, I see:
Same packets as above (pcap_setdirection was called with PCAP_D_INOUT).
Packets identified as data, data-ack, link-service, ils-ack by tcpdump.
That is only as to be expected, and you cannot draw any conclusions from
that. Since you have a switch, it will only forward unicast packets to
the port where the actual recipient is located, as soon as it have learned.
This is all based on mac addresses.
On my machine I have, as I have written, noticed that the packets I see
with tcpdump differ from the packets I see in the bridge.
These are all broadcast packets, by the way...
Until now, I have not seen a packet in tcpdump I have not seen in my
program, which is basically yours for the pcap part. By the way, I'm
looking for a document describing DECNET frames to dive a little deeper in
that way. Any pointer will be appreciated.
The whole basics of DECnet is in the public domain. Look through
bitsavers for instance. Or just google for the documentation.
All tests use Apple's libpcap.dylib in /usr/lib, NOT libpcap.a in
/usr/local/lib which was required to install simh on Mac OS X. I'm running
Tiger, so you should have no problems using Leopard.
Yes, unless some problem have been introduced in Snow Leopard... :-)
Well, I realize that this is my first contribution to this list and maybe a
short introduction is due. Here we go...
I have been working with RSX-11M from '80 to '87. First in computer music
research (GRM, Paris), then in pre-press/phototypesetting. Some old systems
have been donated to me, noticeably SMS (Scientific Micro Systems) OEM
LSI-11/73.
Fun!
As a hobby project, i've resurrected these systems, then linked them to
simh via DECNET. A few details of the project here, unfortunately in french
but I'm sure you will enjoy SEAGATE surgery http://www2.pescadoo.net/pdp/
and maybe DC600 meltdown:
http://www2.pescadoo.net/pdp/photos/TANDBERG/P1010012.JPG
Unfortunately, any interesting RSX software I could share (yet another full
screen editor, a hierarchical filesystem for RSX and some funny drivers)
are locked on a set of magtapes I did not manage to backup before the day
tape drives lifted off earth for an secret destination. So is life...
If you have 1/2" tapes you want read, I can do that.
I have a 11/70 with a TU81 ready for such occasions. :-)
(That's MAGICA:: by the way - (1.1))
More editors would always be fun. As for hierachical file system, I have
a patch set for RSX to get full hierachical file system support. The
ODS-1 structure don't have any problems with that, so it's mostly a
qustion of changing the reserved size for directory strings, and
changing the directory lookup routine in FCS, and some filename parsing
code.
I originally did that work for RSX-11M-PLUS V4.3, but have applied it to
4.6 as well. It should be on ftp:://ftp.update.uu.se/pub/pdp11/rsx if
you look around.
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
At 7:59 PM +0100 2/15/10, Johnny Billquist wrote:
I'll try with a cable tonight to see if that works better than wireless...
I was busy unprotoizing some C sources to feed the pre-ANSI DECUS C
compiler. Since I see you are working on the bridge, I have made some
further tests tonight.
One thing I forgot to mention in my previous mail : On Mac OS/darwin, eth0
is enO.
So, bridge.conf must contain 'local en0'.
The program I use is not your bridge but a very similar one, intended to
see how much work it would be for a Unix box to pretend to be a DECNET
node. Indeed, I copied your pcap initialization part, filter included, then
added my code.
Assume
machine A running node 1.1,
machine B running node 1.2,
machine C running nothing,
all on a wired, switched LAN.
When my program is running on machine C, I see all broadcast packets:
Router-hello l2rout (DECNET packets, size 60)
Lev-1-routing (DECNET packets, size 386 and 590x)
Lev-2-routing (DECNET packets, size 152)
A few LAN packets, size 60.
Since I am on a switched network, I see none of the unicast packets, for
example when I initiate a DECNET transfer between A and B.
When my program is running on machine B, I see:
Same packets as above (pcap_setdirection was called with PCAP_D_INOUT).
Packets identified as data, data-ack, link-service, ils-ack by tcpdump.
Until now, I have not seen a packet in tcpdump I have not seen in my
program, which is basically yours for the pcap part. By the way, I'm
looking for a document describing DECNET frames to dive a little deeper in
that way. Any pointer will be appreciated.
All tests use Apple's libpcap.dylib in /usr/lib, NOT libpcap.a in
/usr/local/lib which was required to install simh on Mac OS X. I'm running
Tiger, so you should have no problems using Leopard.
Well, I realize that this is my first contribution to this list and maybe a
short introduction is due. Here we go...
I have been working with RSX-11M from '80 to '87. First in computer music
research (GRM, Paris), then in pre-press/phototypesetting. Some old systems
have been donated to me, noticeably SMS (Scientific Micro Systems) OEM
LSI-11/73.
As a hobby project, i've resurrected these systems, then linked them to
simh via DECNET. A few details of the project here, unfortunately in french
but I'm sure you will enjoy SEAGATE surgery http://www2.pescadoo.net/pdp/
and maybe DC600 meltdown:
http://www2.pescadoo.net/pdp/photos/TANDBERG/P1010012.JPG
Unfortunately, any interesting RSX software I could share (yet another full
screen editor, a hierarchical filesystem for RSX and some funny drivers)
are locked on a set of magtapes I did not manage to backup before the day
tape drives lifted off earth for an secret destination. So is life...
--
Jean-Yves Bernier
That's the one!
I'm hoping to get the most interesting talks and demos recorded in HD video to susequently upload to the internet. So hopefully anyone who misses the day will still get to share some of the fun.
Jason Stevens wrote:
This event, right?
http://wickensonline.co.uk/declegacy/
sigh i think I picked the wrong month to be in the UK....
On Mon, Feb 15, 2010 at 2:29 PM, Mark Wickens <mark at wickensonline.co.uk <mailto:mark at wickensonline.co.uk>> wrote:
Hi guys,
I've now secured an internet connection for the DEC Legacy event
in April and wanted to pick your collective brains about what
might be interesting to hecnet hobbyists who won't be able to
attend the event if we can get some of the machines that will be
in attendance connected up to hecnet on the day.
A couple of my machines will be there - probably the VAX 4000/90
and either the DEC 3000/600 or the ZX6000 itanium workstation -
I'm presuming I'll need to supply an updated IP address for Jonny
to patch me in given that my bridge will be on a different IP
address? Also, would it be possible for those attendees who've not
been connected previously to get connected up on the day, given
that they won't have to worry about the bridge setup?
Would anyone fancy participating in a coding competition? Anyone
have any other suggestions?
Kind regards, Mark.
This event, right?
http://wickensonline.co.uk/declegacy/
sigh i think I picked the wrong month to be in the UK....
On Mon, Feb 15, 2010 at 2:29 PM, Mark Wickens <mark at wickensonline.co.uk> wrote:
Hi guys,
I've now secured an internet connection for the DEC Legacy event in April and wanted to pick your collective brains about what might be interesting to hecnet hobbyists who won't be able to attend the event if we can get some of the machines that will be in attendance connected up to hecnet on the day.
A couple of my machines will be there - probably the VAX 4000/90 and either the DEC 3000/600 or the ZX6000 itanium workstation - I'm presuming I'll need to supply an updated IP address for Jonny to patch me in given that my bridge will be on a different IP address? Also, would it be possible for those attendees who've not been connected previously to get connected up on the day, given that they won't have to worry about the bridge setup?
Would anyone fancy participating in a coding competition? Anyone have any other suggestions?
Kind regards, Mark.
Hi guys,
I've now secured an internet connection for the DEC Legacy event in April and wanted to pick your collective brains about what might be interesting to hecnet hobbyists who won't be able to attend the event if we can get some of the machines that will be in attendance connected up to hecnet on the day.
A couple of my machines will be there - probably the VAX 4000/90 and either the DEC 3000/600 or the ZX6000 itanium workstation - I'm presuming I'll need to supply an updated IP address for Jonny to patch me in given that my bridge will be on a different IP address? Also, would it be possible for those attendees who've not been connected previously to get connected up on the day, given that they won't have to worry about the bridge setup?
Would anyone fancy participating in a coding competition? Anyone have any other suggestions?
Kind regards, Mark.
Yes, the #if stuff I have had to adapt for OS X as well.
I'll try with a cable tonight to see if that works better than wireless...
Johnny
Jean-Yves Bernier wrote:
At 2:17 AM +0100 2/15/10, Johnny Billquist wrote:
Do anyone have experience with Apples pcap library? It is supposed to be
a plain bsd pcap, but I have a problem that I haven't figured out yet,
and thought that maybe someone here already knows, so I don't have to go
figure it out myself.
I have your bridge working on Mac OS X.
I forced
#define __FreeBSD__
to get
ioctl(BIOCIMMEDIATE, BIOCSHDRCMPLT) compiled.
I get the same packets as tcpdump, that is:
- broadcasts from all nodes, if I run on a distinct machine (no simulator)
router-hello, lev-1-routing, lev-2-routing
- broadcasts and unicasts to me, if I run on a machine hosting a simulator
link-service, data-ack, ils-ack, data
I am on a switched network with unmanaged switches, so i'm unable to sniff
all traffic for the moment.
