Chapter 12 of Linux: Networking for Your Office mentions a bug in Netatalk when using kernels past version 2.2.8. The problem is that Netatalk breaks the connection when a Mac tries to mount a partition that contains a Macintosh HFS disk (like a floppy or Zip disk, or an HFS volume if you're running Linux on a Mac). In some cases, the Mac can crash when this happens. I've run across a Netatalk RPM that fixes this problem. You can obtain it here:
Note: Netscape for Windows and Netscape for Mac both sometimes corrupt files whose types they don't understand. Check the file size (in bytes) against what I've listed above. If they don't match, try to download the files using another browser. Netscape in Linux works fine, as does Internet Explorer.
I've had limited success with this patched version of Netatalk, however; it often seems to cause my iMac (running MacOS 8.6) to fail when trying to save documents. Presumably the patch's original author, at least, doesn't have this problem, so you might not, either, but I advise caution nonetheless.
As an aside, I'll say SuSE includes its own Netatalk package, which you should use rather than the one included with L:NfYO. SuSE doesn't appear to have an update to Netatalk on their web site to address this problem.
Most Linux distributions, including Red Hat, use the lpr printing system. With these OSs, printing with Netatalk works well as described in L:NfYO. Some Linux distributions, however, use non-lpr printing systems. Caldera 2.3, for instance, ships with LPRng, a replacement printing system that's mostly lpr-compatible. Unfortunately, "mostly" doesn't include Netatalk. At best, Netatalk accepts a print job but leaves it in the queue, unprinted, when Linux uses LPRng. At worst, the job isn't accepted at all (producing a PostScript error message on the Mac and a message in /var/log/messages about a missing lock file).
The solution, fortunately, is simple: You must pipe your printout through lpr (or whatever printing software your system supports; note that LPRng's printing program is called lpr). You can do this by changing the pr= entries for your printers in papd.conf. For instance, here's a configuration as described in L:NfYO:
hp4000:\ :pr=hp4000:op=mac:\ :pd=/etc/atalk/ppds/hp4000-mac.ppd:
You merely need to change this entry to:
hp4000:\ :pr=|/usr/bin/lpr -Php4000:op=mac:\ :pd=/etc/atalk/ppds/hp4000-mac.ppd:
The changed entry works fine with Caldera OpenLinux 2.3. Similar changes should work with other LPRng-based systems, or even systems with even more different printing configurations.
A recent exchange on comp.os.linux.networking has revealed a quirk of the Netatalk papd.conf file: You must indent the second and subsequent lines of each printer definition! For instance, only the first of the following two printer definitions works:
hp4000:\ :pr=hp4000:op=mac:\ :pd=/etc/atalk/ppds/hp4000-mac.ppd: hp4050:\ :pre=hp4050:op=mac:\ :pd=/etc/atalk/ppds/hp4050-mac.ppd:
This quirk caused a lot of grief for the individual who encountered it!
There's a bug in versions of Ghostscript prior to 5.50. This bug causes Ghostscript to choke on some fonts delivered by at least some versions of the Macintosh PostScript driver. This problem is apparently restricted to Type 42 fonts -- that is, TrueType fonts encoded in a PostScript wrapper. Unfortunately, the Mac PostScript driver sometimes adds fonts to files unnecessarily, so this problem can crop up even if you don't use any unusual fonts. So if you have problems printing files that include text, but graphics-only files print OK, you may want to try upgrading your version of Ghostscript. Check with your distribution maintainer to see if they've got version 6.0 or later. If not, check ftp://ftp.tex.ac.uk/tex-archive/support/ghostscript/aladdin/gs601/linux/, a directory that contains (as of 5/31/2000) two Ghostscript RPMs: ghostscript-6.01-1.i386.rpm and ghostscript-fonts-6.0-1.noarch.rpm. There are also source RPMs in the same directory, so if you have problems with these or aren't running on Intel-compatible hardware, you can recompile for your system. You can, of course, also check the main Ghostscript web site.
I encountered a peculiar problem when I reconfigured my network: Although Netatalk worked fine on an NDC SOHOware 10/100 NIC (using a Macronix Tulip clone chipset), it didn't work when I switched the local network to use a D-Link DFE-530TX board (which uses a VIA Rhine chipset). More precisely, the functions that rely on AppleTalk's non-TCP/IP functions seemed broken, including print services and locating machines on the network. I could connect when I typed in the server's "raw" IP address.
A little digging on Deja.com reveals that some other cards have problems with Netatalk, too, unfortunately including some of the otherwise very good and popular Intel EtherExpress line. The Intel cards exhibit somewhat different symptoms than does my D-Link -- the NIC starts sending out corrupt packets after it's been running Netatalk for a while. The explanation given in the case of the Intel board is that it must go into promiscuous mode to handle multicasting, which is used by AppleTalk, and that this causes problems. I don't know if the problem with the D-Link is the same. I also don't know if these problems have been solved in the development kernel series.
The bottom line is this: If you have troubles getting AppleTalk working or if running Netatalk seems to corrupt your network traffic, try replacing the NIC. I've successfully used NDC SOHOware 10/100, Linksys LNE-100TX, and Kingston KNE-100TX NICs, all of which use DEC Tulip chipsets or clones thereof. I've heard the NetGear FA-310TX (another Tulip clone board) also works well. I've also received a report that the SMC 1211TX EZ Card 10/100, which uses the rtl8139 Linux driver, works well with Netatalk. I can't speak to other cards at this point, but if you'd like to submit information on what you've used (successfully or not), I can compile it here.
Copyright © 1999, 2000 by Rod Smith, firstname.lastname@example.org
Return to main page.