Description of problem: avahi-publish-service not working on ia64. avahi-browse able to see services published from other machines but not ones from the ia64. This bug prevents the systemtap compile server from working on ia64. Version-Release number of selected component (if applicable): avahi-0.6.16-1.el5_2.1 How reproducible: Always Steps to Reproduce: 1. install avahi on machine 2. in one terminal window publish a service on ia64 machine: avahi-publish-service "Systemtap Compile Server on crud.devel.redhat.com" _stap._tcp 65099 sysinfo="2.6.18-159.el5 #1 SMP Mon Jul 20 18:13:45 EDT 2009 x86_64" 3. in another terminal window look for service on ia64 with: avahi-browse _stap._tcp --terminate -r Actual results: No services reported local to the ia64 machine Expected results: avahi-browse would report the advertised service. This works on i386 and x86_64 machines. Additional info: The ia64 machine is able to see avahi services advertised by other machines in the local network (i386 and x86_64 rhel 5.4 machines)
Hmm, are you sure the cause is ia64 here? Maybe there's a firewall set up on that machine and not on the x86? Please provide the output of "ip addr" and "iptables -L -v -n" here, for both the machine where things work and the machine where it doesn't.
The ia64 is seeing avahi published services from the other machines but not the locally published avahi event. Doesn't the firewall only affect non-local network traffic? Earlier I tried turning off the firewall on the ia64 machine and got the same results. From the working x86_64 machine: [root@calfee ~]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:12:3f:44:40:93 brd ff:ff:ff:ff:ff:ff inet 10.11.228.29/22 brd 10.11.231.255 scope global eth0 inet6 fe80::212:3fff:fe44:4093/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 inet6 fe80::200:ff:fe00:0/64 scope link valid_lft forever preferred_lft forever [root@calfee ~]# iptables -L -v -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 1930K 923M RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 1714K packets, 500M bytes) pkts bytes target prot opt in out source destination Chain RH-Firewall-1-INPUT (2 references) pkts bytes target prot opt in out source destination 1281K 435M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 465 143K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 255 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 12693 2373K ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353 5789 1233K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:631 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:631 608K 480M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 8 480 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:5900 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:5900 21414 3369K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited From the non-working ia64 machine [root@squidward ~]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:6e:38:2a:b7 brd ff:ff:ff:ff:ff:ff inet 10.11.228.32/22 brd 10.11.231.255 scope global eth0 inet6 fe80::230:6eff:fe38:2ab7/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 [root@squidward ~]# iptables -L -v -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 4589 5167K RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 2543 packets, 154K bytes) pkts bytes target prot opt in out source destination Chain RH-Firewall-1-INPUT (2 references) pkts bytes target prot opt in out source destination 407 27203 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 255 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 19 2355 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:631 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:631 4142 5134K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 20 3743 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Hmm, so there is a firewall set. COuld check if disabling the firewall fixes things?
Having the firewall OFF for ia64 machine when booting the machine (and starting the avahi-daemon) allow seeing see the published service: [wcohen@squidward systemtap]$ avahi-publish-service "Systemtap Compile Server on crud.devel.redhat.com" _stap._tcp 65099 sysinfo="2.6.18-159.el5 #1 SMP Mon Jul 20 18:13:45 EDT 2009 x86_64" & [1] 3500 [wcohen@squidward systemtap]$ Established under name 'Systemtap Compile Server on crud.devel.redhat.com' [wcohen@squidward systemtap]$ avahi-browse _stap._tcp --terminate -r+ eth0 IPv6 Systemtap Compile Server on crud.devel.redhat.com _stap._tcp local + eth0 IPv4 Systemtap Compile Server on crud.devel.redhat.com _stap._tcp local = eth0 IPv6 Systemtap Compile Server on crud.devel.redhat.com _stap._tcp local hostname = [squidward.local] address = [fe80::230:6eff:fe38:2ab7] port = [65099] txt = ["org.freedesktop.Avahi.cookie=2769231026" "sysinfo=2.6.18-159.el5 #1 SMP Mon Jul 20 18:13:45 EDT 2009 x86_64"] = eth0 IPv4 Systemtap Compile Server on crud.devel.redhat.com _stap._tcp local hostname = [squidward.local] address = [10.11.228.32] port = [65099] txt = ["org.freedesktop.Avahi.cookie=2769231026" "sysinfo=2.6.18-159.el5 #1 SMP Mon Jul 20 18:13:45 EDT 2009 x86_64"] I noticed a difference between the firewall setting of the x86_64 and ia64 machine, the working x86_64 allow tcp and udp ports 5000-5999, a working i686 machine allow tcp ports 5000-5999. According to the following bug it looks like the ia64 might be having that particular port blocked: https://bugzilla.redhat.com/show_bug.cgi?id=444427 Should there be an explicit entry in the firewall for avahi or does avahi-daemon startup modify the firewall? It seems that restarting the avahi-daemon with the firewall running as is allows things to work. Looking through the /var/log/messages file see that the firewall is starting around the same time as avahi-daemon: Aug 28 14:37:01 squidward avahi-daemon[2613]: Found user 'avahi' (UID 70) and group 'avahi' (GID 70). Aug 28 14:37:01 squidward avahi-daemon[2613]: Successfully dropped root privileges. Aug 28 14:37:01 squidward avahi-daemon[2613]: avahi-daemon 0.6.16 starting up. Aug 28 14:37:01 squidward avahi-daemon[2613]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Aug 28 14:37:01 squidward avahi-daemon[2613]: Successfully called chroot(). Aug 28 14:37:01 squidward avahi-daemon[2613]: Successfully dropped remaining capabilities. Aug 28 14:37:01 squidward avahi-daemon[2613]: Loading service file /services/sftp-ssh.service. Aug 28 14:37:01 squidward kernel: Bridge firewalling registered Aug 28 14:37:02 squidward avahi-daemon[2613]: New relevant interface eth0.IPv6 for mDNS. Aug 28 14:37:02 squidward avahi-daemon[2613]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::230:6eff:fe38:2ab7. Aug 28 14:37:02 squidward avahi-daemon[2613]: New relevant interface eth0.IPv4 for mDNS. Aug 28 14:37:02 squidward avahi-daemon[2613]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.11.228.32. Aug 28 14:37:02 squidward avahi-daemon[2613]: Network interface enumeration completed. Aug 28 14:37:02 squidward avahi-daemon[2613]: Registering new address record for fe80::230:6eff:fe38:2ab7 on eth0. Aug 28 14:37:02 squidward avahi-daemon[2613]: Registering new address record for 10.11.228.32 on eth0. Aug 28 14:37:02 squidward avahi-daemon[2613]: Registering HINFO record with values 'IA64'/'LINUX'. Aug 28 14:37:02 squidward avahi-daemon[2613]: New relevant interface virbr0.IPv4 for mDNS. Aug 28 14:37:02 squidward avahi-daemon[2613]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Aug 28 14:37:02 squidward avahi-daemon[2613]: Registering new address record for 192.168.122.1 on virbr0. Aug 28 14:37:02 squidward dnsmasq[2676]: failed to open pidfile /var/run/libvirt/network/default.pid: Permission denied Aug 28 14:37:02 squidward dnsmasq[2676]: FAILED to start up Aug 28 14:37:02 squidward avahi-daemon[2613]: Interface virbr0.IPv4 no longer relevant for mDNS. Aug 28 14:37:02 squidward avahi-daemon[2613]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Aug 28 14:37:02 squidward avahi-daemon[2613]: Withdrawing address record for 192.168.122.1 on virbr0. Aug 28 14:37:03 squidward setroubleshoot: SELinux is preventing dnsmasq (dnsmasq_t) "search" to ./libvirt (virt_var_run_t). For complete SELinux messages. run sealert -l dac1b6ca-440e-4bf9-a1f9-0ac760586b98
Since this seems to be a firewall issue reassigning to system-config-firewall.
Firewall configuration during installation is actually done by anaconda, so reassigning it to anaconda. Thanks & regards, Phil
If you did a kickstart install, add the relevant ports to the firewall line with the --ports= option. If you're doing an interactive install, you're kind of out of luck from the anaconda perspective. We don't have any mechanism that I'm aware of to have packages communicate that they need holes made in the firewall, and keeping a list of "if X is installed, then open port 4747" in anaconda is just unmaintainable.
The problem seems to be more related to the firewall or avahi. Even when the proper port is open in the fire wall (udp/5353) avahi-daemon needs to be restarted after the machine is up to see the advertised service on the local machine. Should avahi need to have udp/5353 open in the firewall to even see services on the local machine advertised?
(In reply to comment #8) > The problem seems to be more related to the firewall or avahi. Even when the > proper port is open in the fire wall (udp/5353) avahi-daemon needs to be > restarted after the machine is up to see the advertised service on the local > machine. Come again? > Should avahi need to have udp/5353 open in the firewall to even see services on > the local machine advertised? Avahi needs that port open. Port 5353/udp from everwhere to everyhwere. Also see: http://avahi.org/wiki/Avah4users#FAQ The firewall situation is simply broken on RHEL, so I am reassigning this to s-cfw so that the firewall situation gets fixed. This is not a bug I can fix in Avahi.
this is component s-c-network not s-c-fw
Clarification for comments #8 and #9. avahi-daemon service is set to start when the machine boots up. boot up machine. However, that initial avahi-daemon does not work correctly. The version of systemtap rpms installed: systemtap-sdt-devel-0.9.7-5.el5 systemtap-0.9.7-5.el5 systemtap-runtime-0.9.7-5.el5 systemtap-initscript-0.9.7-5.el5 systemtap-testsuite-0.9.7-5.el5 systemtap-client-0.9.7-5.el5 systemtap-server-0.9.7-5.el5 With systemtap setup on the machine and initial avahi-daemon (stap-find-server should have printed out the server running): [wcohen@squidward Desktop]$ SERVER=`stap-find-or-start-server` [wcohen@squidward Desktop]$ echo $SERVER 3467 [wcohen@squidward Desktop]$ stap-find-servers [wcohen@squidward Desktop]$ stap-stop-server $SERVER Now restart the avahi-daemon: [root@squidward ~]# service avahi-daemon restart Shutting down Avahi daemon: [ OK ] Starting Avahi daemon... [ OK ] Rerun previous steps (note that stap-find-servers finds the server on the restarted avahi-daemon): [wcohen@squidward Desktop]$ SERVER=`stap-find-or-start-server` [wcohen@squidward Desktop]$ echo $SERVER 3583 [wcohen@squidward Desktop]$ stap-find-servers squidward.local 10.11.228.32 65000 'sysinfo=2.6.18-159.el5 #1 SMP Mon Jul 20 18:15:42 EDT 2009 ia64' [wcohen@squidward Desktop]$ stap-stop-server $SERVER
Harald, there i sno component s-c-fw. Which package should I assign this to, if it's not s-c-network?
iptables is as close as I can guess ;-) But it should be Thomas...
William, on squidward there is no firewall configuration for virbr0, but on calfee is. Is virbr0 used for avahi-publish-service? If virbr0 is not used: Can you please try to disable the firewall on squidward with "lokkit --disabled" and reboot? Is it working then? Reassigned to system-config-securitylevel.
I updated the machine to RHEL 5.4 this pass week and avahi appears to be working with the firewall on when the machine first starts up. The /var/log/messages output is a bit different than before. It appears to be starting dnsmasq successfully. Output of the log file related to avahi startup: Sep 10 10:11:25 squidward kernel: Bridge firewalling registered Sep 10 10:11:25 squidward avahi-daemon[2517]: Found user 'avahi' (UID 70) and group 'avahi' (GID 70). Sep 10 10:11:25 squidward avahi-daemon[2517]: Successfully dropped root privileges. Sep 10 10:11:25 squidward avahi-daemon[2517]: avahi-daemon 0.6.16 starting up. Sep 10 10:11:25 squidward avahi-daemon[2517]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Sep 10 10:11:25 squidward avahi-daemon[2517]: Successfully called chroot(). Sep 10 10:11:25 squidward avahi-daemon[2517]: Successfully dropped remaining capabilities. Sep 10 10:11:25 squidward avahi-daemon[2517]: Loading service file /services/sftp-ssh.service. Sep 10 10:11:25 squidward avahi-daemon[2517]: New relevant interface eth0.IPv6 for mDNS. Sep 10 10:11:25 squidward avahi-daemon[2517]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::230:6eff:fe38:2ab7. Sep 10 10:11:25 squidward avahi-daemon[2517]: New relevant interface eth0.IPv4 for mDNS. Sep 10 10:11:25 squidward avahi-daemon[2517]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.11.228.32. Sep 10 10:11:25 squidward avahi-daemon[2517]: Network interface enumeration completed. Sep 10 10:11:25 squidward avahi-daemon[2517]: Registering new address record for fe80::230:6eff:fe38:2ab7 on eth0. Sep 10 10:11:25 squidward avahi-daemon[2517]: Registering new address record for 10.11.228.32 on eth0. Sep 10 10:11:26 squidward avahi-daemon[2517]: Registering HINFO record with values 'IA64'/'LINUX'. Sep 10 10:11:26 squidward avahi-daemon[2517]: New relevant interface virbr0.IPv4 for mDNS. Sep 10 10:11:26 squidward avahi-daemon[2517]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Sep 10 10:11:26 squidward avahi-daemon[2517]: Registering new address record for 192.168.122.1 on virbr0. Sep 10 10:11:26 squidward dnsmasq[2574]: started, version 2.45 cachesize 150 Sep 10 10:11:26 squidward dnsmasq[2574]: compile time options: IPv6 GNU-getopt no-ISC-leasefile no-DBus no-I18N TFTP Sep 10 10:11:26 squidward dnsmasq[2574]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Sep 10 10:11:26 squidward dnsmasq[2574]: reading /etc/resolv.conf Sep 10 10:11:26 squidward dnsmasq[2574]: using nameserver 10.11.255.27#53 Sep 10 10:11:26 squidward dnsmasq[2574]: using nameserver 172.16.52.28#53 Sep 10 10:11:26 squidward dnsmasq[2574]: read /etc/hosts - 2 addresses Sep 10 10:11:27 squidward avahi-daemon[2517]: Server startup complete. Host name is squidward.local. Local service cookie is 3913108080. Sep 10 10:11:27 squidward avahi-daemon[2517]: New relevant interface virbr0.IPv6 for mDNS. Sep 10 10:11:27 squidward avahi-daemon[2517]: Joining mDNS multicast group on interface virbr0.IPv6 with address fe80::200:ff:fe00:0. Sep 10 10:11:27 squidward avahi-daemon[2517]: Registering new address record for fe80::200:ff:fe00:0 on virbr0. Sep 10 10:11:28 squidward avahi-daemon[2517]: Service "SFTP File Transfer on squidward" (/services/sftp-ssh.service) successfully established. Sep 10 10:11:31 squidward smartd[2631]: smartd version 5.38 [ia64-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Given that I can no longer replicate this on RHEL5.4 on my machine I am going to close out this bugzilla. It looks like one of the RHEL5.4 errata eliminated the problem.