Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back > Forums > Linux Forums > Linux - Networking
User Name
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.


  Search this Thread
Old 01-26-2006, 01:04 AM   #1
LQ Newbie
Registered: Jan 2006
Posts: 16

Rep: Reputation: 0
Mac OS X and Linux Zeroconf LAN irregularities

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
being run.

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://
(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 C
"Life is judged with all the blindness of life itself."
-- George Santayana
(see Backup::Restore article )
(see Artworks sampling )
Old 01-26-2006, 12:22 PM   #2
LQ Newbie
Registered: Jan 2006
Posts: 16

Original Poster
Rep: Reputation: 0
RE: Mac OS X and Linux Zeroconf LAN irregularities

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 )

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
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
Old 01-28-2006, 02:36 AM   #3
LQ Newbie
Registered: Jan 2006
Posts: 16

Original Poster
Rep: Reputation: 0

This issue was solved.

see my newer "write-up" post.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Mac, Linux and Win File Shares over LAN Strixy Linux - Networking 4 04-26-2004 10:11 PM
anyone know of some Mac + Linux games (LAN play) edman007 Linux - Games 7 01-31-2004 09:30 PM
stubborn zeroconf BasK Mandriva 14 01-14-2004 04:26 PM
Dialling irregularities with SmartLink geznotts Linux - Hardware 1 08-08-2003 05:06 PM
Zeroconf?? need help pleaaase! thandorias Linux - Networking 3 06-13-2003 11:07 AM > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 03:19 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration