netatalk faq
The most frequently asked questions are all answered in the man pages that
are packaged with netatalk.
Please consult these first.
1. General Information
2. Troubleshooting
netatalk is a kernel-level implementation of the AppleTalk Protocol
Suite, originally for BSD-derived systems. It includes support for
routing AppleTalk, serving Unix and AFS filesystems over AFP
(AppleShare), serving Unix printers and accessing AppleTalk printers
over PAP. A number of other minor printing and debugging utilities are
also included.
The latest full release is: 1.3.3
The latest beta release is: 1.4b2
1.4b3 is on its way soon.
The solaris kernel module is rewritten, eliminating many routing problems and
kernel panics. Support for papd printing has been added, and there are plans
for piped printing with papd in the works.
1.4 full-release will follow soon.
Changes in 1.4.x may include fixed directory-IDs and ATP in the kernel,
with dynamically calculated retry timers. ADSP might show up. A
portion of the NBP table could go into the kernel, so that NBP entries
go away magically when sockets are closed. We are considering adding
AppleTalk over PPP to a freely redistributible PPP implementation.
1.5 What's this acronym mean?
DDP - Datagram Delivery Protocol
RTMP - Routing Table Maintenance Protocol
NBP - Name Binding Protocol
ZIP - Zone Information Protocol
AEP - AppleTalk Echo Protocol
ATP - AppleTalk Transaction Protocol
PAP - Printer Access Protocol
ASP - AppleTalk Session Protocol
AFP - AppleTalk Filing Protocol
aecho - send AppleTalk Echo Protocol packets to network hosts
atalk - AppleTalk protocol family
atalkd - AppleTalk RTMP, NBP, ZIP and AEP manager
papd - AppleTalk printer daemon
psf - Postscript Filter
psorder - PostScript pageorder filter
routednetwork routing daemon
ifconfigconfigure network interface parameters
- AIX: No longer supported.
- FreeBSD: v2.2 and after contains support for netatalk.
- Irix/SGI: A port is neither existent, nor in the works.
- Linux: 1.3.x comes with AppleTalk support in the kernel, and netatalk
1.3.3 contains support for Linux.
- NetBSD: current now includes netatalk kernel support. The first
official release to include this will be NetBSD 1.3. As far as netatalk is
concerned, the final version of 1.4 will contain this support.
- NeXT: We are no longer working on a port.
- Solaris: 2.4 and greater has beta support in
netatalk-1.4b2.
- SparcLinux: patches by Tom Dyas exist, and may be incorparated soon.
- Ultrix: supported in both 1.3.3 and 1.4b2.
It depends. For BSD-derived machines, expect to need full source. For
sysV machines, porting the STREAMS version of netatalk may be easy.
The primary difference between netatalk and CAP is structure, in two
ways. First, netatalk is a kernel-level implementation of AppleTalk.
This means that packet reception in general and routing in particular
are both efficient and easy to implement. It also means that new
link-layers (e.g. we support some FDDIs, one could add PPP) can easily
be added. CAP, on the other hand, relies on several less efficient tho
more available methods (e.g. DDP-over-UDP, NIT, Berkeley Packet
Filters).
The second structural difference is in coding style. netatalk is
an integration of AppleTalk into the Berkeley Unix networking
paradigm. All of the semantics useful to the UDP/TCP programmer
are useful to the netatalk-AppleTalk programmer, e.g. sendto(),
select(). In contrast, CAP is written with the semantics of
MacOS.
All of the above differences are of primary interest to the
developer and administrator. The end user will probably only
notice that netatalk is somewhat faster than CAP (an artifact of
both the architecture and coding style).
The mail archive of our mailing list has proved
helpful to many, as well as our netatalk-related links
Ah, good question! The unenlightened often mis-pronounce this word
\'net-'a-to.k\. The correct pronunciation is \'ned-*-to.k\ (the
't' is soft, like d, and the first 'a' is a schwa).
Look wherever syslog logs the LOG_DAEMON facility. You are likely to find a
message like "illegal shell /bin/tcsh for bob". This is because afpd
uses getusershell(3) to verify that users have valid shells.
getusershell reads /etc/shells. It's also possible you need
shadowed password support.
This is a very common configuration error. The user is not in the
group of the parent directory. Then the Mac attempts to set the group
of the newly created directory to be the same as the parent, this error
is generated. The fix is the change the group of the directory to a
group the user is a member of.
When pap is run by psf, which is run by lpd, its working
directory is the spool directory as assigned in /etc/printcap. Therefore
the .paprc must be in the spool directory. pap logs error to
stdout, which will appear in the log file assigned in /etc/printcap.
You've upgraded Suns lpd system with one of several security patches. It moved
/dev/printer to /dev/lpd/printer. My current suggestion is to make a symlink
from /dev/printer to /dev/lpd/printer. Maybe later we'll have netatalk check
for both.
To completely disable all CRLF translation, you should remove -DCRLF from afpd's
Makefile.
If your system uses shadowed passwords, add "-DSHADOWPW" to the "CFLAGS="
portion of the Makefile in etc/afpd.
Send comments about this page to
netatalk@umich.edu
Go back to netatalk home page.