Re: Apple and linux question

[dempson@actrix.gen.nz (David Empson)]

<kmitchel@my-dejanews.com> wrote:

> In article <371B5F20.F2B80A6D@mbnet.mb.ca>,
>   Mike Pfaiffer <pfaiffer@mbnet.mb.ca> wrote:
> > Ingo Soetebier wrote:
> > >
> > > There's a option to compile Appletalk in a Linux kernel. I haven't used
> > > it, but maybe you can connect from the Linux box direct to the IIgs via
> > > Appletalk.
> >
> >     Rumor has it people in this newsgroup have already tried. Apparently it
> > will only work with the Mac if at all. OTOH, I wonder how hard it would
> > be to add in the necessary features to allow exactly this...
> 
> I'm using LinuxPPC on a G3, and run netatalk-1.4b2+asun2.0a18.2 to serve
> Appletalk IP.  This works fine using Macs, but when I try logging in with a
> GS, I get "The file server "moscow150" does not use a recognizable log on
> sequence. You cannot connect to it."

This probably means that the Linux implementation of the Appletalk
Filing Protocol (AFP) doesn't support the user authentication method
used by the IIgs.

AFP has several alternative user authentication methods (UAMs), which
vary in the amount of encryption applied to the password as it is
transferred over the network (or not, as the case may be).  The client
and server negotiate as to which method to use.

On a Mac client, you can add set up additional UAMs by adding
extensions.  The main example of this is for a Novell Netware server.

The IIgs has no support for additional UAMs - you have to stick to the
one supported by the Appleshare FST (cleartext).

Digging out my Inside AppleTalk book:

AFP has three standard UAMs.  Servers and clients may implement any or
all of these, or additional proprietary ones.

1. No user authentication.

You don't even get to enter a user name or password - the server just
assigns you default access (probably the same as a guest login).  I
suspect this method is not accepted by any non-hobbiest servers.

2. Cleartext password.

The user name and password are sent to the server as part of the login
request, without any encryption.  This isn't very safe, as a packet
sniffer can easily grab passwords on the network.

3. Random number exchange.

The server provides a random number to the workstation.  Both machines
generate an encrypted copy of the number, using the password as a key.
The workstation sends the result back to the server, and the user gets
to log in if the result matches.

The IIgs doesn't support this method, for at least two reasons:

(i) The login sequence is more complicated, involving two message
exchanges with the server.  I think the way the calls are implemented
prevented this method from being used, though this limitation may have
been removed in later versions of the protocol stack.

(ii) The encryption (DES) is pretty CPU intensive, and I expect it would
require a lot of code (and time) to implement on a 6502/65816.


I imagine the best solution here would be to add cleartext password
support to netatalk.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand