Bug 632530

in chat with @libcanberra dev, looking at detail in attachment @: https://bugs.freedesktop.org/show_bug.cgi?id=29650#c5

27164 12:06:38.804645 connect(8, {sa_family=AF_INET6, sin6_port=htons(4713),
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28)
= -1 EINPROGRESS (Operation now in progress) <0.000021>
27164 12:06:38.804717 poll([{fd=6, events=POLLIN}, {fd=8, events=POLLOUT}], 2,
5000) = 0 (Timeout) <5.005109>
27164 12:06:43.809956 close(8)          = 0 <0.000039>

Those are the three interesting lines: we try to connect to localhost on port
4713, and that times out. Normally this should immediately return with an
ECONNREFUSED. There's some kind of fw running i'd guess that blocks IPv6 even
for local communication.

Try "iptables -L -v -n" to see if there is some kind of fw running, and fix
your fw.

so, checking (on this box, no firewall ...)

iptables -L -v -n
	Chain INPUT (policy ACCEPT 196 packets, 84005 bytes)
	 pkts bytes target     prot opt in     out     source               destination
	
	Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
	 pkts bytes target     prot opt in     out     source               destination
	
	Chain OUTPUT (policy ACCEPT 207 packets, 38542 bytes)
	 pkts bytes target     prot opt in     out     source               destination      

asking,

[12:45] <dev001> so, iiuc, if ipv6 is disabled on LAN-boxen, libcanberra will fail becuase it insists on ipv6 checks?
[12:45] <mezcalero> no
[12:45] <mezcalero> it will immediately fail and libpulse goes on
[12:46] <mezcalero> and tries the next possible server
[12:46] <mezcalero> most likely there won't be any
[12:46] <mezcalero> and hence it will tell libcanberra that the server couldn't be reached
[12:46] <mezcalero> and the lc will tell the app that the server couldn't be reached
[12:46] <mezcalero> and correctly written apps would completely ignore the lc error codes
[12:47] <mezcalero> because sound events are not really that important
[12:47] <mezcalero> the problem you have is simply that IPv6 is borked for you and something that should normally take zero time takes forever
[12:47] <mezcalero> which is connecting to localhost to see if there's a PA server running

and,

[12:50] <dev001> On opensuse 11.3, if firefox > 3.6.6 is installed, & libcanberra *is* installed, but pulseaudio is not, the "distro-installed ipv6 setup" is 'borked', causing menus in firefox to delay.
[12:50] <dev001> do i have that more or less right?
[12:55] <mezcalero> this has nothing to do with firefox
[12:55] <mezcalero> also, not really anything to do with libcanberra
[12:55] <mezcalero> and not even really too much with pa either
[12:56] <mezcalero> it's just that if you connect to localhost via ipv6 the connection times out instead of returning ECONNREFUSED

which leaves me wondering,

[12:56] <dev001> so the fact that it ONLY mainfests in firefox, when libcanberra & pulseaudio are directly & reproducibly involved, and NOwhere else, is a fluke?

this seems to be blamed, most recently, on "borked" ipv6.

so, let's try component=Network ...

per darix @ #opensuse-factory,

vi /boot/grub/menu.lst

    title openSUSE 11.3
     root (hd0,0)
--   kernel /vmlinuz ... ipv6.disable=1
++   kernel /vmlinuz ...
     initrd /initrd

rpm -e `rpm -e | grep -i pulseaudio`
reboot

launch Firefox (ver 3.6.8, libcanberra installed, NO pulseaudio)
** NO ** menu delay

fixes the problem/delay.

so that's a workaround.

what, if anything, needs to be _fixed_ ?

argh!  that should be:

--   kernel /vmlinuz ...
++   kernel /vmlinuz ... ipv6.disable=1

i.e, **ADD** the disable

although this is a workaround, disabling ipv6 really is not a viable , permanent option.

(how) will this be ultimately addressed?

bump

this is still an issue/problem ...

grasping at straws, atm, might this,

  IPv6 not enabled in Yast, yet dhclient spams logs with ipv6 failures
  https://bugzilla.novell.com/show_bug.cgi?id=616765

be at all related?

No, it isn't related.
Bug 616765 is about starting dhcpv6 client while disable_ipv6=1, that were not
taken into account. Without fix, the dhcpv6 is started when the interface is
configured with BOOTPROTO="dhcp" regardless of disable_ipv6.

As result, on systems with disable_ipv6, the interface start time is longer
(20 secs by default), because /etc/init.d/network (ifup) waits for the dhcpv6
client to get an ipv6 address and the dhcpv6 client can't get any and complains in the logs because IPv6 is disabled. That's all about. No relation to this bug.

default assignee's auto-set to:

  bnc-team-gnome@forge.provo.novell.com

@ https://bugzilla.novell.com/describecomponents.cgi?product=openSUSE%2011.3 says,

  bnc-team-screening@forge.provo.novell.com

changing ...

Changed the summary again. It makes more sense to describe the already analyzed situation than the effects that can be seen.

ok, call it what you will :-/

re: alreadly analyzed?  by whom?  and to what end?

 @ https://bugs.freedesktop.org/show_bug.cgi?id=29650

comment -> "this is not really a problem of libcanberra, nor of PA, and I am pretty sure it's just misconfiguration of opensuse."

and

 @ https://bugzilla.mozilla.org/show_bug.cgi?id=567746

commnet -> "we have discovered it is not a Firefox bug"

so, i.e.,

 !libcanberra
 !pulseaudio
 !firefox

which suggests that

  "libcanberra.so might fail to connect to pulseaudio if IPv6 is enabled (causes menu hangs in Firefox)"

is hardly accurate -- or anything more than coincidence.

and,

  "pulldowns delay/hang in Firefox; OK if IPv6 DISable"

does a better job of simply describing the ACTUAL symptom.

but, i defer -- I'd just like to get some actual eyes on this.

Created attachment 400929 [details]
strace of Firefox in case of reported menu delay

three test cases provided:

 case 1: IPv6 disabled, no IPv6 opt in grub            --> Firefox menu delays
         STRACE ATTACHED (firefox.strace.CASE1.txt.bz2)
 case 2: IPv6 disabled, with 'ipv6.disable=1' in grub  --> no delays
 case 3: IPv6 enabled,  no IPv6 opt in grub            --> no delays


uname -a
	Linux dev001 2.6.34.7-0.5-desktop #1 SMP PREEMPT 2010-10-25 08:40:12 +0200 x86_64 x86_64 x86_64 GNU/Linux

chkconfig --list | grep -i firewall
	SuSEfirewall2_init        0:off  1:off  2:off  3:off  4:off  5:off  6:off
	SuSEfirewall2_setup       0:off  1:off  2:off  3:off  4:off  5:off  6:off

iptables -L
	Chain INPUT (policy ACCEPT)
	target     prot opt source               destination

	Chain FORWARD (policy ACCEPT)
	target     prot opt source               destination

	Chain OUTPUT (policy ACCEPT)
	target     prot opt source               destination

ip6tables -L
	Chain INPUT (policy ACCEPT)
	target     prot opt source               destination

	Chain FORWARD (policy ACCEPT)
	target     prot opt source               destination

	Chain OUTPUT (policy ACCEPT)
	target     prot opt source               destination

rpm -qa | egrep -i "canberra|pulse|MozillaFirefox-3"
	libcanberra-devel-0.24-1.8.x86_64
	libcanberra0-0.24-1.8.x86_64
	libpulse0-32bit-0.9.21-10.1.1.x86_64
	libpulse0-0.9.21-10.1.1.x86_64
	libcanberra-gtk0-32bit-0.24-1.8.x86_64
	libpulse-mainloop-glib0-0.9.21-10.1.1.x86_64
	libcanberra-gtk-0.24-1.8.x86_64
	libcanberra-gtk0-0.24-1.8.x86_64
	libcanberra0-32bit-0.24-1.8.x86_64
	libcanberra-gtk-32bit-0.24-1.8.x86_64
	MozillaFirefox-3.6.12-1.2.x86_64

cat /etc/zypp/locks
	...
	type: package
	match_type: glob
	solvable_name: pulseaudio
	...

###########################################
CASE 1) IPv6 disabled, no settings in GRUB

grep -i ipv6 /etc/sysctl.conf
	net.ipv6.conf.all.disable_ipv6 = 1
grep -i ipv6 /etc/modprobe.d/50-ipv6.conf
	#  net.ipv6.conf.all.disable_ipv6 = 1
	# Comment out to disable IPv6:
	# install ipv6 /bin/true
grep -i ipv6 /boot/grub/menu.lst
	(empty)

ifconfig eth0 | grep inet6
	(empty)
ls -ald /proc/sys/net/ipv*
	dr-xr-xr-x 0 root root 0 2010-11-17 12:11 /proc/sys/net/ipv4/
	dr-xr-xr-x 0 root root 0 2010-11-17 12:11 /proc/sys/net/ipv6/

!! note, /proc/sys/net/ipv6 exists ...

cd /proc/sys/net/ipv6/conf
find . | grep -i ipv6 | grep -i able
	./all/disable_ipv6
	./default/disable_ipv6
	./lo/disable_ipv6
	./eth0/disable_ipv6
cat `find . | grep -i ipv6 | grep -i able`
	1
	1
	1
	1


cd /usr/local/TEMP
strace -s 1024 -Ff -tt -o firefox.strace.CASE1.txt firefox -safe-mode -private -P VANILLA

in Firefox
	select "File" menu
	(~ 5 second delay before dropdown)
	select "File -> Quit"
	(~ 5 second delay before quit)

attach -> firefox.strace.CASE1.txt.bz2


###########################################
CASE 2) IPv6 disabled, and ALSO in GRUB

same as CASE 1, plus

vi /boot/grub/menu.lst
---	kernel /vmlinuz ...
+++	kernel /vmlinuz ... ipv6.disable=1
grep -i ipv6 /boot/grub/menu.lst
	kernel /vmlinuz ... ipv6.disable=1

reboot

ifconfig eth0 | grep inet6
	(empty)
ls -ald /proc/sys/net/ipv*
	dr-xr-xr-x 0 root root 0 2010-11-17 13:09 /proc/sys/net/ipv4/

!! note, NO /proc/sys/net/ipv6 ...

in Firefox, *NO* menu hangs/delays of any kind.


###########################################
CASE 3) IPv6 ENabled, no IPv6 settings in GRUB

grep -i ipv6 /etc/sysctl.conf
	#net.ipv6.conf.all.disable_ipv6 = 1
grep -i ipv6 /etc/modprobe.d/50-ipv6.conf
	#  net.ipv6.conf.all.disable_ipv6 = 1
	# Comment out to disable IPv6:
	install ipv6 /bin/true
grep -i ipv6 /boot/grub/menu.lst
	(empty)

reboot

ifconfig eth0 | grep inet6
          inet6 addr: fe80::226:f2ff:feac:bfc2/64 Scope:Link
ls -ald /proc/sys/net/ipv*
	dr-xr-xr-x 0 root root 0 2010-11-17 13:18 /proc/sys/net/ipv4/
	dr-xr-xr-x 0 root root 0 2010-11-17 13:18 /proc/sys/net/ipv6/

cd /proc/sys/net/ipv6/conf
find . | grep -i ipv6 | grep -i able
	./all/disable_ipv6
	./default/disable_ipv6
	./lo/disable_ipv6
	./eth0/disable_ipv6
cat `find . | grep -i ipv6 | grep -i able`
	0
	0
	0
	0

in Firefox, *NO* menu hangs/delays of any kind.

per chat with darix,

for CASE 1), above, also,

	vi /etc/pulse/client.conf
		...
	---	; default-server =
	+++	default-server = /dev/null
		...
	---	; autospawn = yes
	+++	autospawn = no
		...

then,

	reboot

and, verifying,

	grep -i ipv6 /etc/sysctl.conf
		net.ipv6.conf.all.disable_ipv6 = 1
	grep -i ipv6 /etc/modprobe.d/50-ipv6.conf
		#  net.ipv6.conf.all.disable_ipv6 = 1
		# Comment out to disable IPv6:
		# install ipv6 /bin/true
	grep -i ipv6 /boot/grub/menu.lst
		(empty)
	ifconfig eth0 | grep inet6
		(empty)
	cd /proc/sys/net/ipv6/conf
	find . | grep -i ipv6 | grep -i able
		./all/disable_ipv6
		./default/disable_ipv6
		./lo/disable_ipv6
		./eth0/disable_ipv6
	cat `find . | grep -i ipv6 | grep -i able`
		1
		1
		1
		1

now, @ Firefox, prior menu-pulldown delay's GONE -- operates normally.

so, in the IPv6-disabled case, to NOT suffer Firefox-menu-dropdown-delays, in addition to,

	grep -i ipv6 /etc/sysctl.conf
		net.ipv6.conf.all.disable_ipv6 = 1


apparently, EITHER (or BOTH) of the following need to be true,

(i)
	grep -i ipv6 /boot/grub/menu.lst
		kernel /vmlinuz ... ipv6.disable=1

(ii)
	cat /etc/pulse/client.conf
		...
		default-server = /dev/null
		autospawn = no
		...

i.e., the instructions for disabling IPv6 provided in,

	/etc/modprobe.d/50-ipv6.conf
		#
		# Using this file does not work when the module is compiled
		# into the kernel (11.2 and above). Instead, please use the
		#  net.ipv6.conf.all.disable_ipv6 = 1
		# global sysctl setting in /etc/sysctl.conf or also a per
		# interface settings in ifsysctl(5) files.
		#
		
		# Comment out to disable IPv6:
		# install ipv6 /bin/true

are not sufficient ...

I'm dropping the obsolete /etc/modprobe.d/50-ipv6.conf in factory now.

Karl,
this is something for documentation / release notes, isn't it?

dev001x,
you weren't sooo wrong in your conclusion in comment 7. ifup-dhcp run
into a similar detection problem...

When only "net.ipv6.conf.all.disable_ipv6 = 1" is set, the kernel still
allows to create to a IPv6 socket. It does not behave as in the boot
parameter or moduled-disabled cases, so the old checks that software
were using do not work any more.

reading your comments, i'm not clear what the final *right* method for disabling/enabling IPv6 is (will be?).

question -- does it not make sense, given *SUSE's already current use of /etc/sysconfig/* configs, and the fact that IPv6-related 6-to-4 tunnels are already referenced in, e.g,

 /etc/sysconfig/network.ifcfg.template

to consolidate IPv4 and Ipv6 enable/disable -- both globally and/or per-interface -- 'all in one-place' somewhere in /etc/sysconfig/*?

(In reply to comment #21)
> reading your comments, i'm not clear what the final *right* method for
> disabling/enabling IPv6 is (will be?).

Beside the fact, that disabling of IPv6 introduces more problems than it
solves, there are basically two ways in the _kernel_:

 - via ipv6.disable=1 kernel parameter (global)
 - via sysctl / disable_ipv6 (for all or specific interface)

I think, this will not change so fast in the next feature. It is also
very difficult to get patches accepted upstream. See e.g. bug 559170.

As you noticed, the second method has side effects, because it is not
trivial to detect whether a ipv6 connect will work. When some app wants
to connect for example http://ipv6.google.com/, it does not know and it
usually does not need to know, which interface will be used, so it can't
and shouldn't check the ...all.disable_ipv6 and $ifname.disable_ipv6 flags.

> question -- does it not make sense, given *SUSE's already current use of
> /etc/sysconfig/* configs, and the fact that IPv6-related 6-to-4 tunnels
> are already referenced in, e.g,
> 
>  /etc/sysconfig/network.ifcfg.template
> 
> to consolidate IPv4 and Ipv6 enable/disable -- both globally and/or
> per-interface -- 'all in one-place' somewhere in /etc/sysconfig/*?

Most of the variables are there: e.g. IPV6_DISABLE, IPV6_PRIVACY in the
/etc/sysconfig/sysctl file. IMO a better place for _global_ settings is
the /etc/sysctl.conf file.

Of course it would make sense to consolidate them all and have one place
where you just need to set them. The problem is, applying the sysconfig
variables *often* does not work correctly.
You can not apply any variables to modules that are not yet loaded.

So in case of IPv6, it works only for .all.* and .default.* variables,
but not for interface specific settings. Just think of the case, that
the device (e.g. USB network card) is not yet plugged in.

For example, IPV6_PRIVACY has to be applied as soon as an interface starts
to be visible to the system, but _before_ the link goes up.

So the only way to apply the interface specific settings is to apply
them via udev rules (on network add event). This is the reason, why
I've added one more place: see "man 5 ifsysctl".

removed obsolete 50-ipv6.conf done in yast2-network-2.20.6

(In reply to comment #22)
> ... there are basically two ways in the _kernel_: ...
thanks for the clear explanation!

*** Bug 656916 has been marked as a duplicate of this bug. ***

Created attachment 403328 [details]
Simple test program resolving hostname / port and connecting addresses

Created attachment 403332 [details]
Tests results using the test tool

Michal noticed in 656916#c2, that while his test there were a ::1 set on
the loopback interface.

I've made several tests on two hosts using the simple test tool I wrote.

One finding was interesting: there were also a (tentative) address after
a manual "sysctl -w net.ipv6.conf.all.disable_ipv6=1", that was still set
on the eth0 interface that has had the default route before:

        # ip a s | grep inet6
            inet6 ::1/128 scope host 
            inet6 2001:zzz:zzzz:zzzz::xxx/64 scope global tentative 

I've executed sysctl -w short after the machine booted up...

But I was unable to find any problem [even the tentative addresses were
still set]. I've always got a "Network is unreachable", never a timeout.

     0.000165 connect(3, {sa_family=AF_INET6, sin6_port=htons(25), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable) <0.000072>
     0.000397 write(2, "\tcan not connect to ipv6<[::1]:2"..., 59       can not connect to ipv6<[::1]:25>: Network is unreachable
) = 59 <0.000105>

Kernel Maintainers,

could you take a look at the address cleanup done by sysctl/disable_ipv6
please? Do you have an idea why the connect timeout (see attached straces)
instead of ENETUNREACH occurs?


dev001x,
could you try to reproduce the connect timeout using the attached tool,
so we have something smaller and see if this happens with the tool as
well or the libs are doing something special.

Ian,
could you provide a strace of your problem (Bug 656916) please?

CCing sound guys (as it moved away from the component). We have regularly users suffering from this issue and we should find a way to solve the symptoms somehow at least.

how is this a kernel issue?

Totally confused...

Because the bug is an inconsistent ipv6 disablement in kernel that confuses apps?  Judging from the comments, this doesn't look like a PA-specific issue.

Jiri, any clue about comment 28?

(In reply to comment #31)

Exactly.

The main problem is, that apps (libpulse here) run into timeouts. See also
comment 15..18.

There are many checks for IPv6 availability in several apps, that basically
do not work in disable_ipv6 case -> the checks have to be improved / fixed
in the apps.
A simple "test -d /proc/sys/net/ipv6" is not sufficient and less useful for
normal apps.
A check for socket creation failure is not sufficient too (can be used to
bail our earlier) as it does not work in all.disable_ipv6=1 case and this
runtime setting may change anyway.

But a try to create socket + connect should IMO fail an not cause timeouts
as it seems to happen here.

openSUSE 11.3 is no longer supported; please re-open if this happens in 12.3 or newer.

This is an autogenerated message for OBS integration:
This bug (632530) was mentioned in
https://build.opensuse.org/request/show/57033 Factory / yast2-network
https://build.opensuse.org/request/show/57244 Factory / sysconfig