Bug 519989 - avahi-publish-service does not work on ia64
Summary: avahi-publish-service does not work on ia64
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: system-config-securitylevel
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Thomas Woerner
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-27 21:25 UTC by William Cohen
Modified: 2009-09-11 19:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-11 19:47:19 UTC


Attachments (Terms of Use)

Description William Cohen 2009-08-27 21:25:28 UTC
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)

Comment 1 Lennart Poettering 2009-08-27 22:01:13 UTC
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.

Comment 2 William Cohen 2009-08-28 13:23:14 UTC
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

Comment 3 Lennart Poettering 2009-08-28 16:31:23 UTC
Hmm, so there is a firewall set. COuld check if disabling the firewall fixes things?

Comment 4 William Cohen 2009-08-28 19:09:30 UTC
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

Comment 5 Lennart Poettering 2009-08-29 00:41:35 UTC
Since this seems to be a firewall issue reassigning to system-config-firewall.

Comment 6 Phil Knirsch 2009-09-01 12:22:40 UTC
Firewall configuration during installation is actually done by anaconda, so reassigning it to anaconda.

Thanks & regards, Phil

Comment 7 Chris Lumens 2009-09-01 13:54:15 UTC
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.

Comment 8 William Cohen 2009-09-01 14:20:36 UTC
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?

Comment 9 Lennart Poettering 2009-09-01 15:34:28 UTC
(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.

Comment 10 Harald Hoyer 2009-09-01 16:11:18 UTC
this is component s-c-network not s-c-fw

Comment 11 William Cohen 2009-09-01 17:45:40 UTC
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

Comment 12 Lennart Poettering 2009-09-01 20:56:45 UTC
Harald, there i sno component s-c-fw. Which package should I assign this to, if it's not s-c-network?

Comment 13 Denise Dumas 2009-09-09 19:36:03 UTC
iptables is as close as I can guess ;-) But it should be Thomas...

Comment 14 Thomas Woerner 2009-09-10 07:39:28 UTC
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.

Comment 15 William Cohen 2009-09-10 14:24:38 UTC
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

Comment 16 William Cohen 2009-09-11 19:47:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.