Mac OS X and Linux Zeroconf LAN irregularities

I posted the following to the Debian list for obvious reasons, but I'm also posting it here in the hope that someone might shed some light on my suspicions relative to the Mac log.

*********************************************************************
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,SOCKPACKET)


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-net work
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 (stop and start) 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

Following the thinking that the Linux startup scripts were firing in the wrong order I studied the update-rc.d man pages and THE Debian Policy Manual (selectively), but when I got to looking around in /etc/init.d and /etc/rc?.d I found scripts (and symlinks) for only the relevant daemons autoipd, mdnsresponder and netatalk (there are others of course). There was nothing specific for the automatic DHCP which I believe is relevant based on howl site comments noted above - I guess DHCP is buried somewhere in networking setup in /etc/rcS.d (boot time) and I don't want to hack the basic setup.

So, adjusting the thought train:

1) howl-tools as installed are being phased out in favor of Avahi and the package is no longer being maintained to my knowledge. Their list even ends abruptly in Aug. 2005.

2) There have been significant changes in Debian Etch and kernel 2.6.12-1-686 since this howl-tools package.

3) The system log line "autoipd uses obsolete (PF INET,SOCKPACKET)" is a clue that something ain't kosher 🙂

4) The (dated) comments on the howl site as noted.


My thinking is that automatic DHCP gets its act together then mdnsresponder uses DHCP to do its broadcasting thing. However, either in between or after, the seemingly antiquated autoipd screws up the works for mdnsresponder. My understanding is that autoipd is intended as a work around if DHCP setup fails, but I don't know if the work around is still relevant with Etch and kernel 2.6.12-1-686.

So this klutzy hacker's work around was to use my new found knowledge of sysV init and update-rc.d, and employ the cli
update-rc.d autoipd remove
so the daemon is never started.

My file sharing (via netatalk) connection now works at getty-up-go with the Finder pane approach also, which nullifies the annoyance I was investigating, and my print sharing (via CUPS) still works.

The autoipd code is still on the system and the init script is still there (renamed), so I can always reinstate the daemon startup if I find some adverse affect.

I should not have to exist in this in-between land for too many months. Someday soon Avahi will work its way down to testing without an onerous Sid dependency and create new issues for me to have to screw around with :-))

Lee C