https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c dev001x _ changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.mozilla.or | |g/show_bug.cgi?id=567746 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c1 --- Comment #1 from dev001x _ 2010-08-18 20:04:05 UTC --- 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? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c3 --- Comment #3 from dev001x _ 2010-08-18 21:42:44 UTC --- 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_ ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c yang xiaoyu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xyyang@novell.com AssignedTo|bnc-team-screening@forge.pr |bnc-team-gnome@forge.provo. |ovo.novell.com |novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c6 dev001x _ changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Major --- Comment #6 from dev001x _ 2010-11-17 03:04:14 UTC --- bump this is still an issue/problem ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c8 --- Comment #8 from Marius Tomaschewski 2010-11-17 07:50:12 UTC --- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c dev001x _ changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|libcanberra.so failing to |if IPv6 enabled, menu |connect to pulseaudio |pulldowns delay/hang in |results in menu hangs in |Firefox; OK if IPv6 |Firefox |DISabled -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c11 --- Comment #11 from dev001x _ 2010-11-17 18:16:13 UTC --- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c13 --- Comment #13 from dev001x _ 2010-11-18 02:57:21 UTC --- 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 ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c20 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |jbohac@novell.com InfoProvider| |ke@novell.com --- Comment #20 from Marius Tomaschewski 2010-12-01 15:29:25 UTC --- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c22 --- Comment #22 from Marius Tomaschewski 2010-12-02 08:43:45 UTC --- (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". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

... there are basically two ways in the _kernel_: ...

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c24 --- Comment #24 from dev001x _ 2010-12-02 14:10:10 UTC --- (In reply to comment #22) thanks for the clear explanation! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c26 --- Comment #26 from Marius Tomaschewski 2010-12-03 12:23:12 UTC --- Created an attachment (id=403328) --> (http://bugzilla.novell.com/attachment.cgi?id=403328) Simple test program resolving hostname / port and connecting addresses -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c28 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|ke@novell.com |kernel-maintainers@forge.pr | |ovo.novell.com --- Comment #28 from Marius Tomaschewski 2010-12-03 13:13:12 UTC --- 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? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c30 Greg Kroah-Hartman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|kernel-maintainers@forge.pr | |ovo.novell.com | --- Comment #30 from Greg Kroah-Hartman 2011-09-21 23:36:35 UTC --- how is this a kernel issue? Totally confused... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=632530 https://bugzilla.novell.com/show_bug.cgi?id=632530#c32 --- Comment #32 from Marius Tomaschewski 2011-09-22 09:53:52 UTC --- (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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=632530 http://bugzilla.novell.com/show_bug.cgi?id=632530#c34 --- Comment #34 from Bernhard Wiedemann --- 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 -- You are receiving this mail because: You are on the CC list for the bug.