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

[Linux-decnet-user] dnprogs 2.07 released

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

I am pleased to announce the release of dnprogs 2.07. As stated earlier this is
the last *binary* release that is compatible with Linux 2.2.

  * Fix VMS errors sending block-structured files from fal
  * Added support for Ultrix DATE DAP message (another "new" extension)
  * Cope better with VMS errors when sending files (eg. disk full)
  * Changed some prototypes in netdb.h to match Ultrix
  * Fixed compile of phone because of stupid ncurses symbol
  * dnet_conn() is Ultrix-compatible (with a 2.4 kernel)
  * Substantial enhancements to mail to make it work. But only on 2.4 kernels
  * New function dnet_eof. Again, only for 2.4 kernels
  * Shared libraries linked correctly now (according to lintian)
  * Made it work properly on big-endian machines under 2.4
  * Vastly improved debian package
  * Mucked around with nearly all of the man pages a little
  * Made startnet set the MAC address of any or all interfaces
  * Added -f (force) to startnet to make it DOWN an interface before mucking
    about with it.

The biggest single improvement is in the VMSmail gateway which now works quite
well but, unfortunately, only with 2.4 kernels, but FAL has had some robustness
improvements too and startnet is now so robust it can bring down your network
connections (with the -f switch: be careful out there!)

Get it from http://linux-decnet.sourceforge.net/download.html

patrick

[Linux-decnet-user] Any NCL experts out there ?

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

One minor niggle with 2.4 kernels is the fact that the neighbour table timeouts
are fixed. This seems to be OK for Phase IV nodes because they send endnode
hello messages out quite frequently but my Phase V box sends them out only every
5 minutes so the entries keep getting removed from the neightbour table
(/proc/net/decnet_neigh)

Does anyone know the magic NCL runes to set the hello timer to a shorter value ?
I'll put it in the FAQ if they do.

patrick

[Linux-decnet-user] Future of dnprogs

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

With good luck and a following wind I will be releasing dnprogs 2.07 this
weekend. This has a number of bug-fixes and a lot of work relating to the 2.4
kernel and the Debian package.

This will be the last set of binary packages I will do for the 2.2 kernel. From
2.08 (whenever that may be) the RPMs on the web site will be for Linux 2.4. I
will maintain source code compatability with 2.2 though so that the programs
will still work for both but those people using 2.2 will need to build from
sources - the reverse of the current situation.

The Debian package has undergone a great deal of improvement since 2.06 and will
see much more in the future, and that work will also be applied to latd. Also, I
have been accepted as a Debian maintainer so sometime in the future DECnet and
LAT will become part of that distribution.

This will have the nice effect that Debian should become trivially easy to set
up DECnet - my goal is to have the command "apt-get install dnet-progs" do all
the hard work for you!

The new Debian system will look like this:

libdnet      # Libraries and config files
dnet-progs   # The programs (dnetd, dndir, fal etc)
libdnet-dev  # Development libraries (static libs, .so links and headers)

Anyway, that is all in the future. If anyone has any objections, opinions about
this then let's have a chat about it.

patrick

[Linux-decnet-user] Big endian patch for 2.4

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

I don't know if anyone's trying to use DECnet with a 2.4 kernel on a big-endian
machine (eg SPARC) but if there are then they'll probably need this patch. It
fixes a crash when reading /proc/net/decnet and it makes the daemons work too.

Oh, and you'll probably need to check out the latest dnprogs from CVS as well :-)

So I doubt there is anyone wanting this really! But here it is anyway...


patrick

Re: [Linux-decnet-user] Copy a strange file from vms to linux via decnet

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

OK, I'm back home and had a look at this and it seems to be a VMS restriction
with an easy workaround.

On VMS enter the following ocmmand before attempting the transfer:

$ SET RMS_DEFAULT  /NETWORK_BLOCK_COUNT=127

Or, to make it the system-wide global default set the SYSGEN parameter
RMS_DFNBC

I'll add this to the FAQ.

It seems that VMS does not use segmented DAP messages at all, at least I can't
make it. Does anyone know any different?

patrick

[Linux-decnet-user] Latest DECnet code

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

Hi,

Just a quick note to let people know that the latest DECnet code is in
2.4.0-ac2 at the moment (i.e. Alan Cox's patches) and that it hasn't all
made its way into the main kernel tree yet,

Steve.

Re: [Linux-decnet-user] Copy a strange file from vms to linux via decnet

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

On Thu, Jan 04, 2001 at 01:51:23PM +0800, Chin-Yung wrote:
> Hi,
>         I want to copy a file containing a very large line from my vms host
> to the linux box which runs the redhat6.2 with kernel-2.2.16 ,
> decnet-kernel-patchv0.0.15 and dnprogs2.06. I have the error message as
> follows:
> %COPY-E-WRITEERR,  error  writing  4.1002"spc
> password"::"./data/tablef01/tablef01.txt"
> -RMS-E-NETBTS,  network  buffer  too  small  for  5412  byte  record
> %COPY-W-NOTCMPLT,  L4L$GEN_ROOT:[SAMPLE.CASE100.HISTORY]B100306A00B0.F01;1
> not  completely  copied
> 
> I can copy the file from the vms host to the other vms host without any
> problem. What's wrong with my linux box?

I reckon the problem is that FAL can't handle segmented messages. I need
to do some work here and I'm away from home at the moment so don't hold your
breath! 

You should be able to "pull" the file from VMS by using dncopy on the Linux
machine, it's possible to trigger this from VMS using SUBMIT/REMOTE on a shell
script or (and I haven't tried this so it may not work) convert the file to 
STREAMLF, then use the SET FILE command to change the attributes to fixed-length
512 byte records, no carriage control and send that to Linux.

Patrick

[Linux-decnet-user] Copy a strange file from vms to linux via decnet

[Chin-Yung <sem...@ki...>]

Hi,
        I want to copy a file containing a very large line from my vms host
to the linux box which runs the redhat6.2 with kernel-2.2.16 ,
decnet-kernel-patchv0.0.15 and dnprogs2.06. I have the error message as
follows:
%COPY-E-WRITEERR,  error  writing  4.1002"spc
password"::"./data/tablef01/tablef01.txt"
-RMS-E-NETBTS,  network  buffer  too  small  for  5412  byte  record
%COPY-W-NOTCMPLT,  L4L$GEN_ROOT:[SAMPLE.CASE100.HISTORY]B100306A00B0.F01;1
not  completely  copied

I can copy the file from the vms host to the other vms host without any
problem. What's wrong with my linux box?
This is the content of the strange file :
B100306A00B0,10337.000000,10184.000000,9027.000000,9027.000000,10964.000000,
10964.000000,
9734.000000,9935.000000,10160.000000,10160.000000,9959.000000,10007.000000,1
0007.000000,
10032.000000,10032.000000,10007.000000,10007.000000,10032.000000,10032.00000
0,10007.000000,
10007.000000,10007.000000,10007.000000,10007.000000,10032.000000,10032.00000
0,10007.000000,
10007.000000,10007.000000,10007.000000,10007.000000,10032.000000,10032.00000
0,10032.000000,
10032.000000,10007.000000,10007.000000,10007.000000,10056.000000,10056.00000
0,10080.000000,
10056.000000,10056.000000,10056.000000,10032.000000,10007.000000,10032.00000
0,10032.000000,
10032.000000,10080.000000,10136.000000,10080.000000,10080.000000,10007.00000
0,10056.000000,
10007.000000,10007.000000,10007.000000,10136.000000,10080.000000,10080.00000
0,10080.000000,
10080.000000,9983.000000,10032.000000,10007.000000,10007.000000,10007.000000
,10104.000000,
10104.000000,10136.000000,10056.000000,9983.000000,9983.000000,10007.000000,
10007.000000,
10007.000000,10007.000000,10080.000000,10056.000000,10032.000000,10080.00000
0,10032.000000,
9983.000000,9983.000000,10080.000000,10080.000000,10056.000000,10032.000000,
10056.000000,
10056.000000,10007.000000,10007.000000,10007.000000,10007.000000,10007.00000
0,10056.000000,
10104.000000,10104.000000,10104.000000,10080.000000,10104.000000,10104.00000
0,10056.000000,
10032.000000,10032.000000,10056.000000,10104.000000,10080.000000,10080.00000
0,10080.000000,
10080.000000,10056.000000,10056.000000,10104.000000,10080.000000,10056.00000
0,10080.000000,
10080.000000,10007.000000,10007.000000,10080.000000,10104.000000,10104.00000
0,10160.000000,
10136.000000,10136.000000,10104.000000,10032.000000,10032.000000,10056.00000
0,10032.000000,
10032.000000,10080.000000,10080.000000,10160.000000,10160.000000,10104.00000
0,10104.000000,
10136.000000,10136.000000,10080.000000,10080.000000,10056.000000,10080.00000
0,10056.000000,
10056.000000,10056.000000,10136.000000,10104.000000,11663.000000,10586.00000
0,10586.000000,
10586.000000,12419.000000,11945.000000,11591.000000,11591.000000,11462.00000
0,11462.000000,
11462.000000,11462.000000,11462.000000,11462.000000,11487.000000,11487.00000
0,11462.000000,
11462.000000,11438.000000,11438.000000,11462.000000,11462.000000,11462.00000
0,11462.000000,
11462.000000,11462.000000,11462.000000,11462.000000,11462.000000,11487.00000
0,11487.000000,
11462.000000,11462.000000,11462.000000,11462.000000,11462.000000,11462.00000
0,11487.000000,
11462.000000,11462.000000,11462.000000,11462.000000,11487.000000,11462.00000
0,11462.000000,
11462.000000,11487.000000,11487.000000,11487.000000,11487.000000,11511.00000
0,11487.000000,
11511.000000,11487.000000,11487.000000,11487.000000,11487.000000,11487.00000
0,11462.000000,
11511.000000,11511.000000,11487.000000,11511.000000,11487.000000,11487.00000
0,11487.000000,
11487.000000,11462.000000,11462.000000,11462.000000,11462.000000,11487.00000
0,11511.000000,
11487.000000,11487.000000,11487.000000,11487.000000,11462.000000,11487.00000
0,11487.000000,
11462.000000,11462.000000,11487.000000,11487.000000,11487.000000,11487.00000
0,11487.000000,
11487.000000,11487.000000,11511.000000,11511.000000,11511.000000,11511.00000
0,11511.000000,
11487.000000,11487.000000,11462.000000,11487.000000,11487.000000,11511.00000
0,11511.000000,
11511.000000,11511.000000,11511.000000,11543.000000,11511.000000,11511.00000
0,11487.000000,
11487.000000,11487.000000,11487.000000,11487.000000,11487.000000,11511.00000
0,11543.000000,
11543.000000,11543.000000,11511.000000,11487.000000,11511.000000,11511.00000
0,11511.000000,
11487.000000,11543.000000,11543.000000,11543.000000,11543.000000,11543.00000
0,11543.000000,
11543.000000,11543.000000,11487.000000,11511.000000,11487.000000,11487.00000
0,11487.000000,
11487.000000,11511.000000,11511.000000,11567.000000,11567.000000,11543.00000
0,11543.000000,
11511.000000,11511.000000,11511.000000,11487.000000,11487.000000,11511.00000
0,11511.000000,
4453.000000,3424.000000,4003.000000,4003.000000,4003.000000,5209.000000,2845
.000000,2146.000000,
2146.000000,1342.000000,1439.000000,1543.000000,1543.000000,1591.000000,1591
.000000,1543.000000,
1567.000000,1567.000000,1567.000000,1591.000000,1591.000000,1591.000000,1543
.000000,1567.000000,
1567.000000,1615.000000,1567.000000,1543.000000,1543.000000,1591.000000,1591
.000000,1567.000000,
1591.000000,1543.000000,1567.000000,1591.000000,1543.000000,1543.000000,1567
.000000,1567.000000,
1591.000000,1591.000000,1615.000000,1591.000000,1615.000000,1591.000000,1591
.000000,1591.000000,
1591.000000,1591.000000,1615.000000,1591.000000,1591.000000,1615.000000,1591
.000000,1591.000000,
1591.000000,1591.000000,1567.000000,1615.000000,1639.000000,1639.000000,1591
.000000,1567.000000,
1567.000000,1615.000000,1615.000000,1591.000000,1591.000000,1615.000000,1567
.000000,1567.000000,
1615.000000,1567.000000,1567.000000,1567.000000,1567.000000,1567.000000,1591
.000000,1591.000000,
1591.000000,1615.000000,1591.000000,1591.000000,1591.000000,1591.000000,1591
.000000,1615.000000,
1615.000000,1567.000000,1615.000000,1591.000000,1591.000000,1591.000000,1591
.000000,1567.000000,
1591.000000,1591.000000,1567.000000,1615.000000,1615.000000,1591.000000,1591
.000000,1591.000000,
1591.000000,1591.000000,1615.000000,1567.000000,1567.000000,1591.000000,1591
.000000,1591.000000,
1615.000000,1615.000000,1591.000000,1591.000000,1543.000000,1543.000000,1615
.000000,1591.000000,
1591.000000,1615.000000,1615.000000,1567.000000,1591.000000,1591.000000,1639
.000000,1639.000000,
1567.000000,1567.000000,1567.000000,1591.000000,1591.000000,1591.000000,1591
.000000,1591.000000,
1591.000000,1591.000000,1591.000000,1591.000000,1615.000000,1615.000000,1591
.000000,1615.000000,
1567.000000,1615.000000,1921.000000,1921.000000,1615.000000,7266.000000
The data are all in one line!!

Best  regards

chinyung
jan.4.2001

[Linux-decnet-user] =?big5?B?Q2FuIG5vdCBjb3B5ICJ0aGUgZmlsZSIgdmlhIGRl?= =?big5?B?Y25ldA==?=

[<chi...@ma...>]

Hi,
=20=20=20=20I=20want=20to=20copy=20a=20file=20from=20my=20vms=20host=20to=20=
the=20linux=20box=20which=20runs=20the=20redhat6.2=20+=20kernel-2.2.16=20+=20=
decnet-kernel-patchv0.0.15=20+
dnprogs2.06.=20I=20try=20a=20lot=20of=20files=20and=20everything=20works=20w=
ell,=20but=20when=20I=20copy=20the=20file=20that=20I=20append=20and=20have=20=
the=20error=20message=20as=20follows:
%COPY-E-WRITEERR,=20error=20writing=204.1002"spc=20password"::"./data/tablef=
01/tablef01.
txt"
-RMS-E-NETBTS,=20network=20buffer=20too=20small=20for=205412=20byte=20record=

%COPY-W-NOTCMPLT,=20L4L$GEN_ROOT:[SAMPLE.CASE100.HISTORY]B100306A00B0.F01;1=20=
not=20co
mpletely=20copied

I=20also=20copy=20the=20file=20from=20the=20vms=20host=20to=20the=20other=20=
vms=20host=20without=20any=20problem.=20What's=20wrong=20with=20my=20linux=20=
box?


Best=20regards

chinyung
jan.3.2001



----=3D=3D=20Mailed=20via=20Openfind=20=3D=3D-----
http://mail2000.com.tw/=20=B4=A3=A8=D1=A7K=B6O=B9q=A4l=B6l=A5=F3=ABH=BDc

Re: [Linux-decnet-user] Testing with RSX and latest patches

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

On Mon, Jan 01, 2001 at 02:48:35PM -0500, Doug Carman wrote:
> Thanks to Steve for the latest patches.  
> 
> The really bad news is that this problem also appears to affect data
> transfer from Linux->VMS (MicroVAX 3100, VMS v5.5).  In this case, after
> about 30 lines, the output pauses and then continues in small spurts
> until about 70 lines when it stops for a longer period.  During this
> time, it appears that Linux is retransmitting packets and not getting
> ACK's back from VMS.  Eventually, the output hangs to the point where
> the login must be terminated.  However with the VMS scenario, gaps do
> not exist in the output.
>
> After backing out only the 12/28 patch, I now see reports of "System
> buffer unavailable" from RSX and the output hangs.  From Linux->VMS, I
> get slow output (about 1 line per second) and long pauses in the output.
> 
> With the 12/28 patch, I no longer get "System buffer unavailable"
> messages from RSX, but data is still being lost from Linux->RSX.
> 
> I know there are far more people testing against VMS, so I was wondering
> if anyone else had seen the same problems with VMS?

Just for info (and Steve knows this) I also get the 'hangs' to VMS via ctermd
but no characters are lost. My guess is that it is to do with lots of short
packets being sent. FAL in block mode sends huge blocks of data (32->64K if the
remote end will let it) whereas ctermd sends much smaller packets, I'm seeing
108 bytes each typing a file with lots of 80 character lines).

If I force FAL into record mode then the same thing happens as with ctermd, the
output gets slower and slower until it stalls completely. The blocks here are
not so small as ctermd (4080 bytes) though.
 
Interestingly, my Alpha box (running Phase V) works fine :-)

patrick

[Linux-decnet-user] Testing with RSX and latest patches

[Doug C. <pd...@be...>]

Thanks to Steve for the latest patches.  

I applied both the earlier patch (12/14) and the one from last week
(12/28) to a fresh 2.4.0-test12 source tree.  I still see packet loss
when transmitting data packets from Linux->RSX.  When I 'SET HOST' from
RSX to the Linux system, then perform directory listings or other
commands that produce output to the terminal, I experience loss of
output.  

By running a simple script that generates 1000 numbered lines of output,
you can see the loss in the output.

When I run the script, I see holes in the output like this:

...
13:0123456789abcdef0123456789abcdef0123456789abcdef
14:0123456789abcde789abcdef0123456789abcdef0123456789abcdef
32:0123456789abcdef0123456789abcdef0123456789abcdef
...

and:

...
41:0123456789abcdef0123456789abcdef0123456789abcdef
42:0123456789abcdef01234567896789abcdef0123456789abcdef
60:0123456789abcdef0123456789abcdef0123456789abcdef
...

and:

...
76:0123456789abcdef0123456789abcdef0123456789abcdef
77:0123456789abcdef01123456789abcdef
93:0123456789abcdef0123456789abcdef0123456789abcdef
...

Eventually, the output hangs and the login must be terminated on the
Linux system.

The really bad news is that this problem also appears to affect data
transfer from Linux->VMS (MicroVAX 3100, VMS v5.5).  In this case, after
about 30 lines, the output pauses and then continues in small spurts
until about 70 lines when it stops for a longer period.  During this
time, it appears that Linux is retransmitting packets and not getting
ACK's back from VMS.  Eventually, the output hangs to the point where
the login must be terminated.  However with the VMS scenario, gaps do
not exist in the output.

After backing out only the 12/28 patch, I now see reports of "System
buffer unavailable" from RSX and the output hangs.  From Linux->VMS, I
get slow output (about 1 line per second) and long pauses in the output.

With the 12/28 patch, I no longer get "System buffer unavailable"
messages from RSX, but data is still being lost from Linux->RSX.

I know there are far more people testing against VMS, so I was wondering
if anyone else had seen the same problems with VMS?


-- 
Doug Carman
pd...@be...

[Linux-decnet-user] Re: Testing with RSX and latest patches

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

Hi,

> 
> Thanks to Steve for the latest patches.  
> 
> I applied both the earlier patch (12/14) and the one from last week
> (12/28) to a fresh 2.4.0-test12 source tree.  I still see packet loss
> when transmitting data packets from Linux->RSX.  When I 'SET HOST' from
> RSX to the Linux system, then perform directory listings or other
> commands that produce output to the terminal, I experience loss of
> output.  
> 
> By running a simple script that generates 1000 numbered lines of output,
> you can see the loss in the output.
>
I've got some ideas to what might be causing this (see below)
[snip]
 
> 
> Eventually, the output hangs and the login must be terminated on the
> Linux system.
>
I've had hangs happen using loopback on my machine here. I actually think
that is a different bug, and I've got a good idea of the cause too. I
think it could be a timer bug (well not the timer itself, but the way it
interacts with the socket locking).
 
> The really bad news is that this problem also appears to affect data
> transfer from Linux->VMS (MicroVAX 3100, VMS v5.5).  In this case, after
> about 30 lines, the output pauses and then continues in small spurts
> until about 70 lines when it stops for a longer period.  During this
> time, it appears that Linux is retransmitting packets and not getting
> ACK's back from VMS.  Eventually, the output hangs to the point where
> the login must be terminated.  However with the VMS scenario, gaps do
> not exist in the output.
> 
What is the program that you are running on the Linux side when you
see this packet loss? ctermd or something else ? I suspect that this
might be a user level problem (maybe the return value from write is not
tested to see exactly how many bytes got written). It is equally possible
that its kernel side too, but we need to find out which and a quick glance
through the source of the relavent program should tell me. Sorry if you've
told me this before and I've forgotten.

> After backing out only the 12/28 patch, I now see reports of "System
> buffer unavailable" from RSX and the output hangs.  From Linux->VMS, I
> get slow output (about 1 line per second) and long pauses in the output.
> 
In this case Linux is sending packets which the flow control does not
allow since the 12/28 patch implements the required flow control
algorithms to prevent this. This is good to know as is means that the
12/28 patch is working :-)

I've sent the 12/28 patch to Dave Miller now but not had any acknowledgement
yet (I guess he is on holiday or something). The other patch is already
on Dave's queue. I guess neither patch will make 2.4.0 now, but it will
probably be in 2.4.1 and I'll send them to Alan Cox for his kernel tree if
he continues to maintain his own kernel patches against the 2.4.xx series.

I'm going to be taking a break from DECnet for a week or so shortly but
I'll keep thinking about solutions to the current problems and try and
have a fix ready to code up when I return,

Happy New Year,

Steve.