Since (at least) version 2.0.49-r19 portage does not sync with IPv6 rsync anymore. This is caused by the actual location of the SYNC mirror being replaced by the result of ip=socket.gethostbyname(hostname) and gethostbyname not supporting AAAA records. A (bigger and most probably improvable) replacement for gethostbyname for IPv6 would be ipv6socks = socket.getaddrinfo(hostname,None,10,socket.SOCK_STREAM) for socket in ipv6socks: ipv6.append(socket[4][0]) resulting in a list named ipv6 with all IPv6 addresses afterwards. Reproducible: Always Steps to Reproduce: 1. set SYNC=rsync://rsync.de.gentoo.org/gentoo-portage in /etc/make.conf 2. emerge sync Actual Results: Connection is established with IPv4 to one of the 14 german rsync mirrors Expected Results: Connection should be established with IPv6 to one of the two german IPv6 rsync mirrors Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.6.0) ================================================================= System uname: 2.6.0 i686 AMD Athlon(TM) XP 2000+ Gentoo Base System version 1.4.3.10p1 distcc 2.11.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ipv6.rrze.uni-erlangen.de/mirrors/gentoo ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo http://www.fhh.opensource-mirror.de/gentoo.org/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow X alsa apm avi berkdb bonobo cdr crypt cups dvd encode esd foomaticdb gdbm gif gpm gtk gtk2 gtkhtml guile imlib ipv6 java jpeg kde libg++ libwww mad mikmod motif mozilla moznocompose moznomail mpeg ncurses nls oggvorbis opengl oss pam pdflib perl pic png python qt quicktime radeon readline samba sdl slang spell sse ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
You wrote: > ipv6socks = socket.getaddrinfo(hostname,None,10,socket.SOCK_STREAM) Is the third args 10(=socket.AF_INET6) better than 0? (I'm not familiar with ipv6...)
It depends on what records you need. with AFI 0 you get both IPv4 and IPv6 with AFI 2 you get IPv4 only with AFI 10 you get IPv6 only I think the best would be to replace the current gethostbyname() call in portage with getaddrinfo and make the AFI configurable through make.conf. Default could/should be AFI 0 with an option to force it to AFI 2.
You mean we'd have new value in make.conf ( and make.conf.default" ? example: in make.conf RSYNC_IPV4orV6="v4" or RSYNC_IPV4orV6="v6" or RSYNC_IPV4orV6="both" the value name is temporary ;)
i think if you use just 0 (use both ipv4 and ipv6) it'll be fine introducing a new variable for this is cruft imho ;)
Would be a good idea. My reason to file this bug was to revert to the old style (always do IPv6 first), but if it was configurable it would be even better (there was already an old bug requesting this, #30801).
Oh my... I think this bug may be deferred, as current rsync (2.6.0) seems to have a bug regarding the specification of literal IPv6 addresses on the command line (-> it does not work). Has to be fixed in rsync first.
Perhaps there's an obvious answer for this, but why aren't we passing rsync the specified hostname? Why are we trying to resolve it for rsync? Rsync does perfectly well resolving ipv6 addresses for given hoestnames and even has a command line argument telling it to prefer ipv4 or ipv6 addresses.
It's very hard to handle a round-robin and provide try-next-on-failure support if we can't trust the resolver to give us a new machine each time we request one. It's random. Also this allows us to log the server you're connecting to.
*** Bug 57704 has been marked as a duplicate of this bug. ***
The bug in rsync has finally been fixed upstream, see https://bugzilla.samba.org/show_bug.cgi?id=1675
I just did a very small proof-of-concept patch onto portage-2.0.50-r11 that allows syncing through IPv6 again Problems so far: a) Python's getaddrinfo() seems to have an ugly list sorting mechanism, the first address returned by getaddrinfo() is always the same, the other ones seem to be shuffled with a local short-time cache. This might be a bug in python or some extra option to getaddrinfo()? b) I can not be called familiar with Python, the code is probably ugly and I had to introduce two global(?) temporary variables named ipsockets and socket, I'm sure this can be made a local variable in some way c) The "0" in socket.getaddrinfo(hostname,None,0,socket.SOCK_STREAM) should probably be a user defined variable (make.conf) with 0 = System default (usually IPv6 first, then IPv4) 2 = IPv4 only 10 = IPv6 only Steps to reproduce: 1) Apply patch to /usr/lib/portage/bin/emerge 2) ACCEPT_KEYWORDS=~x86 emerge '=net-misc/rsync-2.6.3' 3) SYNC=rsync://rsync.de.gentoo.org/gentoo-portage emerge --ask sync Do you want to sync your Portage tree with the mirror at rsync://[2001:638:500:101::21]/gentoo-portage? [Yes/No] y 4) Hope your local resolver does not point you to the other box in rsync.de which is dead (I'll file a bug about this)
Created attachment 41398 [details, diff] Proof-of-concept for IPv6-aware emerge
Created attachment 41401 [details, diff] Improved patch Sorting of getaddrinfo() is intended in glibc according to some friends and is done by comparing the first bits of the own network address with the result list. So I changed the code, getaddrinfo() is now only used for IPv6 and randomized before usage, then IPv4 is imported with the old gethostbyname_ex() which copies the randomized network format. Syncing with IPv6-enabled rotations (rsync.de.gentoo.org) works (with normal fallback to another server if no IPv6) as well as IPv4-only rotations (rsync.europe.gentoo.org)
*** Bug 30801 has been marked as a duplicate of this bug. ***
Created attachment 65574 [details, diff] The old patch but in the correct unified format Curious to see if ipv6 is still giving issues, or if the issues covered here are gone. Also looking for input on whether the patch works for everyone or not.
It's basically come down to the same issue. *** This bug has been marked as a duplicate of 27093 ***
Sorry, I don't think so. Bug 27093 was about forcing rsync to v4 or v6 back in 2003 when portage passed an hostname to rsync. Since beginning of 2004 portage resolves the hostname on its own (currently IPv4-only, this is why I opened this bug) and passes an IP-address to rsync in order to be able to sync to the same host several times (due to the timestamp-thing introduced). The situation described in bug 27093 isn't in the code anymore.
Created attachment 68172 [details, diff] Improved patch This patch against portage-2.0.52 is an improved version of my older patch. By setting RSYNC_IPV="4" or "6" as suggested in bug 27093 the user can choose between IPv4-only or IPv6-only. I removed the randomizing because it helps you to get closer mirrors first. In default setting current glibc/python returns all IPv6-addresses, then all IPv4-addresses if the kernel is IPv6-enabled and has a non-link-local IPv6-address (~= global IPv6 connectivity), or vice versa if the kernel is not IPv6-enabled or has no global addresses configured. You need >=net-misc/rsync-2.6.3 to sync to IPv6-hosts. An example for an IPv6-enabled mirror would be SYNC="rsync://ftp.join.uni-muenster.de/gentoo-portage"
*** Bug 27093 has been marked as a duplicate of this bug. ***
Is there someone working on this bug? The last activity seems to be 10 months ago. If you don't plan on changing this behaviour of portage, to resolve the hostname itself before passing it to rsync (which is just wrong, IMHO), you should at least check PORTAGE_RSYNC_EXTRA_OPTS for "-6" or "--ipv6" and print a warning, that this option isn't supported, because as it is now, rsync just gives an error message and the user has no idea of what happened, since the mirror he specified should support IPv6.
I'd love to know that as well. I asked quite a few months ago (I think end of last year) whether the patch had a chance to be integrated (in the IRC channel) and was told that a new breed of portage was in development and my patch would not be integrated into the old version anymore. If someone could give me the path to the SVN repository where current development is going on (where a patch can be integrated) I could give it a try.
(In reply to comment #21) > If someone could give me the path to the SVN repository where current > development is going on (where a patch can be integrated) I could give it a > try. The svn repo isn't yet accessible anonymously but the latest revisions can be downloaded from viewcvs here: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/ I also put snapshots of trunk in my dev space occasionally: http://dev.gentoo.org/~zmedico/portage/snapshots/
The old patch still applies perfectly, after replacing "portage.settings" with "settings" it works as expected: Sync against IPv6+IPv4 hosts works # SYNC="rsync://ftp.join.uni-muenster.de/gentoo-portage" ./emerge --sync >>> Starting rsync with rsync://[2001:638:500:101::21]/gentoo-portage... >>> Checking server timestamp ... Welcome to ftp.uni-muenster.de, University of Muenster IPv6 FTP server. How are you gentlemen? All your base are belong to us. Syncing against hosts with only IPv4 works # SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" ./emerge --sync >>> Starting rsync with rsync://81.88.37.23/gentoo-portage... >>> Checking server timestamp ... -===================================================================- Fallback from IPv6 to IPv4 works # ip6tables -A INPUT -s 2001:638:500:101::21 -j DROP # SYNC="rsync://ftp.join.uni-muenster.de/gentoo-portage" ./emerge --sync >>> Starting rsync with rsync://[2001:638:500:101::21]/gentoo-portage... >>> Checking server timestamp ... rsync: failed to connect to 2001:638:500:101::21: Connection timed out (110) rsync error: error in socket IO (code 10) at clientserver.c(107) [receiver=2.6.8] >>> Retrying... >>> Starting retry 1 of 3 with rsync://128.176.191.21/gentoo-portage >>> Checking server timestamp ... Welcome to ftp.uni-muenster.de, University of Muenster IPv6 FTP server. Forcing AFI to IPv4 works # RSYNC_IPV=4 SYNC="rsync://ftp.join.uni-muenster.de/gentoo-portage" ./emerge --sync >>> Starting rsync with rsync://128.176.191.21/gentoo-portage... Forcing AFI to IPv6 (most probably) works RSYNC_IPV=6 SYNC="rsync://ftp.join.uni-muenster.de/gentoo-portage" ./emerge --sync >>> Starting rsync with rsync://[2001:638:500:101::21]/gentoo-portage... >>> Checking server timestamp ... rsync: failed to connect to 2001:638:500:101::21: Connection timed out (110) rsync error: error in socket IO (code 10) at clientserver.c(107) [receiver=2.6.8] >>> Retrying... >>> Starting retry 1 of 3 with rsync://[2001:638:500:101::21]/gentoo-portage net-misc/rsync-2.6.8* is marked stable on almost all archs (mips, ppc-macos and x86-fbsd missing), so that shouldn't be a blocker anymore. I can think of two code improvements which I will integrate if requested: a) Throw an error when forced to an AFI with RSYNC_IPV, but the rsync host does not have an address of this AFI (throw error if ips is empty after the lookup) b) force lookups to IPv4 only if not >=net-misc/rsync-2.6.3 For the latter I would need hints how to get that information from portage best, I'd rather not call "rsync --version" and parse the output.
Created attachment 91524 [details, diff] Patch against portage-2.1.1_pre20060710
How about if we call it PORTAGE_SYNC_IPV. I prefer to prefix any portage env vars with PORTAGE_ in order to prevent name collision and to make it clear that the variable is intended for portage. Also, perhaps SYNC is better than RSYNC, since it's possible that we can reuse this variable in the future for protocols other than rsync. I know that Marius (genone) has been working on a modular sync framework for portage, so he may want to chime in on this.
(In reply to comment #25) Why does it need an extra configuration variable in the first place? My suggestion would be to check the already existing PORTAGE_RSYNC_EXTRA_OPTS. If it contains "-4" or "--ipv4" the user obviously wants to use only IPv4, if it's "--ipv6" or "-6", he wants IPv6. An additional variable just makes it more complicated, and you have to check for a situation in which those two variables are set to contradictorily values anyways.
Created attachment 91544 [details, diff] patch using -4/-6 in PORTAGE_RSYNC_OPTS Great idea actually, I've updated the patch accordingly. It's not working with PORTAGE_RSYNC_EXTRA_OPTS yet because those are not parsed like PORTAGE_RSYNC_OPTS, but just appended to the called command. I'm working on that.
Created attachment 91545 [details, diff] patch using -4/-6 in PORTAGE_RSYNC_OPTS Great idea actually, I've updated the patch accordingly. It's not working with PORTAGE_RSYNC_EXTRA_OPTS yet because those are not parsed like PORTAGE_RSYNC_OPTS, but just appended to the called command. I'm working on that.
Created attachment 91881 [details, diff] Updated patch, gets -4/-6 from PORTAGE_RSYNC_* Updated patch, now honours -4/-6 in PORTAGE_RSYNC_OPTS and PORTAGE_RSYNC_EXTRA_OPTS. Zac, anything I can do to get that thing included as soon as possible? I'd rather not port this patch to three more portage rewrites.
Thanks, this is fixed in svn r3908.
This has been released in 2.1.1_pre3-r1.
(In reply to comment #31) > This has been released in 2.1.1_pre3-r1. > What was released? I'm using portage-2.1.1_pre5-r1 and it doesn't honour "-4" in both PORTAGE_RSYNC_OPTS and PORTAGE_RSYNC_EXTRA_OPTS. I can only use ipv4, so portage is broken to me. Cheers Renato
(In reply to comment #32) > > This has been released in 2.1.1_pre3-r1. > What was released? I'm using portage-2.1.1_pre5-r1 and it doesn't honour "-4" > in both PORTAGE_RSYNC_OPTS and PORTAGE_RSYNC_EXTRA_OPTS. Works for me [tm] # equery list portage [I--] [ ~] sys-apps/portage-2.1.1_pre5-r1 (0) # emerge --sync >>> Starting rsync with rsync://[2001:638:500:101::21]/gentoo-portage... # PORTAGE_RSYNC_EXTRA_OPTS=-4 emerge --sync >>> Starting rsync with rsync://128.176.191.21/gentoo-portage... besides that no official Gentoo rsync rotation has an IPv6 address yet, and it is supposed to do a graceful fallback even if it had _and_ your network configuration would be broken to try IPv6 when no IPv6 was configured. Please paste the mirror you are using and the portage output which makes you think the breakage is related to IPv6.
Now I see the problem is caused by a different thing (sorry): rsync when compiled with "USE=-ipv6" doesn't accept the -4/--ipv4 option. This means that this solution doesn't work for me.. (I have USE=-ipv6) I have to manually ping rsync.gentoo.org in order to use "emerge --sync". Otherwise it gets the address 1.0.0.0 and hangs.. Several apps exibit this behaviour when compiled with ipv6 support, so.. Please reopen the bug.
(In reply to comment #34) > rsync when compiled with "USE=-ipv6" doesn't accept the -4/--ipv4 option. This > means that this solution doesn't work for me.. (I have USE=-ipv6) What happens if you just omit "-4"? Maybe we should delete the -4/-6 flags before passing the options to rsync to fix those issues. > I have to manually ping rsync.gentoo.org in order to use "emerge --sync". > Otherwise it gets the address 1.0.0.0 and hangs.. Several apps exibit this > behaviour when compiled with ipv6 support, so.. I cannot confirm that, please give me output. rsync.gentoo.org does not have any AAAA record, I'm still not sure why you would see anything about IPv6 here.
(In reply to comment #35) > (In reply to comment #34) > > > rsync when compiled with "USE=-ipv6" doesn't accept the -4/--ipv4 option. This > > means that this solution doesn't work for me.. (I have USE=-ipv6) > > What happens if you just omit "-4"? Maybe we should delete the -4/-6 flags > before passing the options to rsync to fix those issues. > Simply ommiting "-4" gives me this: # emerge --sync >>> Starting rsync with rsync://1.0.0.0/gentoo-portage... >>> Checking server timestamp ... (hang) If I do add "-4" I get a valid IP address, but then rsync spits out the "unknown option" error end exits. If I ping rsync.gentoo.org or after using the "-4" option (or anything that caches the correct ip adress), then I can sync. > > I have to manually ping rsync.gentoo.org in order to use "emerge --sync". > > Otherwise it gets the address 1.0.0.0 and hangs.. Several apps exibit this > > behaviour when compiled with ipv6 support, so.. > > I cannot confirm that, please give me output. rsync.gentoo.org does not have > any AAAA record, I'm still not sure why you would see anything about IPv6 here. I first experienced this behaviour when installed gentoo. If ipv6 was enabled then the apps first resolved for the ipv6 address and then for the ipv4. For some unknown reason they allways got address 1.0.0.0. After some digging around in the forums I disabled the ipv6 use flag, and then apps would get the correct ip address. This may be the fault of my router (which as far as I know is only ipv4-aware). Anyway, pinging the site would make the app get the correct address, so I supose there is some kind of IP caching going on. It must be a problem with the ipv6 resolving.. ipv6 is broken in my setup, so I must have a way to force the use ipv4..
> > What happens if you just omit "-4"? Maybe we should delete the -4/-6 flags > > before passing the options to rsync to fix those issues. > Simply ommiting "-4" gives me this: > > # emerge --sync > >>> Starting rsync with rsync://1.0.0.0/gentoo-portage... > >>> Checking server timestamp ... > (hang) > > If I do add "-4" I get a valid IP address, but then rsync spits out the > "unknown option" error end exits. If I ping rsync.gentoo.org or after using > the "-4" option (or anything that caches the correct ip adress), then I can > sync. This sounds so broken it makes me vomit. a) run python and enter the following commands > import socket > socket.getaddrinfo('rsync.gentoo.org', None, 0, socket.SOCK_STREAM) report the output b) Is the IPv6 kernel module loaded (do you have an fe80::* address on a device)? Run # ip -6 addr | grep -v fe80 # ip -6 route and report the output c) What device is the first nameserver in your /etc/resolv.conf? Your router? Try to remove that and replace it with your ISPs nameserver. Ultimately, try to replace it with 217.146.139.5 (that is an open recursive nameserver) d) Are you running nscd? Try to stop it using /etc/init.d/nscd e) Run "tcpdump -n -s 0 -i <interfacetonameserver> port domain" while starting emerge --sync and report the output > After some digging around in the forums I disabled the ipv6 use flag, and then > apps would get the correct ip address. This may be the fault of my router > (which as far as I know is only ipv4-aware). Anyway, pinging the site would > make the app get the correct address, so I supose there is some kind of IP > caching going on. 99% of the routers are only IPv4 aware. This is fine, as your box won't even bother to try connecting with IPv6 if you don't have any address configured. It must not break resolving IPv6 records though, which I suspect it is doing. > It must be a problem with the ipv6 resolving.. ipv6 is broken in my setup, so > I must have a way to force the use ipv4.. I'll try to work up a patch. In the meantime _after_ you have reported the above requested outputs you could try to disable IPv6 in the kernel completely by adding alias net-pf-10 off to /etc/modprobe.conf (I think)
(In reply to comment #37) > > > What happens if you just omit "-4"? Maybe we should delete the -4/-6 flags > > > before passing the options to rsync to fix those issues. > > Simply ommiting "-4" gives me this: > > > > # emerge --sync > > >>> Starting rsync with rsync://1.0.0.0/gentoo-portage... > > >>> Checking server timestamp ... > > (hang) > > > > If I do add "-4" I get a valid IP address, but then rsync spits out the > > "unknown option" error end exits. If I ping rsync.gentoo.org or after using > > the "-4" option (or anything that caches the correct ip adress), then I can > > sync. > > This sounds so broken it makes me vomit. > > a) run python and enter the following commands > > import socket > > socket.getaddrinfo('rsync.gentoo.org', None, 0, socket.SOCK_STREAM) > > report the output Here it is: [(2, 1, 6, '', ('1.0.0.0', 0))] > > b) Is the IPv6 kernel module loaded (do you have an fe80::* address on a > device)? Run No, it is not even compiled.. I'm compiling it now as a module to see if loading it changes anything. > # ip -6 addr | grep -v fe80 No output.. > # ip -6 route 192.168.1.0/24 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 192.168.1.1 dev eth0 <--------(my router) > > and report the output > > c) What device is the first nameserver in your /etc/resolv.conf? Your router? Yap, my router. > Try to remove that and replace it with your ISPs nameserver. Ultimately, try to > replace it with 217.146.139.5 (that is an open recursive nameserver) It seems that replacing it with the isp's nameserver works. I'll reboot to clear the cache and see if this works again. > d) Are you running nscd? Try to stop it using /etc/init.d/nscd No, not running. > e) Run "tcpdump -n -s 0 -i <interfacetonameserver> port domain" while starting > emerge --sync and report the output tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 23:25:18.053975 IP 192.168.1.2.32794 > 195.23.129.126.53: 1251+ AAAA? rsync.gentoo.org. (34) 23:25:18.081264 IP 195.23.129.126.53 > 192.168.1.2.32794: 1251 0/0/0 (34) 23:25:18.081734 IP 192.168.1.2.32794 > 195.23.129.126.53: 8693+ AAAA? rsync.gentoo.org. (34) 23:25:18.107106 IP 195.23.129.126.53 > 192.168.1.2.32794: 8693 0/0/0 (34) 23:25:18.107480 IP 192.168.1.2.32794 > 195.23.129.126.53: 12495+ A? rsync.gentoo.org. (34) 23:25:18.135454 IP 195.23.129.126.53 > 192.168.1.2.32794: 12495 6/0/0 A 134.68.220.73, A 64.127.121.98, A 38.99.64.200, A 140.211.166.165, A 134.68.220.97, A 134.68.220.74 (130) Please note that emerge --sync already worked after replacing the router nameserver for the isp one. I'll reboot and check this again. > > After some digging around in the forums I disabled the ipv6 use flag, and then > > apps would get the correct ip address. This may be the fault of my router > > (which as far as I know is only ipv4-aware). Anyway, pinging the site would > > make the app get the correct address, so I supose there is some kind of IP > > caching going on. > > 99% of the routers are only IPv4 aware. This is fine, as your box won't even > bother to try connecting with IPv6 if you don't have any address configured. > > It must not break resolving IPv6 records though, which I suspect it is doing. > > > It must be a problem with the ipv6 resolving.. ipv6 is broken in my setup, so > > I must have a way to force the use ipv4.. > > I'll try to work up a patch. In the meantime _after_ you have reported the > above requested outputs you could try to disable IPv6 in the kernel completely > by adding I supose it was already disabled. In any case I'll do that once I reboot. > > alias net-pf-10 off > > to /etc/modprobe.conf (I think) > Thanks! Renato
> > report the output > Here it is: > [(2, 1, 6, '', ('1.0.0.0', 0))] This is sick. > Please note that emerge --sync already worked after replacing the router > nameserver for the isp one. I'll reboot and check this again. Please do so. I suspect the router breaks its internal states when queried with a type it does not understand. If you verified the router to be your problem please name vendor, model and firmware version, there is definitely some shame to be applied. If it is not the newest firmware an upgrade might help as well. Funny, I've been extensively doing IPv6 for five years now, but I have not seen anything alike before.
(In reply to comment #38) > > c) What device is the first nameserver in your /etc/resolv.conf? Your router? > > Yap, my router. > > > Try to remove that and replace it with your ISPs nameserver. Ultimately, try to > > replace it with 217.146.139.5 (that is an open recursive nameserver) > > It seems that replacing it with the isp's nameserver works. I'll reboot to > clear the cache and see if this works again. As promissed, the second thing I did after reboot was to change the nameserver, and it worked again. Restarting the eth0 interface (and reruning dhcp) seems to reset the cache. I was able to isolate the /etc/resolv.conf problem.. > > e) Run "tcpdump -n -s 0 -i <interfacetonameserver> port domain" while starting > > emerge --sync and report the output > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode (...) The first thing I did after rebooting: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 23:49:47.389892 IP 192.168.1.2.32771 > 192.168.1.1.53: 30232+ AAAA? rsync.gentoo.org. (34) 23:49:47.422862 IP 192.168.1.1.53 > 192.168.1.2.32771: 30232 0/0/0 (34) 23:49:47.423203 IP 192.168.1.2.32771 > 192.168.1.1.53: 64794+ AAAA? rsync.gentoo.org. (34) 23:49:47.425629 IP 192.168.1.1.53 > 192.168.1.2.32771: 64794- 1/0/0 (34) 23:49:47.425949 IP 192.168.1.2.32771 > 192.168.1.1.53: 30024+ A? rsync.gentoo.org. (34) 23:49:47.427548 IP 192.168.1.1.53 > 192.168.1.2.32771: 30024- 1/0/0 A 1.0.0.0 (50) 23:50:38.710323 IP 192.168.1.2.32771 > 192.168.1.1.53: 20662+ A? bugs.gentoo.org. (33) 23:50:38.712072 IP 192.168.1.1.53 > 192.168.1.2.32771: 20662- 1/0/0 A 140.211.166.163 (49) Now the sync didn't work, so this should be the important dump. > > I'll try to work up a patch. In the meantime _after_ you have reported the > > above requested outputs you could try to disable IPv6 in the kernel completely > > by adding > > I supose it was already disabled. In any case I'll do that once I reboot. > > > > > alias net-pf-10 off > > > > to /etc/modprobe.conf (I think) > > > > Thanks! > Renato >
(In reply to comment #39) > > > report the output > > Here it is: > > [(2, 1, 6, '', ('1.0.0.0', 0))] > > This is sick. > > > Please note that emerge --sync already worked after replacing the router > > nameserver for the isp one. I'll reboot and check this again. > > Please do so. I suspect the router breaks its internal states when queried with > a type it does not understand. If you verified the router to be your problem > please name vendor, model and firmware version, there is definitely some shame > to be applied. If it is not the newest firmware an upgrade might help as well. The router is a problematic piece of hardware. It's a cheap model, based in the ar7 chip from texas instruments. Unfortunately as far as I know it is a "custom" model made only for my country (Portugal), as a DSL Modem+Router solution. It is branded NTech ADSL-AR41A, and the support is really bad. On the other hand, on the "product information" area of the http interface, it states the Model Number as being "AR7RD" and the firmware version 45.2.1. I suspect I will not be able to find an updated firmware for this product. This will eventually make me hack the firmware. After all, it's a mips core running linux :) > Funny, I've been extensively doing IPv6 for five years now, but I have not seen > anything alike before. >
Here we go .... > 23:49:47.389892 IP 192.168.1.2.32771 > 192.168.1.1.53: 30232+ AAAA? > rsync.gentoo.org. (34) What is the IPv6 address of rsync.gentoo.org? > 23:49:47.422862 IP 192.168.1.1.53 > 192.168.1.2.32771: 30232 0/0/0 (34) The hostname exists (rcode NOERROR), but it does not have any record of the requested type (AAAA = IPv6). ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0. This is the correct and expected behaviour when an IPv6 record is queried for an IPv4-only hostname. > 23:49:47.423203 IP 192.168.1.2.32771 > 192.168.1.1.53: 64794+ AAAA? > rsync.gentoo.org. (34) I ask you again what is the IPv6 address of rsync.gentoo.org (I'd love to know what causes this doubled request) > 23:49:47.425629 IP 192.168.1.1.53 > 192.168.1.2.32771: 64794- 1/0/0 (34) The hostname exists (NOERRROR) and I have an answer section of the size 1 (which means one record of the requested type). But, there is no answer attached to this packet, which is broken in the first place. Does not seem to cause any visible harm to the client though. > 23:49:47.425949 IP 192.168.1.2.32771 > 192.168.1.1.53: 30024+ A? > rsync.gentoo.org. (34) Okay, then I want to know the IPv4 address of rsync.gentoo.org > 23:49:47.427548 IP 192.168.1.1.53 > 192.168.1.2.32771: 30024- 1/0/0 A 1.0.0.0 > (50) I have one address for rsync.gentoo.org which is 1.0.0.0 Broken. Plain broken. Could you do that again and write a pcap logfile with "-w filename" and attach this file to this bug? I'd love to see all gory details of those responses. If you get the box hacked I'd love to know what piece of software they used for DNS proxying. I tried google to find some information about this modem and found http://surecom-forums.no-ip.biz:8001/auth/phpBB2/viewtopic.php?t=1907&sid=fd67ac69834525b227d6e0ab1c5fc89a which tells me to contact the .pt reseller for this box on http://www.niposom.com .
Created attachment 94424 [details] The pcap logfile Here's the file generated by adding "-w logfile" to tcpdump.
(In reply to comment #42) > Broken. Plain broken. Could you do that again and write a pcap logfile with "-w > filename" and attach this file to this bug? I'd love to see all gory details of > those responses. Atached the logfile.. > If you get the box hacked I'd love to know what piece of software they used for > DNS proxying. I tried google to find some information about this modem and > found > http://surecom-forums.no-ip.biz:8001/auth/phpBB2/viewtopic.php?t=1907&sid=fd67ac69834525b227d6e0ab1c5fc89a > which tells me to contact the .pt reseller for this box on > http://www.niposom.com . > The dns proxy software is dproxy, unknown version. I can already ssh into it. The next step is to open it up to get access to its (internal) serial port.. I already knew that support site, but it had been down for maintenance for a while. I'm glad to see it's online again now! Thanks! I'll see if they want to help.. Cheers Renato
