Date: Tue, 22 Jun 93 04:30:08 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #161
To: tcp-group-digest
TCP-Group Digest Tue, 22 Jun 93 Volume 93 : Issue 161
Today's Topics:
drsi stat
FTP from additional drives (2 msgs)
MESSAGE SLIP LINK PROBLEMS (2 msgs)
my slip link problems
NOS and Serial Ports
paclen > 256
Password security
Print services in ka9q NOS
RFC 791, IP options
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Mon, 21 Jun 93 15:16:04 PDT
From: efb@suned1.Nswses.Navy.Mil (Everett F Batey)
Subject: drsi stat
To: KC4BZK@delphi.com
--
+ efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org +
+ efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu +
+ Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns WAFFLE +
------------------------------
Date: Mon, 21 Jun 93 11:34:26 BST
From: A.D.S.Benham@bnr.co.uk
Subject: FTP from additional drives
To: nos-bbs@hydra.carleton.CA, TCP-Group@UCSD.Edu
One of my locals was asking if it was possible to configure the FTP server
to allow users access to other drives (he has some files on CD-ROM which
he thinks might be useful if they (and hence the CD-ROM) were available
on-line).
Well, having spent last week on an Object Oriented Analysis course, I spent
yesterday hacking JNOS 1.08d (don't let my boss find out I'm hacking code
after he's spent all that money on the course.....).
The outcome is that with a few changes in FTPSERV.C, PATHNAME.C, and
DIRUTIL.C, it works OK. It's not pretty, but it works (I guess that
describes me too :-)).
So, having done this, the request comes in from another user for different
access permissions for different paths. (Why do I listen to these users?).
The only way I can think of implementing this is to change the format of the
FTPUSERS file. What I have in mind is changing from:
g9zzz ethelred /usr/g9zzz;/public/;s:/utils 63
to:
g9zzz ethelred /usr/g9zzz 63;/public 3;s:/utils 3
The USERLOGIN process would read the leftmost permission, so the other
permissions would only be used for file access.
Now I might be able to detect 'old' and 'new' formats of FTPUSERS, but I
might not be able to detect this reliably.
Has anyone got any better ideas on how to implement this, maybe flames, etc.
Andrew Benham
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
adsb@bnr.ca +44 279 402372 Fax: +44 279 402029
Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP
--------------------------------------------------------------------
------------------------------
Date: Mon, 21 Jun 93 17:51:18 +0200
From: jt@fuw.edu.pl
Subject: FTP from additional drives
To: A.D.S.Benham@bnr.co.uk, TCP-Group@UCSD.Edu, nos-bbs@hydra.carleton.CA
> Message-Id: <9306211034.26219@bhars217.bnr.co.uk>
> From: A.D.S.Benham@bnr.co.uk
> Date: Mon, 21 Jun 93 11:34:26 BST
>
> One of my locals was asking if it was possible to configure the FTP server
> to allow users access to other drives (he has some files on CD-ROM which
...
> So, having done this, the request comes in from another user for different
> access permissions for different paths. (Why do I listen to these users?).
...
> Has anyone got any better ideas on how to implement this, maybe flames, etc.
I implemented it all at begin of 1992. It was on ucsd.edu, but now I was
unable to find it there. However it is still on zfja-gate (148.81.6.100)
in directory ./nos/pa0gri/local, file ftpd-20m.zip (for GRINOS 2.0m). 73's
------------------------------
Date: Mon, 21 Jun 1993 22:52:31 -0400 (EDT)
From: KC4BZK@delphi.com
Subject: MESSAGE SLIP LINK PROBLEMS
To: tcp-group@ucsd.edu
I UP LOADED A MESSAGE BUT I BELEVE IT HAD ERRORS IN IT. IM RESENDING
JUST INCASE....SORRY FOR THE EXTRA TRAFFIC....MESSAGE FOLLOWS
Ok i gess i should have been more complete in my question about a slip link
running at 9600 bps. My setup is two pc's one a 386 25mhz and the other an
10 mhz xt. The xt is used 24hr a day on our tcpip lan, the 386 is my machine
used for other than packet, like sending messages to the tcp-group..hi..hi.
My use of this slip link is to ftp files that arive from the area lan users
to my 386 for editing, processing or what ever. This link is used realy as
a way to keep the lan-nos box up at all times with out having to bring down
nos to xfer files back and forth.
The two pc's use the standard com ports, a full rs-232 cable, and a null modem
adapter. This works just fine at 2400 bps but when bumped up to 9600 bps it
fall's apart. Watching the trace data on the slip port shows that it is rx'ing
data but has a check sum error on every frame. Bring the speed back down and
it works just fine again.
There were many replys that said to use a 16550 FIFO card. as i under stand
this is a new and improved chip over what the old com cards had on them ( 8530 ? ).
Where can i get two of them ( com card's) and what kind of cost am i looking at???
Thanks for all the replys!!!
Dave..............kc4bzk@delphi.com
------------------------------
Date: Tue, 22 Jun 93 10:27:33 +0200
From: jt@fuw.edu.pl
Subject: MESSAGE SLIP LINK PROBLEMS
To: KC4BZK@delphi.com, tcp-group@ucsd.edu
> Date: Mon, 21 Jun 1993 22:52:31 -0400 (EDT)
> Message-Id: <01GZNNPKFI0Y9EDJ7Y@delphi.com>
>
> There were many replys that said to use a 16550 FIFO card. as i under stand
> this is a new and improved chip over what the old com cards had on them ( 8530 ? ).
> Where can i get two of them ( com card's) and what kind of cost am i looking at???
If you use COM cards with 8250 or 16450 chips on them (usually SLIP uses
just these chips, 8530 is Serial Communication Controller, not an async
chip), you can replace them by 16550A. Cost: 16550A-s can be ordered from
Questor (contact sp@questor.org), price $11 each + $3 shipping in USA.
Of course, card using any async chip using DMA instead being serviced by
CPU would be much better, but I don't know any... 73's, Jerzy
------------------------------
Date: Mon, 21 Jun 1993 22:30:12 -0400 (EDT)
From: KC4BZK@delphi.com
Subject: my slip link problems
To: tcp-group@ucsd.edu
Ok i gess i should have been more complete in my question about a slip link
running at 9600 bps. My setup is two pc's one a 386 25mhz and the other an
10 mhz xt. The xt is used 24hr a day on our tcpip lan, the 386 is my machine
used for other than packet, like sending messages to the tcp-group..hi..hi.
it works just fine again.
There were many replys that said to use a 16550 FIFO card. as i under stand
this is a new and improved chip over what the old com cards had on them ( 8530 ? ).
Where can i get two of them ( com card's) and what kind of cost am i looking at???
Thanks for all the replys!!!
Dave..............kc4bzk@delphi.com
------------------------------
Date: Mon, 21 Jun 1993 09:17:58 -0500 (CDT)
From: Mr. Sampson <ssampson@sabea-oc.af.mil>
Subject: NOS and Serial Ports
To: kc4bzk@delphi.com
NOS is pretty slow on serial port I/O. Best bet is to get a
couple of Ethernet or Arcnet cards and by-pass the serial ports.
I can't even get my 16 MHz 386sx to go 9600 to the TNC. If your
machine is slower than this, it's a bigger problem, as 2400 is
about all I got out of a 4.77 MHz XT. I'm satisfied at 4800 on
mine. To minimize the problem you should aquire 16550 FIFO
cards at each end, but surplus network cards (hell, even new
cards) are probably cheaper. The next generation of outboard
TNC should be 10BaseT compatible :-)
---
Steve, N5OWK
------------------------------
Date: 21 Jun 93 12:28:56 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: paclen > 256
To: tcp-group@ucsd.edu
Hi,
1.
I've been looking into using a paclen value > 256.
Some docs I read state that some versions of ax25 can't
handle this, so don't do it unless all your users are
running NOS. It also states that NOS will still have trouble
with some KISS TNCs. It further states that the k3mc firmware
will allow paclen > 256 on a TNC-2. If I blow the k3mc code
into a spare eprom I have and use that in my Tiny-2, am I
right in saying I'll be able to use paclen > 256?
2.
Also I'd like to play with a SLIP link. I seem to remember that
the connections are
1-1
2-3
3-2
7-7
is this correct.
3. The later versions of JNOS have an extended ip access command
allowing security based on both source and dest ip addresses.
My question concerns encapped packets. If they pass before being
decapped, might they fail after being decapped?
Thanks a lot
JJ
:: Jon Jagger , Sheffield Hallam University, S1 1WB, UK
:: Work J.R.Jagger@shu.ac.uk Home 2E1BSD (44.131.2.111)
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
------------------------------
Date: Tue, 22 Jun 93 10:03:33 +0200
From: jt@fuw.edu.pl
Subject: Password security
To: enge@almaden.ibm.com, mea@Mea.cc.utu.fi
> From: mea@Mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
> Message-Id: <9306200056.AA07714@mea.utu.fi>
> To: enge@almaden.ibm.com
> Date: Sun, 20 Jun 1993 03:56:41 +0300 (EED)
> In-Reply-To: <9306191614.AA20405@ucsd.edu> from "enge@almaden.ibm.com" at Jun 19, 93 07:13:21 pm
>
> > OK.. I will try it. Now, where do I find MD5 in either assembler
> > or Turbo Pascal?
> >
> > Roy, AA4RE
>
> In C and partial assembly in latest NOS sources.
> I was able to port NOS ftp-server's MD5 "file-signaturing"
> on a SPARC system.
>
> Assuming you have TP5 or later (with 32bit signed/unsigned
> integers), it should not be a problem at all to port is.
> However, do make "cut, and paste" copy of several vast
> arrays of data in the MD5. They are impossible to get
> right if you type by hand..
I have most of MD5 translated to macro assembler and can adapt it to be
called from Turbo Pascal. Few days ago I put a msg about it here, but
seems it was lost, so I am putting it again:
> From JT@zfja-gate.fuw.edu.pl Wednesday June 16, 1993 7:00:34 p.m.
> Date: Wed, 16 Jun 93 18:11:22 PST
> From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
> To: samisen!djc@sol.UVic.CA
> Cc: tcp-group@ucsd.edu
> Subject: Re: Password security
>
> > Message-Id: <9306142109.AA11402@sol.UVic.CA>
> > Date: Mon, 14 Jun 93 13:52:05 PDT
> > Reply-To: samisen!djc@sol.UVic.CA
> >
> > Thanks, JT. I'd love to try out this code when you have it together.
>
> I have put it on zfja-gate (148.81.6.100) in guest login directory
> as MD5A.ZIP (12kB, PKZIP 2.04 used) - use anonymous FTP or send mail
> to listserv@zfja-gate.fuw.edu.pl containing line "GET MD5A.ZIP".
>
> You can try to optimize it more by changing few parameters inside the
> .ASM file - but it is time-consuming because differences are too small
> to be easy to see. Look the file for some information how to try it.
>
> Anyway, can try to force compiler to optimize code, I don't have BC 3.1
> here and asked someone having it to compile the .C program but seems
> the compiler either cannot automatically decide to keep frequently used
> variables in registers without "register" keyword or requires some
> option to do it. If you have BC 3.1 try add a "register" keyword in
> local variables declaration in MD5Transform (but use MD5C.C from
> MD5S.ZIP), compile with all possible optimization and compare speed
> with my code. Note original code calls C functions to move data and
> clear buffer and time spent on it is significant: my code is 3.5 times
> faster than C, and only 2.5 times after removing these calls...
>
> Some suggestion if guessing S(n-1) is to be harder and computing S(n)
> is to take a bit less time: MD5 has "state" in form of 4 32-bit words
> and usually the state is initialized to some predefined value and
> changed by every 64-byte block processing by MD5Transform() and the
> state after processing last block is the final result S1; to compute
> S2 don't put the S1 in data buffer but in the state and pass all zeros
> as data - in other words, invoke MD5Init, then MD5Transform(password),
> then many times MD5Transform(zeros). This is not pure MD5, but pure
> MD5 allows go back by one step of 64 used to produce digest if data
> size is known to be just the 128 bits (anyway, reversing it seems to
> be impossible). This causes some change in password verification:
> data received as password must be put in state, not data buffer and
> data buffer must be preset to all zeros, then MD5Transform (possibly
> repeated few times) should produce state same as saved password.
>
> > I'm an old assembly hacker from way back - but so far I have managed to
> > keep my hands completely uncontaminated by *86 code...
>
> What assembly languages you tried till now ?
> I wrote a lot on old CYBER-73 in central and peripheral processors
> assembly code, and also in Buffer Controller assembly code (except
> central processor they were available for system analysts only),
> and some programs in PDP-11, 6809 and 68000, 6502, 8080 assembly
> languages. And, of course, much *86 code... 73's, Jerzy
If Turbo Pascal (TASM+TP) version will be available, its name will be
MD5P.ZIP (now, can try get MD5A.ZIP, but remember it user SMALL memory
model - must be linked with $F- and offsets, not pointers should be
passed to assembly code). I don't expect porting MD5 to Turbo Pascal
using ASM statements in TP to be easy work - my .ASM source heavily
uses macro instructions (without them the .ASM source would be very
long and hard to read) and TP doesn't allow them; note also you have
nothing like macro in Turbo Pascal and MD5 in C heavily uses #define-s
(which are form of macro) to make the code readable. If it is really
needed, can replace these macro by procedure calls, it has advantage
of reducing code size but will increase execution time. 73's, Jerzy
------------------------------
Date: Sun, 20 Jun 93 15:03:48 GMT
From: ik3ngu@ntt.glt.esercito.it (Pasquale Pizzichetti)
Subject: Print services in ka9q NOS
To: tcpgroup%ucsd.edu.@osi.iunet.it
I work with PA0GRI's NOS version (2.0m) and I wish to use the
print services built in source code. Naturally I compiled the executable
with the client and server LPD and I think all is right .
But I do not know how to operate with LPD.
I can imagine the I have to attach the asyncronous com port with "raw" mode,
but can I use the parallel port ? if yes , How?
And then how can initialize the print server lpd apart to give nos the
command "start lpd"?
The PA0GRI documentation is lack about that , so I wonder if someone has
experience on it.
All kind of information are welcomed.
Thanks for now.
Lino ik3ngu@osi.iunet.it Internet
(ik3ngu@ir3tvt.ampr.org 44.134.176.202 Amprnet)
------------------------------
Date: Fri, 18 Jun 93 18:17:31 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: RFC 791, IP options
To: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>,
I'm catching up on a *big* pile of email, and I'm seeing what appears to be
a repeat of a security discussion that has happened several times before
on tcp-group.
I implemented the one-time-password scheme that used an iterated 1-way
function (MD-4) back at Bellcore before I left. It's up and running on
UNIX systems (you need to hack login.c, su.c and any other system program
that accepts passwords). I'll ask to see if I can distribute it.
Phil
------------------------------
End of TCP-Group Digest V93 #161
******************************
******************************