Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-06 Thread Gustavo Noronha Silva
On Sat, 2009-08-01 at 16:12 +, Debian Bug Tracking System wrote:
  if you have to disable ipv6 to make the internet connection fast, the 
  setup 
  at your provider is broken - Debian comes with working out of the box 
  support 
  for ipv6, if you need to disable it to make the network work for you, there 
  is something wrong on the network.

While I agree in general, it is still a PITA that Debian fails miserably
in these cases. It does cause a bad impression. I keep having problems
with misbehaving ipv6 myself, and it seems unlikely that stuff will just
start supporting ipv6 correctly in the near future.

While at debconf I was debugging why epiphany-webkit (libsoup, really)
was failing to get to Rhonda's blog, and it seems like DNS was resolving
the name to the ipv6 address as well as the ipv4. It seems like firefox
handles this by falling back, but soup doesn't.

Can we do better?

See you,

-- 
Gustavo Noronha Silva k...@debian.org
Debian




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-06 Thread Stephen Gran
This one time, at band camp, Gustavo Noronha Silva said:
 While at debconf I was debugging why epiphany-webkit (libsoup, really)
 was failing to get to Rhonda's blog, and it seems like DNS was resolving
 the name to the ipv6 address as well as the ipv4. It seems like firefox
 handles this by falling back, but soup doesn't.

Debconf had fully working ipv6.  I do wish you could have reported
problems with it at the time so we could have looked at it.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature


Re: Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-03 Thread Bjørn Mork
Tollef Fog Heen tfh...@err.no writes:
 ]] Roger Leigh 

 | Having working local networking is important.  We wouldn't consider
 | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
 | bad.

 Sure, having it working is important.  Is it more important than keeping
 those (often new) users for whom Debian appears useless because of its
 perceived poor network performance?

I don't think measuring the importance of these bugs against each other
is going to be productive.  

Workarounds for bugs in other systems are fine, but not adding bugs in
Debian should be an absolute requirement for such workarounds.


Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-02 Thread Tollef Fog Heen
]] Roger Leigh 

| Having working local networking is important.  We wouldn't consider
| broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
| bad.

Sure, having it working is important.  Is it more important than keeping
those (often new) users for whom Debian appears useless because of its
perceived poor network performance?

Anyway, IIRC this is now solved in glibc by sending out the queries in
parallel and returning the first answer you get.

| The idea behind the patch isn't bad, but the implementation proposed
| here is too naïve.  The assumption that you only want working IPv6
| name resolution when you have a globally-scoped IPv6 address is too
| simplistic.

FWIW, it roughly matches what Mac OS X and Windows do.

| Not only do you have the local loopback, you also have link-local
| addresses which you can legitimately use.  Does zeroconf support
| these?  Fundamentally breaking IPv6 for these use cases to work around
| broken routing hardware is IMO a step too far.

Does anybody use IPv6-only link-local?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-02 Thread Philipp Kern
On 2009-08-02, Tollef Fog Heen tfh...@err.no wrote:
| Not only do you have the local loopback, you also have link-local
| addresses which you can legitimately use.  Does zeroconf support
| these?  Fundamentally breaking IPv6 for these use cases to work around
| broken routing hardware is IMO a step too far.
 Does anybody use IPv6-only link-local?

I occassionally did and I think Gobby even supports that now in conjunction
with Zeroconf.

Kind regards,
Philipp Kern



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-02 Thread Roger Leigh
On Sun, Aug 02, 2009 at 08:39:46AM +0200, Tollef Fog Heen wrote:
 ]] Roger Leigh 
 
 | Having working local networking is important.  We wouldn't consider
 | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
 | bad.
 
 Sure, having it working is important.  Is it more important than keeping
 those (often new) users for whom Debian appears useless because of its
 perceived poor network performance?

It would be nice if both worked.  But, in the absence of good heuristics
for detecting broken networking, this is probably something that should
not be done automatically.

 Anyway, IIRC this is now solved in glibc by sending out the queries in
 parallel and returning the first answer you get.

OK.  What happens to the other answer(s) though?  Does this mean that
getaddrinfo(3) skips slow replies completely?  This is surely equally
broken if so?

For anyone with broken networking, the test program here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=addrtest.c;att=1;bug=441857
will test local name resolving in glibc; just replace ip6-localhost with
a hostname to check.

 | The idea behind the patch isn't bad, but the implementation proposed
 | here is too naïve.  The assumption that you only want working IPv6
 | name resolution when you have a globally-scoped IPv6 address is too
 | simplistic.
 
 FWIW, it roughly matches what Mac OS X and Windows do.

And it's not considered broken on these platforms too?

I guess the proportion of IPv6 users is vastly lower on these platforms
due to the general networking clue level of the users, and that Windows
has had fully functional IPv6 networking for a much shorter time than
GNU/Linux.

 | Not only do you have the local loopback, you also have link-local
 | addresses which you can legitimately use.  Does zeroconf support
 | these?  Fundamentally breaking IPv6 for these use cases to work around
 | broken routing hardware is IMO a step too far.
 
 Does anybody use IPv6-only link-local?

Probably not conciously; it's intended to be used automatically.  A
quick google shows Avahi does use these (with some caveats).

IPv6 has the concept of Scope, and these scopes include Node/Host,
Link, Site, Organisation, and Global.  To assume that IPv6 networking
is only active when you have one or more Global addresses is an
incorrect assumption.  With the previous glibc patch, my networking
broke as the Global link went up and down.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature


Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-02 Thread Tollef Fog Heen
]] Roger Leigh 

| On Sun, Aug 02, 2009 at 08:39:46AM +0200, Tollef Fog Heen wrote:
|  ]] Roger Leigh 
|  
|  | Having working local networking is important.  We wouldn't consider
|  | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
|  | bad.
|  
|  Sure, having it working is important.  Is it more important than keeping
|  those (often new) users for whom Debian appears useless because of its
|  perceived poor network performance?
| 
| It would be nice if both worked.  But, in the absence of good heuristics
| for detecting broken networking, this is probably something that should
| not be done automatically.

Both would be nice, of course.  Sometimes you have to choose between
having the cake and eating it, though.

|  Anyway, IIRC this is now solved in glibc by sending out the queries in
|  parallel and returning the first answer you get.
| 
| OK.  What happens to the other answer(s) though?  Does this mean that
| getaddrinfo(3) skips slow replies completely?  This is surely equally
| broken if so?

Unsure.  The man page for getaddrinfo doesn't seem to imply that you get
all answers if you specify AF_UNSPEC, it specifies «any».  Your test
program does get both the A and the  record, so my recollection of
this might be incorrect.

[...]

|  | The idea behind the patch isn't bad, but the implementation proposed
|  | here is too naïve.  The assumption that you only want working IPv6
|  | name resolution when you have a globally-scoped IPv6 address is too
|  | simplistic.
|  
|  FWIW, it roughly matches what Mac OS X and Windows do.
| 
| And it's not considered broken on these platforms too?

You're talking about 0.07% of the users for Windows Vista (and 0.03% for
XP), Mac OS X is at a whopping 2.4%.  I doubt many users would see if
their IPv6 was broken since there are few/no IPv6 services out there.
(From
http://www.ripe.net/ripe/meetings/ripe-57/presentations/Colitti-Global_IPv6_statistics_-_Measuring_the_current_state_of_IPv6_for_ordinary_users_.7gzD.pdf
 )

| Probably not conciously; it's intended to be used automatically.  A
| quick google shows Avahi does use these (with some caveats).
| 
| IPv6 has the concept of Scope, and these scopes include Node/Host,
| Link, Site, Organisation, and Global.  To assume that IPv6 networking
| is only active when you have one or more Global addresses is an
| incorrect assumption.  With the previous glibc patch, my networking
| broke as the Global link went up and down.

It did actually put the threshold at site, not global, since people
could reasonably put site-only names into DNS, but link-local addresses
shouldn't be in DNS.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-02 Thread Roger Leigh
On Sun, Aug 02, 2009 at 03:53:48PM +0200, Tollef Fog Heen wrote:
 ]] Roger Leigh 
 
 | On Sun, Aug 02, 2009 at 08:39:46AM +0200, Tollef Fog Heen wrote:
 |  Anyway, IIRC this is now solved in glibc by sending out the queries in
 |  parallel and returning the first answer you get.
 | 
 | OK.  What happens to the other answer(s) though?  Does this mean that
 | getaddrinfo(3) skips slow replies completely?  This is surely equally
 | broken if so?
 
 Unsure.  The man page for getaddrinfo doesn't seem to imply that you get
 all answers if you specify AF_UNSPEC, it specifies «any».  Your test
 program does get both the A and the  record, so my recollection of
 this might be incorrect.

Just tested on current sid for localhost where this is listed in /etc/hosts
as both 127.0.0.1 and ::1:

% addrtest localhost 3

Addrinfo for 0x21f8f90
Flags:  32
Family: 10
Socket Type:1 
Protocol:   6 (tcp)
Canonical name: (null) 
Socket Address (len=28):
  Port: 3   
  IPv6 Address: ::1 

Addrinfo for 0x21f8ff0
Flags:  32
Family: 10
Socket Type:2 
Protocol:   17 (udp)
Canonical name: (null)  
Socket Address (len=28):
  Port: 3   
  IPv6 Address: ::1 

Addrinfo for 0x21f9050
Flags:  32
Family: 10
Socket Type:3 
Protocol:   0 (ip)
Canonical name: (null)
Socket Address (len=28):
  Port: 3   
  IPv6 Address: ::1 

Addrinfo for 0x21f81a0
Flags:  32
Family: 2 
Socket Type:1 
Protocol:   6 (tcp)
Canonical name: (null) 
Socket Address (len=16):
  Port: 3   
  IPv4 Address: 127.0.0.1

Addrinfo for 0x21f81f0
Flags:  32
Family: 2 
Socket Type:2 
Protocol:   17 (udp)
Canonical name: (null)  
Socket Address (len=16):
  Port: 3   
  IPv4 Address: 127.0.0.1
ravenclaw% ./at localhost 3 5
Usage: ./at hostname port
ravenclaw% ./at localhost
Usage: ./at hostname port
ravenclaw% ./at localhost 44

Addrinfo for 0x8bdf90
Flags:  32   
Family: 10   
Socket Type:1
Protocol:   6 (tcp)
Canonical name: (null) 
Socket Address (len=28):
  Port: 44  
  IPv6 Address: ::1 

Addrinfo for 0x8bdff0
Flags:  32   
Family: 10   
Socket Type:2
Protocol:   17 (udp)
Canonical name: (null)  
Socket Address (len=28):
  Port: 44  
  IPv6 Address: ::1 

Addrinfo for 0x8be050
Flags:  32   
Family: 10   
Socket Type:3
Protocol:   0 (ip)
Canonical name: (null)
Socket Address (len=28):
  Port: 44  
  IPv6 Address: ::1 

Addrinfo for 0x8bd1a0
Flags:  32   
Family: 2
Socket Type:1
Protocol:   6 (tcp)
Canonical name: (null) 
Socket Address (len=16):
  Port: 44  
  IPv4 Address: 127.0.0.1

Addrinfo for 0x8bd1f0
Flags:  32   
Family: 2
Socket Type:2
Protocol:   17 (udp)
Canonical name: (null)  
Socket Address (len=16):
  Port: 44  
  IPv4 Address: 127.0.0.1

Testing again for via proper DNS for noc.sixxs.net:

% addrtest noc.sixxs.net 44

Addrinfo for 0x142f190
Flags:  32
Family: 2 
Socket Type:1 
Protocol:   6 (tcp)
Canonical name: (null) 
Socket Address (len=16):
  Port: 44  
  IPv4 Address: 213.197.29.32

Addrinfo for 0x142f1e0
Flags:  32
Family: 2 
Socket Type:2
Protocol:   17 (udp)
Canonical name: (null)
Socket Address (len=16):
  Port: 44
  IPv4 Address: 213.197.29.32

Addrinfo for 0x142f230
Flags:  32
Family: 2
Socket Type:3
Protocol:   0 (ip)
Canonical name: (null)
Socket Address (len=16):
  Port: 44
  IPv4 Address: 213.197.29.32

Addrinfo for 0x142f280
Flags:  32
Family: 10
Socket Type:1
Protocol:   6 (tcp)
Canonical name: (null)
Socket Address (len=28):
  Port: 44
  IPv6 Address: 2001:838:1:1:210:dcff:fe20:7c7c

Addrinfo for 0x142f2e0
Flags:  32
Family: 10
Socket Type:2
Protocol:   17 (udp)
Canonical name: (null)
Socket Address (len=28):
  Port: 44
  IPv6 Address: 2001:838:1:1:210:dcff:fe20:7c7c


I've attached a slightly updated version of the test code.  I'd
be interested on the results for people with broken nameservers.
The above tests are on a system without a Scope:Global IPv6
address but with working  DNS lookups.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
/* Copyright © 2007  Roger Leigh rle...@debian.org
 *
 * addrtest is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 

Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-01 Thread Debian Bug Tracking System

Your message dated Sat, 1 Aug 2009 18:09:54 +0200
with message-id 200908011809.54427.hol...@layer-acht.org
and subject line your provider provides buggy internet
has caused the Debian Bug report #535833,
regarding general: Slow internet on iceweasel, epiphany and so on...
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
535833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535833
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: general
Severity: important


The internet connection is very slow when using
the internet navigator on Debian 5.0.
This problem doesn't appear on another computer 
of my network under ubuntu whereas the DNS used 
is the same for all computers.

I fixed this problem: after typing 'about:config' 
in the adress bar of iceweasel, I modified the 
key 'network.dns.disableIPv6' to 'true'.

This operation works for iceweasel and for epiphany 
too.

I don't know if other applications are affected
by this problem (synaptic may be affected).

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


---End Message---
---BeginMessage---
Hi,

if you have to disable ipv6 to make the internet connection fast, the setup 
at your provider is broken - Debian comes with working out of the box support 
for ipv6, if you need to disable it to make the network work for you, there 
is something wrong on the network.


regards,
Holger


signature.asc
Description: This is a digitally signed message part.
---End Message---


Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-01 Thread Tollef Fog Heen
]]  (Debian Bug Tracking System)

| if you have to disable ipv6 to make the internet connection fast,
| the setup at your provider is broken - Debian comes with working out
| of the box support for ipv6, if you need to disable it to make the
| network work for you, there is something wrong on the network.

This is probably the same bug as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435646, which while a
bug in the DSL router of users is not possible for most of them to work
around, while fairly trivial for us to work around in libc.  (Heck, I
believe newer libcs already have the fix in.)

(I think we should fix it, but I'm not going to fight that battle again,
since apparently having loopback ipv6 when no other IPv6 address is
configured working is more important than making Debian usable for
certain people without having to disable ipv6.  See 441857 for the other
bug in the story.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)

2009-08-01 Thread Roger Leigh
On Sat, Aug 01, 2009 at 09:51:26PM +0200, Tollef Fog Heen wrote:
 ]]  (Debian Bug Tracking System)
 
 | if you have to disable ipv6 to make the internet connection fast,
 | the setup at your provider is broken - Debian comes with working out
 | of the box support for ipv6, if you need to disable it to make the
 | network work for you, there is something wrong on the network.
 
 This is probably the same bug as
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435646, which while a
 bug in the DSL router of users is not possible for most of them to work
 around, while fairly trivial for us to work around in libc.  (Heck, I
 believe newer libcs already have the fix in.)
 
 (I think we should fix it, but I'm not going to fight that battle again,
 since apparently having loopback ipv6 when no other IPv6 address is
 configured working is more important than making Debian usable for
 certain people without having to disable ipv6.  See 441857 for the other
 bug in the story.)

Having working local networking is important.  We wouldn't consider
broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
bad.

The idea behind the patch isn't bad, but the implementation proposed
here is too naïve.  The assumption that you only want working IPv6
name resolution when you have a globally-scoped IPv6 address is too
simplistic.  Not only do you have the local loopback, you also have
link-local addresses which you can legitimately use.  Does zeroconf
support these?  Fundamentally breaking IPv6 for these use cases to
work around broken routing hardware is IMO a step too far.

If there's a better metric for detecting that IPv6 name resolution is
broken, and then disabling it, I wouldn't be opposed to it as long as
it doesn't break things which are currently working.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature