On Thu, 26 Jan 2006 13:04:38 -0500
Chinook <chinook.nr@tds.net> wrote:
> Chinook wrote:
> > 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.
> > ==============================================
> > Installation:
> >
> >
> > 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
> > being run.
> >
> >
> > hardwired ethernet with the Mac and Linux box connected
> > to a Belkin 4 port router
> > ==============================================
> > Trials:
> >
> >
> > 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.
Lee, I don't know a thing about mDNS* and other packages you mention, but my gut feeling on your above trial is that your startup scripts are simply in the wrong order. IOW, mDNSresponder relies on some other service in order to function properly, but that service comes up after mdsn* in the startup under a normal boot. By manually restarting it later you are making it work because whatever service was required is now up and running. So, as a temporary fix, while you try to find the real problem (could even be a bug in the install) you could change the startup script order using update-rc.d (man page will tell all, but watch out for the periods (.) in the command line.). Something like <making up numbers here>:
update-rc.d mdnsresponder start 85 2 3 4 5 . stop 85 1 6 .
look at what the defaults for mdnsresponder are before making adjustments.
A
> > ==============================================
> >
> > Lee C
> > "Life is judged with all the blindness of life itself."
> > -- George Santayana
> > (see Backup::Restore article
> > http://homepage.mac.com/lee_cullens/Bx3.html )
> > (see Artworks sampling
> > http://homepage.mac.com/lee_cullens/Artworks.pdf )
> >
> >
>
> The howl-tools portion of my zeroconf installation is being phased
> out in favor of the newer Avahi as I understand it. However, Avahi
> hasn't made its way down to testing yet so for the time being I'm
> trying to make do with howl-tools. The point in my mentioning
> this here is that much of the information I find is outdated.
>
>
> That said, the only thing I've found in the Linux bootup logs yet
> (using dmesg) that I recognize is the line
>
>
> autoipd uses obsolete (PF_INET,SOCK_PACKET)
>
>
> So, using autoipd as a starting point for further researching
> this issue I found the following
> (at http://www.porchdogsoft.com/products/howl/InstallUnix.html )
>
> ..........................
> Ideally, autoipd should run only in the event that the interface has not
> been statically configured and DHCP fails. Running autoipd this way
> requires modification to the standard distribution boot scripts for your
> OS. These modifications vary depending on your version of Linux or
> FreeBSD. On RedHat Linux, for example, the /sbin/ifup script may be
> modified to launch autoipd in the event that dhclient fails. On our
> systems, we added the following line to /sbin/ifup right after dhclient
> is launched so that autoipd runs whenever DHCP fails:
>
> elif [ -z "`pidof -x dhclient`" ] && [ -z "`pidof -x dhcpcd`" ] && [ -z
> "`pidof -x pump`" ] && [ -x /usr/local/bin/autopid ] &&
> /usr/local/bin/autoipd -i ${DEVICE}; then echo $"started autoip."
>
> Note that since this change causes "$NUMDEFROUTES" to become
> zero-length, the subsequent code in /sbin/ifup for fixing the duplicate
> routes generated by DHCP also gets modified in the howl version of ifup.
>
> You may need to modify your boot scripts differently depending on your
> platform. We have included the original ifup script for RedHat 9 along
> with our modified version (howl_ifup) as an example so that you may more
> easily identify how to modify the boot scripts for your platform.
> .............................
>
> A lot of Greek to me :-) but I did look in /etc/init.d and found
> the autoipd script which is the normal boilerplate (same as all
> the others with autoipd substituted for the daemon name).
>
> Even if I felt comfortable adding the above in the
> /etc/init.d/autoipd script, I have no idea whether it would be
> dealt with after dhclient.
>
> I also found in the Mac system log after a reboot:
> Jan 26 02:22:48 slpmacg5 mDNSResponder: Adding browse domain local.
> Jan 26 02:22:48 slpmacg5 configd[33]: executing
> /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/enable-network
> Jan 26 02:22:48 slpmacg5 configd[33]: posting notification
> com.apple.system.config.network_change
> Jan 26 02:22:48 slpmacg5 lookupd[80]: lookupd (version 369.2) starting -
> Thu Jan 26 02:22:48 2006
> Jan 26 02:22:49 slpmacg5 configd[33]: target=enable-network: disabled
> Jan 26 02:22:50 slpmacg5 configd[33]: AppleTalk startup complete
> Jan 26 02:23:59 slpmacg5 automount[148]: NSLXResolveDNS will try and
> resolve [debian1] of type [_afpovertcp._tcp.] in location [local.]\n
>
>
> so I'm thinking (dangerous at my age) that my Mac isn't "discovering"
> what it needs until I restart mdnsresponder on my Linux box????
>
>
> What I'm asking is whether anyone thinks this (autoipd) on Linux is a
> likely cause of my described connection annoyance?
>
>
> If so, is the referenced info applicable to Debian today and how
> would one go about applying it?
>
>
> Or alternately if so, might it make sense to just disable autoipd
> startup altogether and how would I best go about that - just something
> like update-rc.d autoipd remove????????
>
>
> Thank you,
> Lee C
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Attachment:
pgpkcoPTD1hgv.pgp
Description: PGP signature