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

Re: [Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes

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

On Tue, Mar 27, 2001 at 04:06:20PM +0100, Paul Sherwin wrote:
> At 14:14 27/03/01 +0100, you wrote:
> >On Tue, Mar 27, 2001 at 12:28:29PM +0000, Eduardo Serrat wrote:
> >> I am afraid the problem is related to the MTU (Max Transfer Unit) that
> >> Steve's Kernel implementation of DECnet uses. This was set to 230 Bytes
> >> so I had to issue a patch for DAPFS to work with it (BLOCK I/O would fail 
> >> because it needs more that 230 bytes (????)). You can obtain it
> downloading 
> >> the dapfs patch and applying it.
> >
> >It was changed in 2.4.1 to default to 1498 or whatever the remote end
> needs (if
> >less than that). That's one of the reasons I made a new 2.4.2 dapfs patch :-)
> 
> I'm getting confused here. Does this mean I need to apply a patch the
> standard 2.4.2 kernel and that will fix my problem, or is there a real
> problem with 2.4.2 which is as yet unfixed?

Sorry, that was as typo as well as badly phrased. The MTU was fixed in 2.4.1 and
2.4.2 has the same DECnet code in as 2.4.1, so there should be no MTU problems
in the kernel you have.

I made a new DAPFS patch for 2.4.1 because Eduardo's original 2.4.0 dapfs patch
included the MTU fix. That was probably an irrelevant piece of information
there.

patrick

Re: [Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes

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

On Tue, Mar 27, 2001 at 11:56:15AM +0100, Patrick Caulfield wrote:
> On Mon, Mar 26, 2001 at 05:13:36PM +0100, Paul Sherwin wrote:
> > I still haven't managed to copy a large file from a Linux system to a
> > uVaxII using linux-decnet under RH7.1 beta. I did the following:
> > 
> > 1. Obtained the source for kernel 2.4.2 and rebuilt it, specifying Decnet
> > support be included in the kernel.
> > 
> > 2. Rebuilt dnprogs2.07 against this kernel.
> > 
> > This has made absolutely no difference. The Linux Decnet node is seen by,
> > and sees, the Vax node, and files can be copied from the Vax to the Linux
> > box with no obvious problems. Sethost also works. However, if the same file
> > is copied back to the Vax, the following happens:
> > 
> 
> Oh dear, it happens here too. It seems OK to phase V nodes but not phase IV.

Just a bit more info - it does seem to be flow control related. When it failed
for me first time I had FAL logging enabled on my VAXstation. If I switch that
off then the copy works fine using dncopy and fal.

Looks like FAL logging slows a 4000VLC down to the speed of a MicroVAX! 

patrick

Re: [Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes

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

On Tue, Mar 27, 2001 at 12:28:29PM +0000, Eduardo Serrat wrote:
> 
> Hi,
> 
> I am afraid the problem is related to the MTU (Max Transfer Unit) that
> Steve's Kernel implementation of DECnet uses. This was set to 230 Bytes
> so I had to issue a patch for DAPFS to work with it (BLOCK I/O would fail 
> because it needs more that 230 bytes (????)). You can obtain it downloading 
> the dapfs patch and applying it.

It was changed in 2.4.1 to default to 1498 or whatever the remote end needs (if
less than that). That's one of the reasons I made a new 2.4.2 dapfs patch :-)

patrick

Re: [Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes

[Eduardo S. <ems...@ho...>]

Hi,

I am afraid the problem is related to the MTU (Max Transfer Unit) that
Steve's Kernel implementation of DECnet uses. This was set to 230 Bytes
so I had to issue a patch for DAPFS to work with it (BLOCK I/O would fail 
because it needs more that 230 bytes (????)). You can obtain it downloading 
the dapfs patch and applying it.

Hope this helps,

Eduardo Serrat
>From: Paul Sherwin <psh...@st...>
>To: lin...@li...
>Subject: [Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes
>Date: Mon, 26 Mar 2001 17:13:36 +0100
>
>I still haven't managed to copy a large file from a Linux system to a
>uVaxII using linux-decnet under RH7.1 beta. I did the following:
>
>1. Obtained the source for kernel 2.4.2 and rebuilt it, specifying Decnet
>support be included in the kernel.
>
>2. Rebuilt dnprogs2.07 against this kernel.
>
>This has made absolutely no difference. The Linux Decnet node is seen by,
>and sees, the Vax node, and files can be copied from the Vax to the Linux
>box with no obvious problems. Sethost also works. However, if the same file
>is copied back to the Vax, the following happens:
>
>Red Hat Linux release 7.0.90 (Fisher)
>Kernel 2.4.2 on an i486
>login: root
>Password:
>Last login: Mon Mar 26 16:34:16 from 192.168.0.214
>You have mail.
>[root@OldTimer /root]# cd /tmp
>[root@OldTimer /tmp]# dncopy -vvv -mblock -rfix /tmp/starlet.olb
>'psc"system"::dua0:[paul]'
>Sending message of type CONFIG
>wrote 17 bytes
>read: read 21 bytes
>Got message of type CONFIG
>Remote buffer size is 32767
>Using block size 32767
>Remote OS is 7
>in dap_send_attributes()
>Blocked output is ON
>Sending message of type ATTRIB
>Sending message of type ALLOC
>Blocked output is OFF, sending 14 bytes
>wrote 14 bytes
>Sending message of type ACCESS
>wrote 32 bytes
>in dap_get_file_entry()
>read: read 63 bytes
>Got message of type ATTRIB
>Got message of type PROTECT
>Got message of type NAME
>Got message of type ACK
>in dap_send_connect()
>Sending message of type CONTROL
>wrote 5 bytes
>in dap_get_reply()
>read: read 2 bytes
>Got message of type ACK
>in dap_send_get_or_put($PUT)
>Sending message of type CONTROL
>wrote 6 bytes
>in dap_put_record(512 bytes)
>Blocked output is ON
>Sending message of type DATA
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>     /* LONG WAIT */
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>     /* LONG WAIT */
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>     /* LONG WAIT */
>Wrote 32571 bytes, buffer size is now 517 bytes
>in dap_put_record(512 bytes)
>Sending message of type DATA
>     /* REPEATED MANY TIMES */
>in dap_put_record(512 bytes)
>Sending message of type DATA
>block is over-full(33088), Sending 32571 bytes
>     /* HANGS (OR VERY LONG WAIT) */
>     /* PRESS CTRL-C              */
>[root@OldTimer /tmp]#
>
>It's also not possible to copy the file from the other end using fal -ag.
>
>I don't think there's anything very unusual about my setup, but I can't
>believe nobody else has hit this problem since it's so easy to reproduce.
>Help!
>
>TIA, Paul
>
>Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
>Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
>Mobile +44 (0)7931 578334   mailto:psh...@st...
>Pager  +44 (0)7666 797228
>
>_______________________________________________
>Linux-decnet-user mailing list
>Lin...@li...
>http://lists.sourceforge.net/lists/listinfo/linux-decnet-user

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes

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

On Mon, Mar 26, 2001 at 05:13:36PM +0100, Paul Sherwin wrote:
> I still haven't managed to copy a large file from a Linux system to a
> uVaxII using linux-decnet under RH7.1 beta. I did the following:
> 
> 1. Obtained the source for kernel 2.4.2 and rebuilt it, specifying Decnet
> support be included in the kernel.
> 
> 2. Rebuilt dnprogs2.07 against this kernel.
> 
> This has made absolutely no difference. The Linux Decnet node is seen by,
> and sees, the Vax node, and files can be copied from the Vax to the Linux
> box with no obvious problems. Sethost also works. However, if the same file
> is copied back to the Vax, the following happens:
> 

Oh dear, it happens here too. It seems OK to phase V nodes but not phase IV.

patrick

[Linux-decnet-user] More RH7.1 / kernel 2.4 copying woes

[Paul S. <psh...@st...>]

I still haven't managed to copy a large file from a Linux system to a
uVaxII using linux-decnet under RH7.1 beta. I did the following:

1. Obtained the source for kernel 2.4.2 and rebuilt it, specifying Decnet
support be included in the kernel.

2. Rebuilt dnprogs2.07 against this kernel.

This has made absolutely no difference. The Linux Decnet node is seen by,
and sees, the Vax node, and files can be copied from the Vax to the Linux
box with no obvious problems. Sethost also works. However, if the same file
is copied back to the Vax, the following happens:

Red Hat Linux release 7.0.90 (Fisher)
Kernel 2.4.2 on an i486
login: root
Password: 
Last login: Mon Mar 26 16:34:16 from 192.168.0.214
You have mail.
[root@OldTimer /root]# cd /tmp
[root@OldTimer /tmp]# dncopy -vvv -mblock -rfix /tmp/starlet.olb
'psc"system"::dua0:[paul]'
Sending message of type CONFIG
wrote 17 bytes
read: read 21 bytes
Got message of type CONFIG
Remote buffer size is 32767
Using block size 32767
Remote OS is 7
in dap_send_attributes()
Blocked output is ON
Sending message of type ATTRIB
Sending message of type ALLOC
Blocked output is OFF, sending 14 bytes
wrote 14 bytes
Sending message of type ACCESS
wrote 32 bytes
in dap_get_file_entry()
read: read 63 bytes
Got message of type ATTRIB
Got message of type PROTECT
Got message of type NAME
Got message of type ACK
in dap_send_connect()
Sending message of type CONTROL
wrote 5 bytes
in dap_get_reply()
read: read 2 bytes
Got message of type ACK
in dap_send_get_or_put($PUT)
Sending message of type CONTROL
wrote 6 bytes
in dap_put_record(512 bytes)
Blocked output is ON
Sending message of type DATA
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
    /* LONG WAIT */
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
    /* LONG WAIT */
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
    /* LONG WAIT */
Wrote 32571 bytes, buffer size is now 517 bytes
in dap_put_record(512 bytes)
Sending message of type DATA
    /* REPEATED MANY TIMES */
in dap_put_record(512 bytes)
Sending message of type DATA
block is over-full(33088), Sending 32571 bytes
    /* HANGS (OR VERY LONG WAIT) */
    /* PRESS CTRL-C              */
[root@OldTimer /tmp]#

It's also not possible to copy the file from the other end using fal -ag.

I don't think there's anything very unusual about my setup, but I can't
believe nobody else has hit this problem since it's so easy to reproduce.
Help!

TIA, Paul 

Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
Mobile +44 (0)7931 578334   mailto:psh...@st...
Pager  +44 (0)7666 797228 

Re: [Linux-decnet-user] Binary file copy problems with 2.4 kernel

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

On Fri, Mar 23, 2001 at 03:28:22PM +0000, Paul Sherwin wrote:
> I'm having lots of trouble copying some binary files from a Linux system
> using a 2.4.0 kernel. dncopy seems to hang for no obvious reason, and
> copying from the VMS end using 'fal ag' doesn't work either. The files copy
> without problems from another box running a patched 2.2.13 kernel.
> 
> Admittedly these files are pretty strange (in fact they're RMS indexed
> files complete with all the indexing stuff etc.) but they're just data when
> all's said and done.
> 
> As I'm obviously using an unpatched kernel, I built dnprogs using the dn.h
> that came with it ('make please'). I suspect this wasn't the right thing to
> do - any suggestions?

You should *never* use make please !

If you have an unpatched 2.4.0 kernel (though 2.4.2 would be better) linked into
your /usr/include directory then make please should not be necessary. If it is
then copy the dn.h file from $(KERNEL_SOURCE)/include/linux/dn.h into the
dnprogs include/netdnet directory and do it again.

The symptoms you have do sound like the tools are built using the wrong include
file.

patrick

Re: [Linux-decnet-user] Binary file copy problems with 2.4 kernel

[Paul S. <psh...@st...>]

At 18:02 23/03/01 +0000, Steve Whitehouse wrote:

>Some enhancements to the DECnet layer have gone in since 2.4.0 one of these
>is a bug fix relating to the handling of flow control on DECnet connections
>which sounds very like what you are experiencing. It could also be a
>problem with the headers as you suggest since you should build the tools
>against the headers that came with the kernel. I'm not sure whether the 'it'
>you refer to means the kernel or the dnprogs distribution in this case.

Hmmm. dncopy fails progressively - the first few 32K chunks transfer
correctly, albeit slowly, and then the transfer hangs. The receiving
computer is a uVaxII with a fairly slow disk, so it probably can't keep up
with the incoming data rate - this does indeed point to a flow control
problem. I'll try to get get the 2.4.2 kernel patch and see what happens.

>2.4 has more advanced handling of many things than the 2.2 patch so it should
>be more reliable in general. You don't get any odd messages in your syslog
>I presume ? It should log various conditions that are unexpected in order to
>help in debugging. I understand that there are still problems with RSX
>boxes and 2.4, but PhaseV works reliably now. I'm still working on the RSX
>problem but I ran out of time and inspiration when I was last looking at
>it and I haven't had a chance since to look at it again,

Nothing in /var/log/messages.

Best regards, Paul


Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
Mobile +44 (0)7931 578334   mailto:psh...@st...
Pager  +44 (0)7666 797228 

Re: [Linux-decnet-user] Binary file copy problems with 2.4 kernel

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

Hi,

Some enhancements to the DECnet layer have gone in since 2.4.0 one of these
is a bug fix relating to the handling of flow control on DECnet connections
which sounds very like what you are experiencing. It could also be a
problem with the headers as you suggest since you should build the tools
against the headers that came with the kernel. I'm not sure whether the 'it'
you refer to means the kernel or the dnprogs distribution in this case.

2.4 has more advanced handling of many things than the 2.2 patch so it should
be more reliable in general. You don't get any odd messages in your syslog
I presume ? It should log various conditions that are unexpected in order to
help in debugging. I understand that there are still problems with RSX
boxes and 2.4, but PhaseV works reliably now. I'm still working on the RSX
problem but I ran out of time and inspiration when I was last looking at
it and I haven't had a chance since to look at it again,

Steve.

> 
> I'm having lots of trouble copying some binary files from a Linux system
> using a 2.4.0 kernel. dncopy seems to hang for no obvious reason, and
> copying from the VMS end using 'fal ag' doesn't work either. The files copy
> without problems from another box running a patched 2.2.13 kernel.
> 
> Admittedly these files are pretty strange (in fact they're RMS indexed
> files complete with all the indexing stuff etc.) but they're just data when
> all's said and done.
> 
> As I'm obviously using an unpatched kernel, I built dnprogs using the dn.h
> that came with it ('make please'). I suspect this wasn't the right thing to
> do - any suggestions?
> 
> Apart from this, are there any known problems using 2.4 kernels?
> 
> TIA, Paul
> 
> Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
> Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
> Mobile +44 (0)7931 578334   mailto:psh...@st...
> Pager  +44 (0)7666 797228 
> 
> _______________________________________________
> Linux-decnet-user mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux-decnet-user
> 

Re: [Linux-decnet-user] Binary file copy problems with 2.4 kernel

[Paul S. <psh...@st...>]

At 15:28 23/03/01 +0000, I wrote:
>I'm having lots of trouble copying some binary files from a Linux system

>As I'm obviously using an unpatched kernel, I built dnprogs using the dn.h
>that came with it ('make please'). I suspect this wasn't the right thing to
>do - any suggestions?
>
I RTFMed and found the make script was checking in the wrong place for the
dn.h file (the wrong place in RedHat terms that is - the RH kernel source
RPM doesn't create a /usr/src/linux link to /usr/src/linux-2.4.0). Once I
made the link dnprogs rebuilt cleanly. 

dncopy still doesn't work though... :-(

Best regards, Paul


Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
Mobile +44 (0)7931 578334   mailto:psh...@st...
Pager  +44 (0)7666 797228 

[Linux-decnet-user] Binary file copy problems with 2.4 kernel

[Paul S. <psh...@st...>]

I'm having lots of trouble copying some binary files from a Linux system
using a 2.4.0 kernel. dncopy seems to hang for no obvious reason, and
copying from the VMS end using 'fal ag' doesn't work either. The files copy
without problems from another box running a patched 2.2.13 kernel.

Admittedly these files are pretty strange (in fact they're RMS indexed
files complete with all the indexing stuff etc.) but they're just data when
all's said and done.

As I'm obviously using an unpatched kernel, I built dnprogs using the dn.h
that came with it ('make please'). I suspect this wasn't the right thing to
do - any suggestions?

Apart from this, are there any known problems using 2.4 kernels?

TIA, Paul

Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
Mobile +44 (0)7931 578334   mailto:psh...@st...
Pager  +44 (0)7666 797228 

Re: [Linux-decnet-user] linux-decnet 2.05 / RedHat 7.1 beta

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

On Tue, Mar 20, 2001 at 11:24:58AM +0000, Paul Sherwin wrote:
> Local                                              Remote
>    0.0/2001 0001:0001 0000:0000 2 29                  0.0/0000 0000:0000
> 0000:0000 2 0                OPEN IMMED
> 
> /proc/net/decnet_neigh shows
> 
> Addr    Flags State Use Blksize Dev
> 0.0     ---   40    01  0001498 lo      
> 

You're running a 2.4 kernel - try doing

echo "1.6" > /proc/sys/net/decnet/node_address

You may also need:

echo "eth0" > /proc/sys/net/decnet/default_device


Make sure you've built the dnprogs from source too - the RPM on the
download site is for 2.2 kernels.

Patrick

[Linux-decnet-user] linux-decnet 2.05 / RedHat 7.1 beta

[Paul S. <psh...@st...>]

My apologies if this has been covered before in the list - I became
unsubscribed some time ago (maybe during the move to sourceforge) and never
got arounfd to resubscribing.

I've been using decnet 2.05 on a RH5.2 system with a patched 2.2.13 kernel
without problems. I'm now trying to get this to work with a new RH7.1 beta
release and am having _considerable_ problems!

The startup sequence with RH7.1 is different, but I'm initialising the
ethernet card with the correct hardware address (AA:00:04:00:06:04),
insmodding the decnet kernel module, and running startnet immediately
afterwards, which produces no errors. TCP/IP works fine.

/etc/decnet.conf is:

#
#		DECnet host files
#
#Node		Node		Name		Node	Line	Line
#Type		Address		Tag		Name	Tag	Device
#-----		-------		-----		-----	-----	------
executor	1.6 		name		old	line	eth0
node		1.5 		name		white
node		1.10 		name		psc

/proc/net/decnet shows

Local                                              Remote
   0.0/2001 0001:0001 0000:0000 2 29                  0.0/0000 0000:0000
0000:0000 2 0                OPEN IMMED

/proc/net/decnet_neigh shows

Addr    Flags State Use Blksize Dev
0.0     ---   40    01  0001498 lo      

/proc/net/decnet_route shows

Iface	Dest	GW  	Flags	RefCnt	Use	Metric	Mask		MTU	Window	IRTT
                                                   

If I do 'sethost psc' (which is a Vax) on the box, I get 'socket: No route
to host'. The Vax doesn't see the node (though it correctly sees the RH5.2
Linux system).

Does this ring any bells for anyone? All suggestions gratefully received.
(I need to get this working with the RH7.1 system because I need large file
support).

TIA, Paul


Paul Sherwin Consulting     22 Monmouth Road, Oxford OX1 4TD, UK
Phone  +44 (0)1865 721438   http://www.psherwin.strayduck.com
Mobile +44 (0)7931 578334   mailto:psh...@st...
Pager  +44 (0)7666 797228 

Re: [Linux-decnet-user] dnprogs password security

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

On Wed, Mar 14, 2001 at 07:05:42PM +0000, Patrick Caulfield wrote:
> ...And here's a patch for dntask...enjoy!

...and dnping is in CVS if you really want it...

patrick

Re: [Linux-decnet-user] dnprogs password security

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

...And here's a patch for dntask...enjoy!

Index: dntask/dntask.c
===================================================================
RCS file: /cvsroot/linux-decnet/dnprogs/dntask/dntask.c,v
retrieving revision 1.3
diff -u -r1.3 dntask.c
--- dntask/dntask.c	2001/01/21 13:36:58	1.3
+++ dntask/dntask.c	2001/03/14 19:04:35
@@ -437,6 +437,21 @@
         accessdata.acc_acc[0] = '\0';
 
 
+
+    /* If the password is "-" and fd 0 is a tty then 
+       prompt for a password */
+    if (accessdata.acc_pass[0] == '-' && accessdata.acc_pass[1] == '\0' && isatty(0))
+    {	
+	char *password = getpass("Password: ");
+	if (password == NULL || strlen(password) > (unsigned int)MAX_PASSWORD)
+	{
+	    lasterror = "Password input cancelled";
+	    return FALSE;
+	}
+	strcpy(accessdata.acc_pass, password);
+    }
+
+    
     /* Complete the accessdata structure */
     accessdata.acc_userl = strlen(accessdata.acc_user);
     accessdata.acc_passl = strlen(accessdata.acc_pass);

-- 

patrick

Re: [Linux-decnet-user] dnprogs password security

[Raimund H. <ra...@ba...>]

On Wed, Mar 14, 2001 at 09:39:04AM +0000, Patrick Caulfield wrote:
> Though it would be easy...try this patch. Entering a password of "-" will then
> prompt you.
> 
> eg:
> 
> dncopy 'trisha"patrick -"::login.com' mylogin.com

[Modification of libdap/connection.cc]

> +    /* If the password is "-" and fd 0 is a tty then 
> +       prompt for a password */
> +    if (password[0] == '-' && password[1] == '\0' && isatty(0))
> +    {
> +	password = getpass("Password: ");
> +	if (password == NULL || strlen(password) > (unsigned int)MAX_PASSWORD)
> +	{
> +	    strcpy(errstring, "Password input cancelled");
> +	    lasterror = errstring;
> +	    return false;
> +	}
> +	
> +    }
> +

It works perfectly for dndir, dnprint, dncopy, dntype :-)
Thank you very much.

The exception is dntask. Dntask prompts not for Password and send a
"connection refused", if I set "-" for Password.

Greetings
Raimund

-- 
Life's too short to read boring signatures

Re: [Linux-decnet-user] dnprogs password security

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

Though it would be easy...try this patch. Entering a password of "-" will then
prompt you.

eg:

dncopy 'trisha"patrick -"::login.com' mylogin.com


patrick


Index: libdap/connection.cc
===================================================================
RCS file: /cvsroot/linux-decnet/dnprogs/libdap/connection.cc,v
retrieving revision 1.4
diff -u -r1.4 connection.cc
--- libdap/connection.cc	2001/01/21 13:36:58	1.4
+++ libdap/connection.cc	2001/03/14 09:36:30
@@ -230,6 +230,20 @@
 	return false;
     }
 
+    /* If the password is "-" and fd 0 is a tty then 
+       prompt for a password */
+    if (password[0] == '-' && password[1] == '\0' && isatty(0))
+    {
+	password = getpass("Password: ");
+	if (password == NULL || strlen(password) > (unsigned int)MAX_PASSWORD)
+	{
+	    strcpy(errstring, "Password input cancelled");
+	    lasterror = errstring;
+	    return false;
+	}
+	
+    }
+
     memcpy(accessdata.acc_user, user, strlen(user));
     memcpy(accessdata.acc_pass, password, strlen(password));
     memcpy(s.sdn_add.a_addr, binadr->n_addr, sizeof(s.sdn_add.a_addr));
@@ -248,7 +262,7 @@
     }
     else
         accessdata.acc_acc[0] = '\0';
-    
+
 
     accessdata.acc_userl = strlen(user);
     accessdata.acc_passl = strlen(password);

Re: [Linux-decnet-user] dnprogs password security

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

On Tue, Mar 13, 2001 at 10:50:16PM +0100, Raimund Huemmer wrote:
> Hi,
> 
> using the dnprogs (dndir, dntask, dncopy,...), I have to type the
> password clear readable on my shell.
> 
> Is there any way, to type the password unreadable?
> 

Currently not I'm afraid. Unless you have proxies set up at the VMS end (and
there are a few reasons why you shouldn't to that).

I'll take that as a feature request - it shouldn't be too hard to build in :-)

patrick

[Linux-decnet-user] dnprogs password security

[Raimund H. <ra...@ba...>]

Hi,

using the dnprogs (dndir, dntask, dncopy,...), I have to type the
password clear readable on my shell.

Is there any way, to type the password unreadable?

Raimund

-- 
Life's too short to read boring signatures

[Linux-decnet-user] Can not install dnprogs on debian

[Chin Yung<chi...@ki...>]

Hi,
  I want to install dnprogs_2.07-2_i386.deb on debian 2.2 r2. However, when I use 
  # dpkg -i dnprogs_2.07-2_i386.deb 
(Reading database ... 20195 files and directories currently installed.)
Unpacking dnprogs (from dnprogs_2.07-2_i386.deb) ...
Setting up dnprogs (2.07-2) ...

then it halts.
  The kernel I used is 2.4.2, and there is a file called decnet in the /proc/net directory. So I think that I have successfully made my new kernel with decnet. Why can not I install dnprogs? Do I have something wrong?


Best regards,

chiniung

--------------------------------------------------------------------
奇摩電子信箱•溝通心世界  http://mail.kimo.com.tw
< 網 路 生 活•盡 在 奇 摩 >  http://www.kimo.com.tw

[Linux-decnet-user] latd 1.02 released

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

The main change for this release is the much-requested llogin program but there
are other nice changes too. Particularly appreciated (I hope) will be the bug
that forced you from naming the node as well as service when requesting
reverse-LAT ports.

The download site contains Intel binaries as well as the usual source. The DEB
file is for potato. If you're using Debian woody then the DEB file is on it's
way into the Debian archive and should be there in a couple of days.

Here's the changelog

  * Fixed bug where you *had* to specify a node name in reverse connections
  * New llogin program
  * This file is now a Debian changelog
  * Fix keepalives when connected to Tru64
  * Tidied MAC address internals
  * In fact, quite a lot of internal tidying and bug-fixing.
  * Move sockets into /var/run as per FHS
  * Fixed EOF trapping on local ports
  * Fixed latcp -d display of local ports (node & service were swapped)
  * Changed example latd.conf to show we can connect to services without 
    specifying a node name now

Patrick