You are not logged in.
Pages: 1
Topic closed
I have an Asus Eee 701SD netbook running Arch, and for some days now I've been trying to get Avahi (Zeroconf, Bonjour) working between the various devices on our home network.
For the most part, all is now well, but the one problem I've had all along: the Eee hasn't been able to "see" any of the Zeroconf services on the network. (It did manage to connect to our HP LaserJet 4100TN network printer, but I suspect the Eee found it by a means other than Zeroconf.) I tried everything I could find - appropriate holes in the firewall (ufw - yes), was avahi-daemon running (yes), etc. - but although everything checked out, the Eee couldn't find any Zeroconf services.
Yesterday evening, I went on a "hunch", and connected the Eee to Ethernet rather than the usual WiFi. Bingo - suddenly the Avahi service browser was showing the complete range of services on our LAN. I switched back to WiFi, and they disappeared again.
Frankly, I'm stumped - why would Avahi work over Ethernet, but not WiFi, when all the other Zeroconf/Bonjour-enabled machines on our LAN have no problems? I wondered if there was some kind of bug or issue with the wireless chipset driver (rt818x, I believe), which might stop Avahi sending or receiving data - perhaps something to do with multicast?
Many thanks for any ideas you can come up with - much appreciated :-)
Tim
--
Asus Eee 701SD (8Gb SSD) - Arch Linux
The continuing adventures: http://eee701planetoid.wordpress.com/
--
Offline
Is your wireless LAN in the same subnet as your wired LAN?
Offline
Is your wireless LAN in the same subnet as your wired LAN?
Yes - I was wondering whether our router might put wired and wireless networks on different subnets, but I checked that and they are both on the same one (255.255.255.0). Furthermore, I tried a Macbook (WiFi) and iMac (Ethernet) on the LAN, and they could see each other's Bonjour services, so I figured it couldn't be a subnet issue.
None of the other hosts on the LAN have the same problems with Zeroconf/Bonjour, and the Eee sees the services when on a wired connection, so by a process of elimination, that seems to leave the Eee's wireless as the "prime suspect". (The only other "lead" I had was that our router - a BT Home Hub 3 - apparently doesn't support multicasting, but I figured that if that was the source of the problem, then surely Zeroconf shouldn't work at all?)
Curiouser and curiouser...
--
Asus Eee 701SD (8Gb SSD) - Arch Linux
The continuing adventures: http://eee701planetoid.wordpress.com/
--
Offline
Having just written that...
Immediately afterwards, I Googled for "zeroconf bridge wired wireless" and found this page at superuser.com. In short, it looks as if quite a few routers (including the BT Home Hub 3) don't handle multicast properly, which means in practice that wired and wireless clients may not "see" each other via Zeroconf.
Hmm...
--
Asus Eee 701SD (8Gb SSD) - Arch Linux
The continuing adventures: http://eee701planetoid.wordpress.com/
--
Offline
Do you use NetworkManager? You could also take a look into /etc/avahi/avahi-daemon.conf there is a parameter "allow-interfaces" which might be helpful...
Offline
Is your wireless LAN in the same subnet as your wired LAN?
Yes - I was wondering whether our router might put wired and wireless networks on different subnets, but I checked that and they are both on the same one (255.255.255.0).
That's the subnet mask - the subnet would be something like 192.168.1.*.
Offline
Thanks for your replies :-)
Do you use NetworkManager? You could also take a look into /etc/avahi/avahi-daemon.conf there is a parameter "allow-interfaces" which might be helpful...
I use Wicd, as I try to avoid GNOME and KDE apps where I can (the Eee 701SD isn't exactly a high-spec machine...).
I'm looking at the Avahi config file - there is a parameter for "allow-interfaces", but it's commented out. Should I explicitly allow eth0 and wlan0 in this file, if I want Avahi to work on them both?
That's the subnet mask - the subnet would be something like 192.168.1.*.
If proof were needed that I'm operating on the edges of my networking knowledge here... The wired and wireless clients are all on the same subnet: 192.168.123.* (I know this range is an odd one; it's a holdover from the SMC Barricade router we used to use, and I've stayed with it for compatibility reasons, but could change to one of the "proper" local LAN IP address ranges if it is a problem.)
Hope this helps - thanks again!
--
Asus Eee 701SD (8Gb SSD) - Arch Linux
The continuing adventures: http://eee701planetoid.wordpress.com/
--
Offline
192.168.123.* is "proper", don't worry.
Whenever you have the time/interest, google 'RFC1918' for more details.
Offline
I had this problem too. My access point is an Amped AP20000G.
I have used Wireshark on both side of the AP to be sure that Avahi multicast traffic could go through the wifi access point.
What this has led me to discover or realize is that Wifi is less reliable than wired Ethernet. I just moved my laptop close to the wired desktop (where my AP is located as well) and Avahi started to work.
I have never realized it before but TCP works fine on weak Wifi signals because of the builtin retransmission mechanism but multicast which requires UDP depends on the application to detect packet drops and to implement retransmission policy.
So simple test: move your laptop close to the AP to see if it makes a difference. Check number of packet drops from ifconfig (or the newer equivalent) ouput.
Maybe there is a way in avahi-daemon.conf file to tweak retransmission params (# of attempts, interval).
Offline
Offline
Pages: 1
Topic closed