On Mon, Jul 12, 2010 at 1:54 PM, Jordon Bedwell <span dir="ltr"><<a href="mailto:jordon@envygeeks.com">jordon@envygeeks.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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

<br><div style="margin-left: 40px;"><font size="1"><span style="font-family: courier new,monospace;">Jul 12 14:12:17 rainforest afpd[855]: shutting down on signal 15</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: Registering CNID module [last]</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: Registering CNID module [cdb]</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: Registering CNID module [dbd]</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: Loading ConfigFile</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: main: </span><b style="font-family: courier new,monospace;">atp_open: Cannot assign requested address</b><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: uam: loading (/usr/lib/netatalk/uams_dhx2.so)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: uam: uams_dhx2.so loaded</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: uam: loading (/usr/lib/netatalk/uams_clrtxt.so)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: uam: uams_clrtxt.so loaded</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: Finished parsing Config File</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Jul 12 14:12:19 rainforest afpd[3979]: main: </span><b style="font-family: courier new,monospace;">no servers configured</b></font><br>

</div> <br>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.<br>

<br>Anyway, when I get a little more time, I'll probably trot over here:<br><br><a href="https://answers.launchpad.net/ubuntu/+source/netatalk" target="_blank">https://answers.launchpad.net/ubuntu/+source/netatalk</a><br>

</div></div>