Ethan Gold (etgold@cs.vassar.edu): I think the problem of atlook crapping out on you is a CAP problem, not a macbsd one. I run CAP on a sparc5 with 24mb RAM under 4.1.3 and I get the same error when I try a generic lookup on a full zone. if you do an atlook for a specific nbp entity you should be able to avoid the dump. as for slowness, I don't know. David Hornsby : > From: "A. Forest Godfrey" > 1) atlook gags on the Carnegie Mellon campus network. Sometimes it > core dumps, other times it complains about an invalid name length, and > sometimes it does both. It NEVER displays all the nodes on the network. In cap60/samples/atlook.c, change the line #define NUMNBPENTRY 250 /* max names we can lookup */ to a bigger number. > 2) A bigger problem is that the AppleShare server (aufs) is > EXTREMELY slow! So slow as to make it unusable. It took 5 minutes to > write a 12k file yesterday on a machine that is on the same hub as the > server! As an aside, AppleTalk/AFP is very unforgiving of even minor packet losses, Packet Loss Time-LT Throughput-LT Time-ET Throughput-ET ------------------------------------------------------------- 0% 200 s 100% 15 s 100% 0.01% 205 s 97% 20 s 75% 0.05% 224 s 89% 39 s 38% 0.1% 248 s 81% 63 s 24% 0.5% 424 s 47% 255 s 6% (LT = LocalTalk, ET = EtherTalk, Time is for 1000 packets, numbers by Tom Evans). The usual suspect on a BSD host is having the Berkeley Packet Filter return multiple packets in a single read. CAP copes with this OK assuming that MULTI_BPF_PKT gets defined in cap60/support/ethertalk/bpfiltp.c On NetBSD this is handled by #ifdef __NetBSD__ Check that your sources have this in place. Otherwise check that your ethernet card is working OK by using ping or spray etc. to send a bunch of packets to the CAP host. Check for log or console error messages. Kazunari Nakamura : From: "A. Forest Godfrey" > 2) A bigger problem is that the AppleShare server (aufs) is > EXTREMELY slow! Try to add following line in "m4.features", and rebuild CAP programs !! define(`specialcflags',concat(specialcflags,` -DATPREQCACHE')) David Hornsby : > From: tferris@umich.edu (Todd Ferris) > If Netatalk doesn't work, what about CAP? I saw one message on the list > regarding CAP. Does it compile "out of the box"? Is there anyway to > attach a localtalk printer? or do you need to attach via serial cable? Enclosed is a copy of a response I posted to a similar question. You would need to use the serial cable and make the printer work under lpr, then you could use CAP's lwsrv to make it visible to other EtherTalk Macs. > > From: David Hornsby > > Sender: owner-port-mac68k@NetBSD.ORG > > > > CAP support for NetBSD 1.0 (at least the mac68k version) was added > > in CAP patch number 195. It compiles and runs fine here on a Mac IIx > > running 1.0 with slightly hacked networking code. There is no reason > > that it should not work on more recent kernels, I just haven't tried it. > > > > CAP patch info etc. info is available in > > > > ftp://munnari.OZ.AU/mac/CAP.faq > > http://www.cs.mu.OZ.AU/appletalk/atalk.html Charles Owens : I am setting up a mailing list to facilitate communication between folks who are trying to provide Appletalk services using FreeBSD (NetAtalk, CAP, etc.). Our beloved operating system has much to offer in this regard, but there's work to be done to polish things up and to better support those who are trying to implement such services. Make yourself heard!!!! If you're interested, send a note to fbsd-request@enc.edu Post all contributions to the list to fbsd-atalk@enc.edu Feel free to tell others about this list. For now, I'm maintaining it by hand, but I'll switch to majordomo if need be.