no AppleTalk?

[Pete Gontier]

On Mon, Jul 12, 2010 at 1:54 PM, Jordon Bedwell <jordon at envygeeks.com>wrote:

> On 7/12/2010 2:39 PM, NoOp wrote:
> > On 07/12/2010 12:21 PM, Pete Gontier wrote:
> >> Yep; I too googled around and experimented with editing the
> configuration
> >> files and restarting and that sort of thing.
> >>
> >> I completely understand about AppleTalk being so old that hardly anybody
> >> tests with it. Heck; even Mac OS has abandoned support for AppleTalk at
> this
> >> point. Most people would have worn out one of these printers and
> replaced it
> >> by now, but I use it only once every few months, so its page count is
> very
> >> low for its age.
> >>
> >> The fact that I can mount my Ubuntu home on Mac OS proves only that AFP
> over
> >> IP works; it doesn't prove that DDP works. I haven't yet tried to
> configure
> >> printing. I'm trying to get any evidence that DDP works at all before
> trying
> >> to make any higher-level protocol work. So far, every indication I get
> is
> >> that DDP doesn't work, so if I were to try to make printing work I'd
> just be
> >> driving myself crazy with another layer of error abstraction. :-)
> >>
> >
> > Jordan already pointed to:
> > http://packages.ubuntu.com/lucid/net/netatalk
> > to the right is bug reports:
> > https://launchpad.net/ubuntu/+source/netatalk/+bugs
> > Check there and ask in 'Answers':
> > https://answers.launchpad.net/ubuntu/+source/netatalk
> >
> > I reckon those are your best bets as the questions and/or bug reports
> > typically will get the attention of the maintainer.
> >
> > Also, please bottom post on this list - thanks :-)
> > http://www.ubuntu.com/support/community/mailinglists
>
>
> I just wanted to point out that upstream bug #33415 does affect route,
> they actually fixed the bug somewhat, but later it was broken again
> because the paths changed to:
>
> (This was pointed out in the upstream bug)
>
> /proc/net/atalk
> /proc/net/atalk/arp
> /proc/net/atalk/socket
> /proc/net/atalk/route
> /proc/net/atalk/interface
>
> A cat on /proc/net/atalk/route proves this as true.  I succesfully
> loaded Appletalk, I have not been able to test DDP, I guess I could mock
> the protocol or go and get an old Apple printer (which would not be very
> hard for me since the highschool has a bunch and I know the
> administrator) I told the server to start ddp with -ddp flag on - in
> afpd.conf (- -ddp -notcp) and it did not complain one bit. Disable TCP
> and see if you can still connect, let us know what happens.
>

If I disable TCP, I definitely won't be able to connect, because recent
versions of Mac OS have dropped AppleTalk support. However, it might still
be an interesting exercise to just watch what happens in the log after I
change afpd.conf to contain - -ddp -notcp. (The default is supposed to be to
try both.)

Jul 12 14:12:17 rainforest afpd[855]: shutting down on signal 15
Jul 12 14:12:19 rainforest afpd[3979]: Registering CNID module [last]
Jul 12 14:12:19 rainforest afpd[3979]: Registering CNID module [cdb]
Jul 12 14:12:19 rainforest afpd[3979]: Registering CNID module [dbd]
Jul 12 14:12:19 rainforest afpd[3979]: Loading ConfigFile
Jul 12 14:12:19 rainforest afpd[3979]: main: *atp_open: Cannot assign
requested address*
Jul 12 14:12:19 rainforest afpd[3979]: uam: loading
(/usr/lib/netatalk/uams_dhx2.so)
Jul 12 14:12:19 rainforest afpd[3979]: uam: uams_dhx2.so loaded
Jul 12 14:12:19 rainforest afpd[3979]: uam: loading
(/usr/lib/netatalk/uams_clrtxt.so)
Jul 12 14:12:19 rainforest afpd[3979]: uam: uams_clrtxt.so loaded
Jul 12 14:12:19 rainforest afpd[3979]: Finished parsing Config File
Jul 12 14:12:19 rainforest afpd[3979]: main: *no servers configured*

I've seen "atp_open: Cannot assign requested address" before from many
netatalk userland programs. I suspect this log line indicates afpd
discovering for itself that it can't do DDP. However, "no servers
configured" is new. Indeed, when TCP is turned on, an apfd process sticks
around, and when TCP is turned off, no afpd process lives. And that makes
sense; there'd be no point in lingering without any passive network
connections to tend. What's interesting about this is that I think it tells
me that if afpd thought DDP were working then afpd would have stuck around.

Anyway, when I get a little more time, I'll probably trot over here:

https://answers.launchpad.net/ubuntu/+source/netatalk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20100712/e8241834/attachment.html>