On Wed, 8 May 2013, Cory Smelosky wrote:
On Wed, 8 May 2013, Paul_Koning wrote:
On May 8, 2013, at 5:31 PM, Cory Smelosky wrote:
On Wed, 8 May 2013, Johnny Billquist wrote:
On 2013-05-08 03:36, Connor Youngquist wrote:
Hello,
I would like to request area 32 for my usage. I've been watching HECnet
for a while now, and I'm ready to jump in and start learning. Cory has
mentioned that he will assist me in setting up the proper connections.
So noted.
Johnny
I've almost got him connected...but!
%%%%%%%%%%% OPCOM 8-MAY-2013 17:29:29.93 %%%%%%%%%%%
Message from user DECNET on GEWT
DECnet event 4.19, adjacency down, operator initiated
On Wed, 8 May 2013, Paul_Koning wrote:
On May 8, 2013, at 5:31 PM, Cory Smelosky wrote:
On Wed, 8 May 2013, Johnny Billquist wrote:
On 2013-05-08 03:36, Connor Youngquist wrote:
Hello,
I would like to request area 32 for my usage. I've been watching HECnet
for a while now, and I'm ready to jump in and start learning. Cory has
mentioned that he will assist me in setting up the proper connections.
So noted.
Johnny
I've almost got him connected...but!
%%%%%%%%%%% OPCOM 8-MAY-2013 17:29:29.93 %%%%%%%%%%%
Message from user DECNET on GEWT
DECnet event 4.19, adjacency down, operator initiated
On May 8, 2013, at 5:31 PM, Cory Smelosky wrote:
On Wed, 8 May 2013, Johnny Billquist wrote:
On 2013-05-08 03:36, Connor Youngquist wrote:
Hello,
I would like to request area 32 for my usage. I've been watching HECnet
for a while now, and I'm ready to jump in and start learning. Cory has
mentioned that he will assist me in setting up the proper connections.
So noted.
Johnny
I've almost got him connected...but!
%%%%%%%%%%% OPCOM 8-MAY-2013 17:29:29.93 %%%%%%%%%%%
Message from user DECNET on GEWT
DECnet event 4.19, adjacency down, operator initiated
On Wed, 8 May 2013, Johnny Billquist wrote:
On 2013-05-08 03:36, Connor Youngquist wrote:
Hello,
I would like to request area 32 for my usage. I've been watching HECnet
for a while now, and I'm ready to jump in and start learning. Cory has
mentioned that he will assist me in setting up the proper connections.
So noted.
Johnny
I've almost got him connected...but!
%%%%%%%%%%% OPCOM 8-MAY-2013 17:29:29.93 %%%%%%%%%%%
Message from user DECNET on GEWT
DECnet event 4.19, adjacency down, operator initiated
On May 8, 2013, at 5:14 PM, Dennis Boone wrote:
Yes, I saw the DECnet/Linux code. It's rather puzzling because it seems
to tie into a tun/tap device -- so it expects Ethernet behavior. But
then it converts to short headers, which suggests point to point
behavior. Which is it? The data headers are only a tiny part of the
difference between the two datalink flavors...
If I understood it correctly when I looked at it a while back, Multinet
uses the DECNET point-to-point frame format in the UDP packets it
exchanges with the remote. But Linux DECNET is unlikely to have any
real hardware point-to-point links, and quite reasonably expects any
frames from the local LAN (including those on e.g. a Linux virtual
bridge from a simh instance running locally) to be in the broadcast
format used by DECNET if its interface is an ethernet. Linux DECNET
therefore converts between the two formats as necessary.
Once I got past that, I was able to follow what was going on in packet
captures based on how the Linux multinet program shuffled around array
elements.
Thanks everyone, I believe I got it now.
paul
Yes, I saw the DECnet/Linux code. It's rather puzzling because it seems
to tie into a tun/tap device -- so it expects Ethernet behavior. But
then it converts to short headers, which suggests point to point
behavior. Which is it? The data headers are only a tiny part of the
difference between the two datalink flavors...
If I understood it correctly when I looked at it a while back, Multinet
uses the DECNET point-to-point frame format in the UDP packets it
exchanges with the remote. But Linux DECNET is unlikely to have any
real hardware point-to-point links, and quite reasonably expects any
frames from the local LAN (including those on e.g. a Linux virtual
bridge from a simh instance running locally) to be in the broadcast
format used by DECNET if its interface is an ethernet. Linux DECNET
therefore converts between the two formats as necessary.
Once I got past that, I was able to follow what was going on in packet
captures based on how the Linux multinet program shuffled around array
elements.
De
You're thinking what I'm thinking, aren't you? :)
-brian
On May 8, 2013, at 16:32, <Paul_Koning at Dell.com> wrote:
Gentlepeople,
I gather the "multinet" protocol is how much of hecnet is tied together. Is that right? Is there a protocol description for it, or code that implements it?
I vaguely remember reading that there's simh support for it, but I don't see it.
paul
On May 8, 2013, at 4:51 PM, Dennis Boone wrote:
I gather the "multinet" protocol is how much of hecnet is tied
together. Is that right? Is there a protocol description for it, or
code that implements it?
It wraps decnet frames in udp frames, typically on port 700. The linux
decnet package has an implementation of it, and the source is reasonably
easy to follow.
I think I figured it out. The DECnet/Linux code is in dnprogs, file multinet.c
It's quite a hack. DECnet/Linux apparently only supports Ethernet datalinks. Or at least the multinet stuff hooks into the Ethernet machinery (via a tun/tap port). But it converts the packet stream into the point to point flavor of the protocol, at least a close enough approximation that it basically works.
Ok, that helps, because it basically means I need to do another point to point link (closely analogous to the simh DDCMP emulation).
One detail is unclear: it looks like the first four bytes of the datagram are a 2 byte sequence number followed by 2 bytes of padding. The code isn't doing anything with the sequence number on receipt. And it doesn't ever seem to reset the sequence number. So what, if anything, is it used for?
Part of the puzzle is that the DECnet routing spec requires point to point links not to lose packets -- which DDCMP guarantees. UDP does not, obviously. It doesn't even guarantee sequential delivery. And while DECnet can deal reasonably well with lost packets, reordered packets on a datalink are not something the state machine was designed for. I suppose that real world packet loss/reordering rates are low enough that it works well enough by the standards of the people who invented this scheme, even though it wouldn't have passed muster in the DECnet architecture team...
paul
Point to point or Ethernet-like?
I can't speak for the implementation, but from DECnet's point of view a
Multinet link is a point to point connection. A Multinet link connects
exactly one VMS host to exactly one other VMS host - it's not a multi host
bus connection like Ethernet.
Of course DECnet can route traffic thru a Multinet link just like it'd
route thru any other point to point connection, so DECnet machines on one
LAN can see DECnet machines on the remote LAN as long as the two Multinet
connected hosts are DECnet routers.
Bob
On May 8, 2013, at 4:43 PM, Bob Armstrong wrote:
I vaguely remember reading that there's simh support for it, but I don't
see it.
I don't think there's any specific simh support for a Multinet port, but
you can of course run Multinet "thru" simh (i.e. install Multinet on a simh
VAX/VMS system and tunnel DECnet thru the simh emulated Ethernet
controller).
I assume you're asking about a simh invention that talks to a remote
Multinet VAX/VMS system on the simh host side and pretends to be some other
device (like a DMR/DUP/DMV/whatever) on the simulated side - I've never seen
anything like that.
DECnet/Linux can supposedly emulate a Multinet tunnel. Is that what
you're thinking of? But in that case you're running DECnet on the Linux
host and simh has nothing to do with it.
I want to learn how to make my DECnet speak Multinet. Rob mentioned wanting to do the same for his "user mode router". So it would be another DECnet datalink. Point to point or Ethernet-like?
Yes, I saw the DECnet/Linux code. It's rather puzzling because it seems to tie into a tun/tap device -- so it expects Ethernet behavior. But then it converts to short headers, which suggests point to point behavior. Which is it? The data headers are only a tiny part of the difference between the two datalink flavors...
paul
