linux-decnet-user — Discussion for users of DECnet on Linux

[Linux-decnet-user] RFC: The loopback device in 2.5 kernels

[Steven W. <st...@gw...>]

Hi,

Here is an RFC on a rather unusual topic... I've been looking into the
requests recently to make the DECnet addresses of devices more easily
configurable. I've currently got a work-in-progress patch with the
following changes from 2.5.36:

 o The autoconfig function for ethernet devices has been changed so that any
   ethernet device with hiord in its MAC address will gain a DECnet address to
   match when the device is brought up.

 o Any ethernet device which has a DECnet address added to it, will also
   add the correct (unicast) MAC address to its multicast list in the case
   that the MAC address isn't the same as the device MAC address.

 o The output packet code has been tweeked to take account of these changes
   by ensuring that it uses the correct source address for packets.

 o The hello code has been tweeked so that every configured address for an
   interface will result in a hello message being sent out (with the
   correct contents).

Currently the decision about sending router or endnode hellos is left as
a "per interface" option. Clearly it seems to make sense to move this
toward a "per address" option in the future, but I want to think a bit
more about the interactions between the different addresses on an interface
before I do that.

So the RFC in this case relates to two things, namely the only two places
in which the decnet_address variable as configured on the kernel command
line is still used.

 1. In autoconfiguration of the loopback device. There must be a better way
    of doing this. I know Linux is unique in this slightly odd method of
    using a loopback device for DECnet, but it does have the advantage of
    being able to reuse a lot of the TCP/IP code for routing.

    One solution might be to autoconfigure the loopback device with every
    address which is added to other interfaces in the system. It sounds
    easy, but will in fact cause a fairly large code change.

    Another solution is just to ignore it. We could force people to add
    the addresses to the loopback device manually using iproute2.

    So this is the main area where I'm asking for ideas of how we should
    proceed.

 2. In autobind, the decnet_address variable is used to give us a default
    local address to bind to. We could do something really simple, such as
    bind to the first address on the loopback device by default, or we
    could leave the decnet_address variable for just this one purpose.
    It would be nice if we could in fact bind to something like DNADDR_ANY
    for example so that we can make the source address decision later. This
    would need the fixing of prefsrc in the routing code though.

    Again all ideas are welcome.

So I hope this makes some kind of sense :-) Let me know if you have any
questions in case I've not explained things very well. I hope to come up
with a patch in the next few days for testing and eventual submission to
the 2.5 kernel series. I'm not intending to back port any part of this
work to the 2.4 kernels at least until this is working and tested in 2.5
and only then if there is a demand for it and if I can ensure its 100%
backward compatible.

Steve.

RE: [Linux-decnet-user] Command line access to NCL

[Anderson, A. <A.A...@hp...>]

Hi,

In addition to all that Colin mentioned there is the need to compile the =
DECnis ncl script into a CMIP file.  This can only be done on VMS or =
Tru64 unix or a PC with the DECnis kit installed.  Then the DECnis needs =
to have a load host.  Even if you use flash now, some day you may need =
to modify the configuration recompile the ncl script into a cmip and =
reload.  Or maybe you need to replace a failing cpu card.  So you need =
to reload.  In any case you need a VMS or Tru64 Unix or a PC as a DECnis =
management station around.   =20

I have run into numerous situations where the DECnis/wanrouter load host =
was deinstalled sold or scrapped then a summer storm comes along and the =
UPS system runs low......  Poof no more wide area network.  Be vary =
carefull what you wish for.

All this software was sold to a subsidary of Cabletron (www.dnpg.com) =
before Compaq bought Digital.

Alan Anderson



-----Original Message-----
From: Colin Butcher [mailto:col...@xd...]
Sent: Thursday, September 19, 2002 8:04 AM
To: Linux-Decnet-User@Lists. Sourceforge. Net
Subject: RE: [Linux-decnet-user] Command line access to NCL


NCL is the command line interface with DECnet/OSI & DECnet-Plus, aka
DECnet Phase V. DECnis etc. use it for remote management. Since the =
Linux
DECnet implementation is Phase IV the answer must be no.

DECnis routers don't really do remote console or anything much like =
that,
so you'll need to retain a DECnet Phase V machine to manage them =
remotely
over the network.

If you're looking to replace DECnet Phase V machines with Linux running =
an
implementation of DECnet Phase IV then be very careful that you're not
throwing away functionality in DECnet Phase V that you're implicitly
reliant on. DECnet Phase IV uses NSP as the transport layer. DECnet =
Phase
V uses any (or all) of NSP, OSI TRANSPORT and DECnet over IP (uses
RFC1006-Plus to encapsulate DECnet packets inside IP packets).

DECnet Phase V does multi-homed end systems. Early DECnet Phase V =
(called
DECnet/OSI) doesn't do host based routing, later Phase V (called
DECnet-Plus - appears in VMS V7.1 onwards) does do host based routing.

VAX does DDCMP (DECnet over serial line), Alpha doesn't. VAX doesn't do
PPP (TCPIP Services, not DECnet), Alpha does.

Hope this helps.
Colin Butcher (col...@xd...)

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of
Anthony Patchett
Sent: 19 September 2002 12:11
To: lin...@li...
Subject: [Linux-decnet-user] Command line access to NCL


I'm looking at replacing some VMS boxes with a linux-based solution and =
I
need DECnet access to manage some older network devices (DECnis routers
etc.). So I was wondering if it is possible to get command line access =
to
NCL using "DECnet for Linux"?

Tony Patchett




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-decnet-user mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-decnet-user mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

FW: [Linux-decnet-user] Command line access to NCL

[Colin B. <col...@xd...>]

Quite right. It's the clearVISN DECnis Configurator (and associated tools).
Last time I saw it you could download it from the DNPG web site
(www.dnpg.com), now the Digital Networks web site (www.digitalnetworks.net).

Colin.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of Rob
Davies
Sent: 19 September 2002 14:45
To: lin...@li...
Subject: Re: [Linux-decnet-user] Command line access to NCL


I seem to remember that a Windows client/configurator application was
developed for the DECNIS that gives you the NCL command line through one
of the menu options.

This should also be able to manage other devices, as I believe that it
was a (reasonably) full implementation of NCL.

I'm not aware of any other NCL implementations, other than of course
Tru64 Unix and VMS ...

Rob.


Patrick Caulfield wrote:
> On Thu, Sep 19, 2002 at 01:10:45PM +0200, Anthony Patchett wrote:
>
>>I'm looking at replacing some VMS boxes with a linux-based solution and I
>
> need DECnet access to manage some older network devices (DECnis routers
etc.).
> So I was wondering if it is possible to get command line access to NCL
using
> "DECnet for Linux"?
>
>
> I suspect the answer is "no" but I don't really know what you're asking as
I've
> always managed to avoid NCL.
>
> If the devices support MOP remote console then you could use the moprc
client
> included with LAT (available from the DECnet for Linux site).
>
> patrick
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-decnet-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-decnet-user
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-decnet-user mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

RE: [Linux-decnet-user] Command line access to NCL

[Colin B. <col...@xd...>]

NCL is the command line interface with DECnet/OSI & DECnet-Plus, aka
DECnet Phase V. DECnis etc. use it for remote management. Since the Linux
DECnet implementation is Phase IV the answer must be no.

DECnis routers don't really do remote console or anything much like that,
so you'll need to retain a DECnet Phase V machine to manage them remotely
over the network.

If you're looking to replace DECnet Phase V machines with Linux running an
implementation of DECnet Phase IV then be very careful that you're not
throwing away functionality in DECnet Phase V that you're implicitly
reliant on. DECnet Phase IV uses NSP as the transport layer. DECnet Phase
V uses any (or all) of NSP, OSI TRANSPORT and DECnet over IP (uses
RFC1006-Plus to encapsulate DECnet packets inside IP packets).

DECnet Phase V does multi-homed end systems. Early DECnet Phase V (called
DECnet/OSI) doesn't do host based routing, later Phase V (called
DECnet-Plus - appears in VMS V7.1 onwards) does do host based routing.

VAX does DDCMP (DECnet over serial line), Alpha doesn't. VAX doesn't do
PPP (TCPIP Services, not DECnet), Alpha does.

Hope this helps.
Colin Butcher (col...@xd...)

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of
Anthony Patchett
Sent: 19 September 2002 12:11
To: lin...@li...
Subject: [Linux-decnet-user] Command line access to NCL


I'm looking at replacing some VMS boxes with a linux-based solution and I
need DECnet access to manage some older network devices (DECnis routers
etc.). So I was wondering if it is possible to get command line access to
NCL using "DECnet for Linux"?

Tony Patchett




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-decnet-user mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

Re: [Linux-decnet-user] Command line access to NCL

[Rob D. <rob...@in...>]

I seem to remember that a Windows client/configurator application was 
developed for the DECNIS that gives you the NCL command line through one 
of the menu options.

This should also be able to manage other devices, as I believe that it 
was a (reasonably) full implementation of NCL.

I'm not aware of any other NCL implementations, other than of course 
Tru64 Unix and VMS ...

Rob.


Patrick Caulfield wrote:
> On Thu, Sep 19, 2002 at 01:10:45PM +0200, Anthony Patchett wrote:
> 
>>I'm looking at replacing some VMS boxes with a linux-based solution and I
> 
> need DECnet access to manage some older network devices (DECnis routers etc.).
> So I was wondering if it is possible to get command line access to NCL using
> "DECnet for Linux"?
> 
> 
> I suspect the answer is "no" but I don't really know what you're asking as I've
> always managed to avoid NCL.
> 
> If the devices support MOP remote console then you could use the moprc client
> included with LAT (available from the DECnet for Linux site).
> 
> patrick
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-decnet-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-decnet-user
> 

Re: [Linux-decnet-user] Command line access to NCL

[Patrick C. <pa...@ty...>]

On Thu, Sep 19, 2002 at 01:10:45PM +0200, Anthony Patchett wrote:
> I'm looking at replacing some VMS boxes with a linux-based solution and I
need DECnet access to manage some older network devices (DECnis routers etc.).
So I was wondering if it is possible to get command line access to NCL using
"DECnet for Linux"?
> 

I suspect the answer is "no" but I don't really know what you're asking as I've
always managed to avoid NCL.

If the devices support MOP remote console then you could use the moprc client
included with LAT (available from the DECnet for Linux site).

patrick

[Linux-decnet-user] Command line access to NCL

[Anthony P. <Pat...@eu...>]

I'm looking at replacing some VMS boxes with a linux-based solution and I =
need DECnet access to manage some older network devices (DECnis routers =
etc.). So I was wondering if it is possible to get command line access to =
NCL using "DECnet for Linux"?

Tony Patchett

[Linux-decnet-user] DECnet docs

[Patrick C. <pa...@ty...>]

It looks like the DECnet Phase IV documentation on gatekeeper.dec.com has
disappeared. maybe it got lost in the lastest mergers :(

I have a downloaded copy of these files and, copyright permitting, am happy to
put them up onto the linux-decnet web site.

Does anyone know the copyright state of these docs and if I can legally do so ?


patrick

[Linux-decnet-user] dnprogs 2.20 released

[Patrick C. <pa...@ty...>]

Just some minor bugfixes in this one but useful enough ones to make it worth
releasing I think.

Debian packages for all arches will be inthe archive shortly. Note that they
will be version 2.21 rather then 2.20 cos I cocked-up the build process and had
to upload a fixed version. Sorry for any confusion caused.

The changelog is just:

  * Fix vroot not NUL-terminating names properly
  * Fix sethost on 2.4.19+ kernels.
  * FAL fix overrun when sending binary files in record mode - OK you
    shouldn't do that anyway, but FAL shouldn't fail on you either.
  * Fix dncopy -mblock when copying file from VMS.
  * dncopy blocks ATTRIB & ACCESS messages for efficiency.


http://sourceforge.net/project/showfiles.php?group_id=4993

patrick

Re: [Linux-decnet-user] LATD: problem with DECServer 90L+

[Patrick C. <pa...@ty...>]

On Tue, Sep 10, 2002 at 03:29:24PM +0200, Jozef Hitzinger wrote:
> 
> It must've been strange thinking at DEC which brought us this. It's ok,
> while it's just LAT/DECnet. I don't know what would we do if some other
> thing would be restricted a different set of MAC addresses. Hope this
> won't happen.
> 
> Thanks a lot for help, and for writing the code too, of course.
> Bye,

Thanks for reminding me about this. I heard of it sometime ago but forgot. I'll
put something in the documentation.

You're right. It's a very bizarre "feature".

patrick

Re: [Linux-decnet-user] LATD: problem with DECServer 90L+

[Jozef H. <hic...@se...>]

On Tue, 10 Sep 2002, Patrick Caulfield wrote:

> On Tue, Sep 10, 2002 at 10:21:59AM +0200, Jozef Hitzinger wrote:
> > I hope DS90L+ works with MAC addresses from non-DEC range ..
>
> ARGH! I think you're right.
>
> /me checks
>
> Yup.
>
> Normally, because I run DECnet, I have all my machines with AA:00:04... MAC
> addresses, so I've never had a problem with the DS90L+
>
> I just changed the MAC address on one of my systems to the MAC address
> you gave me for your box and...guess what...it doesn't connect.
>
> # ifconfig hw ether AA:00:04:00:0A:04

I had to setup another server to test this (can't do such experiments on
main server in the middle of day), so it took a bit longer. Obviously,
unchanged latd 1.15 package from debian unstable works like a charm with
this MAC address:

ifconfig eth0 down
ifconfig eth0 hw ether AA:00:04:00:0A:04
ifcongig eth0 up
/etc/init.d/latd restart

It must've been strange thinking at DEC which brought us this. It's ok,
while it's just LAT/DECnet. I don't know what would we do if some other
thing would be restricted a different set of MAC addresses. Hope this
won't happen.

Thanks a lot for help, and for writing the code too, of course.
Bye,
-- 
jozef  :-)

Re: [Linux-decnet-user] LATD: problem with DECServer 90L+

[Patrick C. <pa...@ty...>]

On Mon, Sep 09, 2002 at 11:04:17AM +0200, hic...@se... wrote:
> 
> Hi guys,
> 
> I've googled the web but didn't find anything suitable .. maybe you could
> help.
> 
> We have several terminals, connected to terminal server, which speaks LAT
> only (no telnet). It connected the terms to a VAX machine. Now the VAX
> will be shutdown and removed, but they want to keep terminals for
> students access to e-mail.
> 
> I put latd 1.15 from debian unstable package on my linux woody server
> named Phobos. Things seem to start good, when I 'c phobos' from a vt420
> connected to 90L+, the terminal server discovers via dec broadcast the MAC
> address of the server and starts talking to it.
> 
> I've captured the communication, 08-00-etc is the term server, 00-50-etc
> is the linux box:
> 
> 1. 08-00-2b-31-0d-e4 -> 00-50-da-44-0c-70
>    C, Start, 0x7304->0x00
> 
> 2. 00-50-da-44-0c-70 -> 08-00-2b-31-0d-e4
>    R, Start, 0x35->0x7304
> 3. the same as 2
> 4. the same as 2
> 
> .. after the first query from term server, there are 21 equivalent
> responses sent from linux box. These are ignored by term server, no
> more messages addressed from 0x7304 to 0x35 appear.
> 
> Then term server asks the C, Start again, and linux box responds with the
> same packets as before, only the number is one higher (0x36).
> 
> When the linux box timeouts on the circuit, it sends 21 C, Stop messages
> from 0x35. The same happens several times around, the amount of messages
> the linux box sends is always different.
> 
> When they reach 0x3d, the term server gives up and terminal shows "Service
> Unavailable" error. Then term server sends C, Stop, 0x00->0x00 .. and
> linux box sends more than hundred C, Stop, 0x3D->0x7304 LAT packets.
> 

Can you send me the full tcpdump please. I have a DS90L+ here and it works fine.


patrick

[Linux-decnet-user] LATD: problem with DECServer 90L+

[<hic...@se...>]

Hi guys,

I've googled the web but didn't find anything suitable .. maybe you could
help.

We have several terminals, connected to terminal server, which speaks LAT
only (no telnet). It connected the terms to a VAX machine. Now the VAX
will be shutdown and removed, but they want to keep terminals for
students access to e-mail.

I put latd 1.15 from debian unstable package on my linux woody server
named Phobos. Things seem to start good, when I 'c phobos' from a vt420
connected to 90L+, the terminal server discovers via dec broadcast the MAC
address of the server and starts talking to it.

I've captured the communication, 08-00-etc is the term server, 00-50-etc
is the linux box:

1. 08-00-2b-31-0d-e4 -> 00-50-da-44-0c-70
   C, Start, 0x7304->0x00

2. 00-50-da-44-0c-70 -> 08-00-2b-31-0d-e4
   R, Start, 0x35->0x7304
3. the same as 2
4. the same as 2

.. after the first query from term server, there are 21 equivalent
responses sent from linux box. These are ignored by term server, no
more messages addressed from 0x7304 to 0x35 appear.

Then term server asks the C, Start again, and linux box responds with the
same packets as before, only the number is one higher (0x36).

When the linux box timeouts on the circuit, it sends 21 C, Stop messages
from 0x35. The same happens several times around, the amount of messages
the linux box sends is always different.

When they reach 0x3d, the term server gives up and terminal shows "Service
Unavailable" error. Then term server sends C, Stop, 0x00->0x00 .. and
linux box sends more than hundred C, Stop, 0x3D->0x7304 LAT packets.

Many thanks for any idea as to what can be wrong.
-- 
jozef  :-)

Re: [Linux-decnet-user] Still having problems with lat and printing

[Patrick C. <pa...@ty...>]

On Thu, Sep 05, 2002 at 10:48:53AM -0400, Mat...@Ke... wrote:
> I moved up to red hat 7.3, lat 1.15 and decnet 2.19 with a fresh install of
> everything.
> 
> LAT and Decnet seem to work fine (llogin, moprc, dnping, sethost,...)
> I have an LP27 on a decserver 250 called LAT25.
> I have a service on LAT25 called LP27 assigned to the printer port (port 5)
> with the queued attribute.
> I created a lat device in the latcp.conf with:
>      latcp -A -p /dev/lat/lta2505 -VLP27 -RPORT_5 -H LAT25 -Q -8
> I created a printer with /dev/lat/lta2505 as the device
> 
> When I try to print a plain text file, or cat or echo text to
> /dev/lat/lta2505, the latd dies.  Sometimes it prints a portion of the text
> (first 20 lines or so.)  What is the best way to find out why latd is
> dying?

If latd is dying that's pretty nasty. Can you compile it with debug enabled
(  DEFS+=-DVERBOSE_DEBUG -DNO_FORK -DDEBUG_MALLOC in the Makefile ) and send me
the output.

It also may be helpful to get a core dump and send me a backtrace from it, if
you know how to do that.

What you you using for printing (lpr, lprng, cups) ?

patrick

[Linux-decnet-user] Still having problems with lat and printing

[<Mat...@Ke...>]

I moved up to red hat 7.3, lat 1.15 and decnet 2.19 with a fresh install of
everything.

LAT and Decnet seem to work fine (llogin, moprc, dnping, sethost,...)
I have an LP27 on a decserver 250 called LAT25.
I have a service on LAT25 called LP27 assigned to the printer port (port 5)
with the queued attribute.
I created a lat device in the latcp.conf with:
     latcp -A -p /dev/lat/lta2505 -VLP27 -RPORT_5 -H LAT25 -Q -8
I created a printer with /dev/lat/lta2505 as the device

When I try to print a plain text file, or cat or echo text to
/dev/lat/lta2505, the latd dies.  Sometimes it prints a portion of the text
(first 20 lines or so.)  What is the best way to find out why latd is
dying?

Thanks.

I can print fine from VMS.