Here is a comment I found on a discussion for a bug in Ubuntu. You can find the whole discussion here.


Some workarounds that "solves" this stupid bug:
1) disable IPv6 in linux kernel: echo "1" > /proc/sys/net/ipv6/conf/all/disable_ipv6
2) disable IPv6 for the wget: edit /etc/wgetrc and add line "inet4_only = on"

*************************************

Disabling IPv6 at the kernel level might solve your problem.

1 members found this post helpful.

khm, khm... Telindus 1132 ADSL router (got it from my ISP, no I can't change DNS settings on router)...
I'm trying to get the new one, linksys or something

I disabled it in modprobe.d
root@protoss:~# cat /etc/modprobe.d/ipv6.conf
alias net-pf-10 off
alias ipv6 off

But for sure I will take your advice and disable it in kernel and for wget too. Thanks a lot for helping me out m8

EDIT:

Hmmm...
root@protoss:~# /proc/sys/net/
core/ ipv4/ token-ring/ unix/

It's not there although I had problems with Firefox after clean install so I had to disable IPv6 in about:config and also Thunderbird didn't work until I added those lines at /modprobe.d/ipv6.conf...

Well, I attempted that echo after blacklisting the ipv6 module, which leaves that 'echo' command pointless as /proc/sys/net/ipv6/conf/all/disable_ipv6 is no longer there. But when I run a query against the DNS server on my firewall/router, the 'AAAA' (ipv6) record request still shows up, which is annoying.

I'm going to look into disabling ipv6 requests for DNS. You wouldn't think that would be necessary seeing ipv6 is disabled, but you know how that goes.

These things are like puzzles. I like a challenge to try to figure something like this out.

hehehe, same thing keeping me up

Yep, you can not let these problems win!

After looking at the DNS queries you posted, they all have AAAA (ipv6) queries initiated first, is that the case with all your DNS traffic, or just the slackpkg ones? That could be an indicator of why it is failing. It doesn't really get us any closer to the solution, but what the hell, theories are about all we have right now!

All my DNS queries have the A record request first, then the AAAA request following it. I was reading the man page for resolv.conf, which mentions setting an option for sending the AAAA request first. Just made me wonder, that's all.

I've read in a few places where people have mentioned that the only true way of removing the ipv6 protocol is to turn it off in the kernel config and recompile. After looking at what I'm seeing with ipv6 DNS traffic going to the DNS server on my DNS server here, it makes me think they might have a point.

Still, I'm of the mind that those requests can be somehow disabled. Don't know how, but dammit, there has to be a feasible way.

And seeing the issue with your wireless ADSL modem, I appreciate my OpenWRT firewall all the more now.

Hmmnn...I'm going to set my DNS queries from my Slack laptop to send ipv6 queries first, and see if that makes any difference.

Things aren't looking good regarding your problem. The deeper I dig, it appears less likely there is a simple solution for this problem. Check out this thread:

http://osdir.com/ml/linux.debian.dev.../msg00004.html

That thread refers to this thread, which is a google translation from a Dutch site, but you can get the idea of what they're saying. Even though ipv6 is turned off everywhere, it's a matter of how glibc handles requests, or at least that's the case according to these people.

Dutch forum google translation

just to clarify something. just because you are getting a AAAA record this doesn't mean you are using ipv6. it just means your reslover is asking a dns server for the ipv6 record for a host. if ipv6 is disabled then that means you won't be able to send/receive ipv6 traffic. if you do "/sbin/ifconfig <int> | grep inet6" and get nothing then you aren't using ipv6.

this is a weird problem. i would doubt that the problem is with your router though as other programs like ping and host are able to use the dns resolver just fine. i would think that the problem is with wget. try using strace to see what wget is doing. maybe that will help.

1 members found this post helpful.

Good morning
Just woke up, turned on comp and did wget/slackpkg tests :

wget:

root@protoss:~# tcpdump -s 0 -nni eth0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:46:13.672254 IP 192.168.1.2.33239 > 208.67.222.222.53: 33202+ A? www.dnbradio.com. (34)
10:46:13.675989 IP 208.67.222.222.53 > 192.168.1.2.33239: 33202- 1/0/0 A 207.234.208.71 (50)
10:46:14.024459 IP 192.168.1.2.34344 > 208.67.222.222.53: 60267+ A? dnbradio.com. (30)
10:46:14.028381 IP 208.67.222.222.53 > 192.168.1.2.34344: 60267- 1/0/0 A 207.234.208.71 (46)
10:46:14.394748 IP 192.168.1.2.41730 > 208.67.222.222.53: 50255+ A? www.dnbrrecs.com. (34)
10:46:14.398562 IP 208.67.222.222.53 > 192.168.1.2.41730: 50255- 1/0/0 A 208.97.175.79 (50)


slackpkg:

root@protoss:~# tcpdump -s 0 -nni eth0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:47:01.487414 IP 192.168.1.2.37615 > 208.67.222.222.53: 51336+ A? ftp.slackware.no. (34)
10:47:01.710090 IP 208.67.222.222.53 > 192.168.1.2.37615: 51336 1/2/1 A 158.36.2.10 (114)


As you can see goes without any problems and I didn't make any changes since last night... Ok, now I'm confused
Btw, I kept opendns servers as I did last night.

Will try again to see what actually happens with getting AAAA records first and why This is getting interesting

@Dev
Yeah I posted on linux.org.ba same question but people are puszzled there too. Also checked the links and same thing happens to that guy and he also tried exactly everything I did.
Also, I used 12.2 on this network and I didn't have any problems with slapt-get, gslapt and wget.

@Fancylad
Will use strace to seek for more informations but as you could see, weird thing happened moments ago when everything worked out just fine. Now I wanna know why...

EDIT:
I tried different mirrors and everything works now! How the hell... Is it possible that some of the programs I use can initiate seek for ipv6 first?

EDIT2:
Actually, only change, since last night was to wgetrc "inet4_only = on"

Yes, I agree, although in this case I think it was a matter of turning off ipv6 in an attempt to eliminate the ipv6 related DNS traffic. Actually, I doubt that compiling a kernel with ipv6 turned off would solve the problem being seen here -- to which you are referring, or so I would imagine.

I've done a fair amount of research on this issue, and have found a number of bugs/forum posts relating to this very issue. There are a few low level router/modem models that exhibit an inability to properly handle ipv6 requests. The Telindus 1132 anger uses is mentioned a few times.

I just fired up my trusty old Slack laptop, and fired off a 'slackpkg update', to find the only thing it is doing is resolving a domain name, then straight into ftp. Something that did stand out in this circumstance, is that this time around the AAAA request was the first packet issued, whereas all the other requests I have captured show the A record request as the first one.

02:42:36.349424 IP 10.xx.xx.117.39161 > 10.xx.xx.1.53: 57913+ AAAA? slackware.mirrors.tds.net. (43)
02:42:36.401704 IP 10.xx.xx.1.53 > 10.xx.xx.117.39161: 57913 0/1/0 (103)
02:42:36.404889 IP 10.xx.xx.117.41661 > 10.xx.xx.1.53: 2414+ AAAA? slackware.mirrors.tds.net.lan. (47)
02:42:36.406539 IP 10.xx.xx.1.53 > 10.xx.xx.117.41661: 2414 NXDomain 0/0/0 (47)
02:42:36.408541 IP 10.xx.xx.117.47165 > 10.xx.xx.1.53: 4240+ A? slackware.mirrors.tds.net. (43)
02:42:36.429561 IP 10.xx.xx.1.53 > 10.xx.xx.117.47165: 4240 1/7/7 A 204.246.0.134 (288)

My theory is that if I had a Telindus 1132 such as anger has, and issued the request above to it, I would have received a 1.0.0.0 resolution due to the AAAA request being first. I have to admit the more I read about the ipv6/AAAA request problem, the overall picture behind it gets vague.

I've read where dproxy, a name server, that has been used with busybox has some sort of a bug regarding ipv6 DNS requests, but that wouldn't cause the issue anger is seeing because he isn't using his modem as a DNS server, he makes his requests directly to external servers. (that, and we really don't know what the OS of the modem is, either) If the modem were running a DNS proxy in conjunction with a pnat rule to capture outbound UDP traffic to port 53, then I could see the issue anger is having being on the modem. Then again, perhaps the modem is simply choking on plain ol' outbound ipv6 DNS requests -- which could very well be possible. That would be a sad state of affairs, but possible nonetheless.

Could be software related too. There could be something strange being inserted into the outbound query. One way or another, it is going to show up in the network traffic, as the problem is the result of a DNS query.

I woke up at 1:30 am, and have been reading about this issue since.

I'm glad to see everything is working now! Maybe it is the order of the the ipv4 versus ipv6 DNS requests being an issue, who knows. Unfortunately, there aren't any AAAA requests in your capture, leaving that theory open. Hopefully you won't have to deal with this issue again. fancylad is right -- it's a bizarre problem to say the least.

I'm going to fire up strace. I haven't used it in a long time, and know very little about it. My background is more on the networking side of things overall, so becoming more knowledgeable about troubleshooting at a system level would be good.

Bingo!
It seems change in /wgetrc fixed the problem! I tested all this with my laptop, which was offline for a week now. As soon as it started I tried to update but I couldn't, same error, while my desktop machine was working ok. So, I added "inet4_only = on" in /etc/wgetrc, rebooted and run it again, and it worked like a charm!!!

Could be it? Testings are on!

Hmmnn...could be! I ran strace on 'slackpkg update' and see that wget is called.

'strace -f -o test.txt slackpkg update'

You can see it all happening, step by step. Cool! I'm studying the wget call and how it is going about setting up the socket it is going to use for the DNS call. The '-f' option tells strace to follow the forks, which of course the captures the wget call. Check it out, could come in handy for your issue if it does resurface. Thanks for making this suggestion fancylad! I'd forgotten about this tool.

if you don't want the trace truncated, use this:

'strace -fv -o test.txt slackpkg update'

There!
4642 execve("/usr/bin/wget", ["wget", "--passive-ftp", "ftp://ftp.slackware.no/pub/linux"..., "-O", "/tmp/slackpkg.FHRUXR/ChangeLog.t"...]$

Thats why 'ipv4_only = on' worked!

Thanks a lot ppl, you were really helpful! All respect to tha community!
Special greetings to devwatchdog

Haha, look at this :O
It's not related with slackpkg or wget, it's irc :

- Connecting to chat.efnet.org (1.0.0.0) port 6667...

- tcp 0 1 192.168.1.2:46784 1.0.0.0:6667 SYN_SENT

And ofcourse after pinging real address this comes out:

- Connecting to chat.efnet.org (67.213.223.85) port 6667...

- tcp 0 0 192.168.1.2:56784 67.213.223.85:6667 ESTABLISHED

I mean it's not anything strange after we concluded there is a problem with ipv6 although it is disabled in modprobe.d but still...

From one of Dev's links:

> That's an interesting problem, and although I don't have an answer, I
> can tell you that disabling the IPv6 module would not solve the problem.
> You see, the IPv6 module only controls the handling of ipv6 packets sent
> or received, while your problem is generating AAAA queries. Since the
> AAAA queries can be - and in this case are - transported over IPv4, it's
> not working.
>
> The solution should involve the resolver library, which you control via
> /etc/resolv.conf. As far as I can tell, there is no system-wide way to
> prevent the use of IPv6, so no luck there.
>
> The only way I can think of (if you can't just update the DNS server to
> be able to handle IPv6 requests) is to install a local DNS server in
> your own laptop, disable handling (and querying) of AAAA records in the
> DNS server and make it recursive. Finally, point your resolver
> (/etc/resolv.conf) only to your local DNS server.

And there is one more suggestion about routers doing NAT, that could be problem too, so I will get another adsl router and tried with that.