Mac OS X and Linux Zeroconf LAN irregularities
I would like to at least understand, if not remedy,
an annoyance in establishing the connection between
my Mac and my Linux box. I have yet to find anything
constructive relative to the issue via the google
shuffle or manual pages. Any thoughts, experiences
and/or further troubleshooting steps would be
appreciated. Thank you.
PMac G5 running OS X Tiger (10.4.4)
Linux printer is shared with Mac via CUPS,
not classic AppleTalk.
P4 with Debian Etch (testing), kernel 2.6.12-1-686,
Gnome desktop and USB attached printer and scanner.
With netatalk 2.0.3-4 and task-howl (0.9.5-2), which
includes the howl mdnsresponder (0.9.5-2), installed.
Only the netatalk afpd and cnid_metad deamons are
hardwired ethernet with the Mac and Linux box connected
to a Belkin 4 port router
If I boot up both my Mac and Linux box:
Linux has autoipd, mDNSResponder and nifd daemons running.
Mac has mDNSResponder and netinfod daemons running (don't
know which others are pertinent to note).
If on my Mac in a Finder pane I click Network -> My Network
-> debian1 -> Connect then I get the message:
AFP connection status
Looking up "debian1.local.."
which times out with the message:
Connection failed - server may not exist blah blah
In can however, on my Mac in the Finder menu bar select
Go -> Connect to Server -> enter afp://192.168.2.48/
(my Linux box) -> enter user and password of shared
directory -> select share to mount; and I have my
connection. If I dismount the share though, within a
session, and try to connect again this method works and
the Finder pane method still does not.
Alternatively, on my Linux box I can run the cli
# /etc/init.d/mdnsresponder restart
Then back on my Mac the Finder pane method of establishing
a connection (that failed above) works as it should.
Further, I can dismount the share and reconnect with this
method any number of times in the same session, and even
reconnect with this method after rebooting only my Mac.
However, if I reboot my Linux box I'm back to Finder menu
bar or mdnsresponder restart reconnect choices.
What the above trials tell me is that if I restart
mdnsreaponder then everything is "peachy" until my Linux
box is rebooted. What they do not tell me is if there is
something flakey with mdnsresponder, my Linux installation,
an incompatibility with Tiger, or even some other
interference on either box.
"Life is judged with all the blindness of life itself."
-- George Santayana
(see Backup::Restore article
(see Artworks sampling