(new thread, back on topic)
Carlos E. R. wrote:
The problem is this:
cer@Telcontar:~> host download.opensuse.org download.opensuse.org has address 195.135.221.134 download.opensuse.org has IPv6 address 2001:67c:2178:8::13 cer@Telcontar:~>
Now look at this message from the kernel when booting and setting up the network:
<0.7> 2012-05-26 14:27:40 Telcontar kernel - - - [ 266.098003] eth0: no IPv6 routers present
Nevertheless, if the IPv6 address fails, programs attempt to send IPv6 over internet, even though there is no IPv6 router, only same segment transport.
One method of avoiding these connectivity problems would be to somehow not getting the IPv6 address in DNS queries, somehow.
_If_ we found such a solution, for instance by fiddling the incoming dns query flags, the only result would be a different error-message, wouldn't it?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-30 08:49, Per Jessen wrote:
(new thread, back on topic)
Carlos E. R. wrote:
The problem is this:
cer@Telcontar:~> host download.opensuse.org download.opensuse.org has address 195.135.221.134 download.opensuse.org has IPv6 address 2001:67c:2178:8::13 cer@Telcontar:~>
Now look at this message from the kernel when booting and setting up the network:
<0.7> 2012-05-26 14:27:40 Telcontar kernel - - - [ 266.098003] eth0: no IPv6 routers present
Nevertheless, if the IPv6 address fails, programs attempt to send IPv6 over internet, even though there is no IPv6 router, only same segment transport.
One method of avoiding these connectivity problems would be to somehow not getting the IPv6 address in DNS queries, somehow.
_If_ we found such a solution, for instance by fiddling the incoming dns query flags, the only result would be a different error-message, wouldn't it?
I guess.
I hopped that there would be a switch or something to tell the dns server not to deliver or not to ask outside for IPv6 resolution, no matter what the answer from outside is. This would help the many people that are still tied to IPv4 now and probably for years to come.
But no such thing is known :-(
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
On 2012-05-30 08:49, Per Jessen wrote:
(new thread, back on topic)
Carlos E. R. wrote:
The problem is this:
cer@Telcontar:~> host download.opensuse.org download.opensuse.org has address 195.135.221.134 download.opensuse.org has IPv6 address 2001:67c:2178:8::13 cer@Telcontar:~>
Now look at this message from the kernel when booting and setting up the network:
<0.7> 2012-05-26 14:27:40 Telcontar kernel - - - [ 266.098003] eth0: no IPv6 routers present
Nevertheless, if the IPv6 address fails, programs attempt to send IPv6 over internet, even though there is no IPv6 router, only same segment transport.
One method of avoiding these connectivity problems would be to somehow not getting the IPv6 address in DNS queries, somehow.
_If_ we found such a solution, for instance by fiddling the incoming dns query flags, the only result would be a different error-message, wouldn't it?
I guess.
I hopped that there would be a switch or something to tell the dns server not to deliver or not to ask outside for IPv6 resolution, no matter what the answer from outside is. This would help the many people that are still tied to IPv4 now and probably for years to come.
I agree that many people will remain on IPv4 for years to come, but I still don't really see what the problem is other than a slightly problematic error message when certain applications try to use IPv6?
If you try ping6, it behaves absolutely correct:
ping6 download.opensuse.org connect: Network is unreachable
This is presumably from the connect() call.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-30 13:58, Per Jessen wrote:
Carlos E. R. wrote:
I agree that many people will remain on IPv4 for years to come, but I still don't really see what the problem is other than a slightly problematic error message when certain applications try to use IPv6?
If you try ping6, it behaves absolutely correct:
ping6 download.opensuse.org connect: Network is unreachable
This is presumably from the connect() call.
Well, the problem is that some applications try to connect via IPv6 instead of trying another server that has an IPv4 address. One such is zypper/yast.
Right now, I'm using a /root/.curlrc file with the line:
- --ipv4
because curl is what zypper/yast use to download files, but I have doubts about it working. It failed once, but I can't confirm it (no log / confused log).
Another application I have some problems with is leafnode, it does attempt IPv6 addresses after IPv4 failed, instead of going to the backup news server immediately.
I also suspect problems with svn (subversion) but this one I haven't verified.
A neat solution would be that none of those applications knew that there existed IPv6 addresses, and so could not try them.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-30 13:58, Per Jessen wrote:
Carlos E. R. wrote:
I agree that many people will remain on IPv4 for years to come, but I still don't really see what the problem is other than a slightly problematic error message when certain applications try to use IPv6?
If you try ping6, it behaves absolutely correct:
ping6 download.opensuse.org connect: Network is unreachable
This is presumably from the connect() call.
Well, the problem is that some applications try to connect via IPv6 instead of trying another server that has an IPv4 address. One such is zypper/yast.
That sounds like like a bug then - when your system has no route to the IPv6 address, any attempts from zypper should fail immediately, and the next mirror can be tried.
Right now, I'm using a /root/.curlrc file with the line:
- --ipv4
because curl is what zypper/yast use to download files, but I have doubts about it working. It failed once, but I can't confirm it (no log / confused log).
Another application I have some problems with is leafnode, it does attempt IPv6 addresses after IPv4 failed, instead of going to the backup news server immediately.
I also suspect problems with svn (subversion) but this one I haven't verified.
A neat solution would be that none of those applications knew that there existed IPv6 addresses, and so could not try them.
Yes that would cure the symptom, but it would be better to investigate the cause, i.e. why those applications don't work like e.g. ping6 (from my earlier posting).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-30 15:44, Per Jessen wrote:
Carlos E. R. wrote:
Well, the problem is that some applications try to connect via IPv6 instead of trying another server that has an IPv4 address. One such is zypper/yast.
That sounds like like a bug then - when your system has no route to the IPv6 address, any attempts from zypper should fail immediately, and the next mirror can be tried.
And they fail (I don't know the timing for this, inmediate of after time out), but a second mirror is not tried. It asks the user what to do.
A neat solution would be that none of those applications knew that there existed IPv6 addresses, and so could not try them.
Yes that would cure the symptom, but it would be better to investigate the cause, i.e. why those applications don't work like e.g. ping6 (from my earlier posting).
I don't know if they fail intermediately, I think it does. Lets try, forcing ipv6:
cer@Telcontar:~> curl -o p --ipv6 http://download.opensuse.org/distribution/11.4/repo/oss/INDEX.gz
curl: (7) Failed to connect to 2001:67c:2178:8::13: Network is unreachable cer@Telcontar:~>
It fails instantly, that's good. The problem, for some people, is that sometimes it tries to use IPv6.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-30 15:44, Per Jessen wrote:
Carlos E. R. wrote:
Well, the problem is that some applications try to connect via IPv6 instead of trying another server that has an IPv4 address. One such is zypper/yast.
That sounds like like a bug then - when your system has no route to the IPv6 address, any attempts from zypper should fail immediately, and the next mirror can be tried.
And they fail (I don't know the timing for this, inmediate of after time out), but a second mirror is not tried. It asks the user what to do.
That is either a zypper or libcurl problem, I would say. Unless of course it's failing for download.opensuse.org in which case there may not be another mirror. (for the metalink file for instance).
A neat solution would be that none of those applications knew that there existed IPv6 addresses, and so could not try them.
Yes that would cure the symptom, but it would be better to investigate the cause, i.e. why those applications don't work like e.g. ping6 (from my earlier posting).
I don't know if they fail intermediately, I think it does. Lets try, forcing ipv6:
cer@Telcontar:~> curl -o p --ipv6 http://download.opensuse.org/distribution/11.4/repo/oss/INDEX.gz
curl: (7) Failed to connect to 2001:67c:2178:8::13: Network is unreachable cer@Telcontar:~>
It fails instantly, that's good. The problem, for some people, is that sometimes it tries to use IPv6.
Because it "works for me" (I currently only have link-local IPv6), I would tend to say that is a configuration problem, and those people ought to pursue that first.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-05-30 17:18, Per Jessen wrote:
Carlos E. R. wrote:
That sounds like like a bug then - when your system has no route to the IPv6 address, any attempts from zypper should fail immediately, and the next mirror can be tried.
And they fail (I don't know the timing for this, inmediate of after time out), but a second mirror is not tried. It asks the user what to do.
That is either a zypper or libcurl problem, I would say. Unless of course it's failing for download.opensuse.org in which case there may not be another mirror. (for the metalink file for instance).
Zypper should be cleverer, yes.
Since a week or two I have done a configuration change for curl, I have a /root/.curlrc file with a line "--ipv4" which should force curl to use ipv4 always, but I still do not know if it is honored.
A neat solution would be that none of those applications knew that there existed IPv6 addresses, and so could not try them.
Yes that would cure the symptom, but it would be better to investigate the cause, i.e. why those applications don't work like e.g. ping6 (from my earlier posting).
I don't know if they fail intermediately, I think it does. Lets try, forcing ipv6:
cer@Telcontar:~> curl -o p --ipv6 http://download.opensuse.org/distribution/11.4/repo/oss/INDEX.gz
curl: (7) Failed to connect to 2001:67c:2178:8::13: Network is unreachable cer@Telcontar:~>
It fails instantly, that's good. The problem, for some people, is that sometimes it tries to use IPv6.
Because it "works for me" (I currently only have link-local IPv6), I would tend to say that is a configuration problem, and those people ought to pursue that first.
Sorry, what configuration problem? I lost you.
If you mean like the one I mentioned above for curl, yes, I did that and I'm trying to confirm it works. But many programs do not have a switch to force ipv4 or ipv6.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
On 2012-05-30 17:18, Per Jessen wrote:
Carlos E. R. wrote:
That sounds like like a bug then - when your system has no route to the IPv6 address, any attempts from zypper should fail immediately, and the next mirror can be tried.
And they fail (I don't know the timing for this, inmediate of after time out), but a second mirror is not tried. It asks the user what to do.
That is either a zypper or libcurl problem, I would say. Unless of course it's failing for download.opensuse.org in which case there may not be another mirror. (for the metalink file for instance).
Zypper should be cleverer, yes.
Since a week or two I have done a configuration change for curl, I have a /root/.curlrc file with a line "--ipv4" which should force curl to use ipv4 always, but I still do not know if it is honored.
You could try running a tcpdump to catch ipv6 on port 80. Just leave it for a few weeks and see if it catches anything.
[snip]
Because it "works for me" (I currently only have link-local IPv6), I would tend to say that is a configuration problem, and those people ought to pursue that first.
Sorry, what configuration problem? I lost you.
Well, I don't know of course, but because I don't have this issue ("works for me") and I don't have external IPv6 connectivity, I think the current setup is working fine, and any problem with it is more likely to be due to a local configuration problem.
If you mean like the one I mentioned above for curl, yes, I did that and I'm trying to confirm it works. But many programs do not have a switch to force ipv4 or ipv6.
Because they don't need it. An IPv6-aware application that is having a problem on a IPv4-only network _could_ have been badly written, but for widely used applications, that is unlikely to be the reason. More likely it is a local configuration issue.
-
Carlos E. R. -
Per Jessen