2020-03-25 It's 2020 and github doesn't support IP version 6 1 week ago
Several of the machines here at home have IPv4 to the outside world disabled, simply to find every ancient service or program that still lives in the old world. Today I found one of those while installing dehydrated to automatically renew Let's Encrypt certificates. Indeed, github has no IPv6 support. It tries to be a modern service, but lacks an AAAA record. The solution is simple: use a webproxy to solve this. The only reason I still have a squid webproxy running is to be able to access IPv4-only http/https services from those hosts, so setting the http proxy in the global git config helped. I'm just surprised github doesn't support IPv6. Update: After some searching I found Github users have been asking about IPv6 connectivity since at least 2018 and the "solution" is that they currently don't support IPv6 and the request is on some list.
2020-01-24 Longest matching IPv6 address selection biting me 2 months ago
Trying to get devuan updates, I see:Err:5 http://nl.mirror.devuan.org/merged ascii Release 404 Not Found [IP: 2001:878:346::116 80] Err:6 http://nl.mirror.devuan.org/merged ascii-security Release 404 Not Found [IP: 2001:878:346::116 80] Err:7 http://nl.mirror.devuan.org/merged ascii-updates Release 404 Not Found [IP: 2001:878:346::116 80]While nl.mirror.devuan.org has no shortage of IPv6 and IPv4 addresses:;; ANSWER SECTION: nl.mirror.devuan.org. 78083 IN CNAME deb.devuan.org. deb.devuan.org. 78083 IN CNAME deb.roundr.devuan.org. deb.roundr.devuan.org. 845 IN AAAA 2001:638:a000:1021:21::1 deb.roundr.devuan.org. 845 IN AAAA 2a01:4f8:140:1102:2b76:955d:b48f:bdf3 deb.roundr.devuan.org. 845 IN AAAA 2001:878:346::116 deb.roundr.devuan.org. 845 IN AAAA 2a01:4f8:162:7293::14 deb.roundr.devuan.org. 845 IN AAAA 2800:a8:c001::a deb.roundr.devuan.org. 845 IN AAAA 2a01:4f9:2a:fa9::2 deb.roundr.devuan.org. 845 IN AAAA 2001:590:3803::31:151 deb.roundr.devuan.org. 845 IN AAAA 2001:4ca0:4300::1:19 deb.roundr.devuan.org. 845 IN AAAA 2a02:2a38:1:400:422a:422a:422a:422a deb.roundr.devuan.org. 845 IN AAAA 2a0a:e5c0:2:2:400:c8ff:fe68:bef3 ;; ANSWER SECTION: nl.mirror.devuan.org. 78063 IN CNAME deb.devuan.org. deb.devuan.org. 78063 IN CNAME deb.roundr.devuan.org. deb.roundr.devuan.org. 824 IN A 188.8.131.52 deb.roundr.devuan.org. 824 IN A 184.108.40.206 deb.roundr.devuan.org. 824 IN A 220.127.116.11 deb.roundr.devuan.org. 824 IN A 18.104.22.168 deb.roundr.devuan.org. 824 IN A 22.214.171.124 deb.roundr.devuan.org. 824 IN A 126.96.36.199 deb.roundr.devuan.org. 824 IN A 188.8.131.52 deb.roundr.devuan.org. 824 IN A 184.108.40.206 deb.roundr.devuan.org. 824 IN A 220.127.116.11 deb.roundr.devuan.org. 824 IN A 18.104.22.168 deb.roundr.devuan.org. 824 IN A 22.214.171.124I always get the error for 2001:878:346::116 when connecting. This site seems to have a problem with the devuan mirror at the moment, so I'd like to use another one, but apt keeps going back to the same source. This has to do with IPv6 address destination selection (RFC 3484 / RFC 6724). A good explanation at IPv6 Destination Address Selection – what, why, how - Karl Auer with:Rule 9, “use longest matching prefix“, will prefer the candidate destination address that shares the greatest number of contiguous leading bits with the source address that would be chosen for it. Such an address is likely to be topologically closer to the source address.Indeed that address is close to my home network addresses:2001:0878:0346:0000:0000:0000:0000:0116 2001:0980:14ca:0001::/64So the "roundr" round robin isn't very round for IPv6 users. Workaround: reject the address that is giving me problems:# ip -6 route add unreachable 2001:878:346::116 # apt update Get:1 http://nl.mirror.devuan.org/merged ascii InRelease [25.6 kB] Get:2 http://nl.mirror.devuan.org/merged ascii-security InRelease [25.6 kB] Get:3 http://nl.mirror.devuan.org/merged ascii-updates InRelease [25.6 kB] Get:5 http://nl.mirror.devuan.org/merged ascii-security/main Sources [185 kB] Hit:4 http://packages.roundr.devuan.org/merged ascii InRelease Get:6 http://nl.mirror.devuan.org/merged ascii-security/main amd64 Packages [480 kB]
2019-12-08 Out of IPv4 addresses, way past time to start using IPv6 3 months ago
2019-11-21 First setup of the remoterig interfaces 4 months ago
The remoterig set I ordered arrived. At first I found the box somewhat empty: no manuals. But the entire manual can be found on-line: User manuals - RemoteRig. The manual is about 200 pages so printing it would be a bad idea. The remoterig site is somewhat slow so I downloaded the PDF manual to my computer. Most of the setup is done via a webinterface, but the initial network setup needs either the right IP addresses hardcoded or a USB connection and the Microbit setup software which is only available for Windows. I did try to see whether one of the four com-ports via USB that showed up would allow me to do a minimal setup via a terminal program but that wasn't true. So I booted Windows to change the units to DHCP. For the radio-side I made an address allocation in the DHCP server, for the client side it is fine to have any usable address. And for my next minor issue: they only use IPv4. So my inner linux and networking geek is a bit dissapointed, but my inner radio geek will do just fine. After that bit I went back to Linux, the rest of the software setup is via a webbrowser. For the hardware setup, which is how it connects to the radio (which pin has audio, which pin has power) it needs a number of internal jumpers and jumper wires connected.
2019-09-19 Real IPv6 port scan/network mapping attempts 6 months ago
I noticed some interesting traffic in my home network this morning, an attempt at finding IPv6 systems. Since IPv6 privacy enhancements are enabled on most systems this is exactly like finding a needle in a haystack. I noticed an amount of outgoing icmpv6 traffic, and looking at the destination addresses and the type of traffic found lots of 'unreachable route' messages to a few Chinese IPv6 addresses. Searching for the netblock '240e:f7:4f01:c' finds more reports of portscanning activity.10:14:27.761704 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12980 > 2001:980:14ca:1:5054:ff:feae:17.902: Flags [S], cksum 0xd0a9 (correct), seq 3726392987, win 29200, options [mss 1460], length 0 10:14:28.278108 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.19933 > 2001:980:14ca:1:5054:ff:feae:8003.12587: Flags [S], cksum 0xe1cc (correct), seq 95632679, win 29200, options [mss 1460], length 0 10:14:29.219766 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.41487 > 2001:980:14ca:1:5054:ff:feae:fff2.902: Flags [S], cksum 0x3c31 (correct), seq 500442149, win 29200, options [mss 1460], length 0 10:14:33.637405 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.35832 > 2001:980:14ca:1:5054:ff:feae:15.902: Flags [S], cksum 0xa6ea (correct), seq 2324914849, win 29200, options [mss 1460], length 0 10:14:34.468975 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12470 > 2001:980:14ca:42::ffe8.16992: Flags [S], cksum 0x5a72 (correct), seq 3249792078, win 29200, options [mss 1460], length 0 10:14:34.469038 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::ffe8 10:14:35.230776 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.63145 > 2001:980:14ca:1:20d:56ff:fece:8006.19: Flags [S], cksum 0xb87b (correct), seq 4259180220, win 29200, options [mss 1460], length 0 10:14:35.952841 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.9056 > 2001:980:14ca:42::8013.16992: Flags [S], cksum 0xbb3b (correct), seq 2896438720, win 29200, options [mss 1460], length 0 10:14:35.952880 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::8013
2019-08-01 IPv6 growing up: ssh attempts to an inside machine 8 months ago
IPv6 is growing up: I saw an ssh attempt to an inside machine, reachable only via IPv6. The source was a Chinese IPv6 address which had not tried anything on any other public service.Jul 30 18:39:02 ritchie sshd: Bad protocol version identification '\026\003\001' from 240e:d9:d800:200::212 port 44926
2019-07-26 My Android phone gets an IPv6 address from t-mobile... but no routing 8 months ago
I just noticed in Network Info II that my android phone does get an IPv6 address from t-mobile. The address is something like 2a02:498:1fe1:9a02:2:3:xxxx:xxxx which is indeed in IPv6 address space allocated to T-Mobile Netherlands.% Information related to '2a02:498::/29' inet6num: 2a02:498::/29 netname: NL-T-MOBILE-20080609 country: NLSo I tested directly whether I could make an IPv6 connection to my website, but it fell back to IPv4. Network Info II saw no IPv6 route on the phone, but in later checking I also saw no IPv6 route when connected to the wifi at home, where IPv6 works fine. And doing a traceroute to that address from home shows that a core router at xs4all says network unreachable:3 0.ae22.xr4.1d12.xs4all.net (2001:888:1:4032::1) 6.105 ms !N 6.063 ms !N *So T-Mobile has activated some IPv6 address management in their network, but stopped at that point.
2019-06-20 De afhankelijkheid van xs4all verminderen 9 months ago
Sinds april 1993 heb ik een xs4all login account (ja, van voor de start, mijn account is met de hand aangemaakt door Rop Gonggrijp). Sinds begin 1992 had ik al een xs4all uucp account voor kzdoos.xs4all.nl, tegenwoordig omgezet naar een bsmtp account (waarbij mail binnenkomt bij de xs4all mailservers en na de spamfiltering doorgestuurd wordt naar mijn server). Maar met de laatste plannen van KPN om het merk xs4all te gaan stoppen en zaken samen te voegen ben ik toch bang dat de unieke redenen om daar te blijven langzaam zullen vervallen. Wat ik nodig heb is een plek met vast IPv4/IPv6 en een aardige uplink snelheid. Via xs4all kan dat gewoon thuis, maar misschien is op den duur een virtuele private server en een goedkope thuisaansluiting met daartussen een vorm van vpn ook een werkende oplossing. Dus dan is het ook tijd om langzaam minder afhankelijk te worden van de bsmtp service voor kzdoos.xs4all.nl en langzaam maar zeker mijn eigen domeinnaam idefix.net voor e-mail in te voeren als primair adres. Wie weet heeft de bsmtp dienst bij KPN ook niet het eeuwige leven. De extra opties die van xs4all een goede provider maken voor een hobbyist zitten bij andere providers vaak in een zakelijk pakket of worden niet aangeboden. Ik kon altijd beweren dat ik het e-mail adres wat ik gebruik gewoon ouder was dan spam e-mail.
2018-12-30 First annoyance with systemd on thompson 1 year ago
On reinstalling thompson I was not sure whether to pick ubuntu (with lots of package support for amateur radio) or devuan (without systemd). I chose ubuntu to keep access to lots of amateur radio packages but as expected the first systemd problem already got me. Names in the internal network with RFC1918 addresses weren't resolvable. After some searching I found out systemd-resolved had decided the last nameserver advertised via IPv6 was the one to use. As I could not find a lot of information on how to do the ordering I just decided to kick it all out and switch to normal resolving. Some searching found How to disable systemd-resolved in Ubuntu? - ask ubuntu which has the right steps. Back to somewhat normal, the next step is to convince NetworkManager to use IPv6 resolving before IPv4.
2018-12-07 Trying to kick spamassassin and perl into the 21st century and prefer IPv6 for DNS traffic 1 year ago
Or in short: Perl considered harmful I want applications to use and prefer IPv6 whenever possible, so I have a /etc/resolv.conf with IPv6 addresses of the nameserver(s) listed first. But I noticed queries from the spamassassin processes still coming in over the legacy IP protocol. Even when listing them in order in /etc/spamassassin/local.cf spamassassin prefers IPv4. And I want it to prefer IPv6 without leaving out IPv4. I like the redundancy but I want to change the preference. Also: I only want to maintain the list of nameservers in /etc/resolv.conf and not in other locations. I wrote a simple test program to understand what the perl Net::DNS::Resolver is doing. With a standard test program like:#!/usr/bin/perl -wT use strict; use Net::DNS; my $resolver = new Net::DNS::Resolver(); print join ' ', $resolver->nameservers(); print "\n";The IPv4 addresses will be listed first, independent of the order in /etc/resolv.conf. Only after changing to:#!/usr/bin/perl -wT use strict; use Net::DNS; my $resolver = new Net::DNS::Resolver(); $resolver->prefer_v6(1); print join ' ', $resolver->nameservers(); print "\n";I will see the IPv6 resolver listed first. But now to convince spamassassin to do the same. Browsing the Net::DNS::Resolver shows the RES_OPTIONS="inet6" option but does not document it. This option confuses spamassassin when starting:export RES_OPTIONS="inet6"root@gosper:/etc/default# service spamassassin restart Restarting SpamAssassin Mail Filter Daemon: Bad arg length for NetAddr::IP::Util::mask4to6, length is 128, should be 32 at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP/Lite.pm line 647. Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8. BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8. Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70. BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70. Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85. BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85. Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin.pm line 71. BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin.pm line 71. Compilation failed in require at /usr/sbin/spamd line 240. BEGIN failed--compilation aborted at /usr/sbin/spamd line 240.So that was a bad idea and is not the answer. Looking at the resolv.conf manpage shows that the option indeed does different things which explains why that was wrong.inet6 Sets RES_USE_INET6 in _res.options. This has the effect of trying an AAAA query before an A query inside the gethostbyname(3) function, and of mapping IPv4 responses in IPv6 "tunneled form" if no AAAA records are found but an A record set exists. Since glibc 2.25, this option is deprecated; applications should use getaddrinfo(3), rather than gethostbyname(3).So if I want perl programs to do what I want, I have to change every one of them to set $resolver->prefer_v6(1);. There is no sane default or a global "get into the 21st century" flag. Changing /usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm to include $res->prefer_v6(1); does help, but will need to be redone when updating spamassassin.
2018-05-03 The preferring IPv6 policy is working 1 year ago
Yesterday I changed some IPv4 addresses on virtual machines on the new homeserver to make autofs work. This is a known issue with autofs: autofs does not appear to support IPv6 hostname lookups for NFS mounts - Debian Bug #737679 and for me the easy solution is to do NFS mounts over rfc1918 ipv4 addresses. I prefer autofs over 'fixed' NFS mounts for those filesystems that are nice to be available but aren't needed constantly. It took about 9 hours before arpwatch on the central router noticed the new activity. I guess the policy to try to do everything over IPv6 is working.
2018-04-06 Keeping squid webproxy running for network mismatches 1 year ago
I considered stopping using squid when upgrading to the new homeserver but I have now changed that decision: I need to keep it running for applications that want to do http connections to IPv6-only systems but can't handle those. There are some old scripts running that need it but it's also the way to fix the problem I noticed with linuxcounter.
2017-10-11 Haproxy on the new home server and devuan upgrades 2 years ago
I got around again to working on the new homeserver 2017 and I worked on the installation of a 'testing' virtual machine with virt-install. This test machine also runs devuan linux. The first application I was testing on there is haproxy. I noticed some defaults I did not expect (such as preferring IPv4 over IPv6). It seems the 'stable' devuan has the same age issues as 'stable' debian. Otherwise haproxy does what it is supposed to and I may standardize on it. Upgrading was easy, I looked at Upgrading Devuan Jessie to Ascii and just changed jessie to ascii in /etc/apt/sources.list and did an apt-get dist-upgrade. The only minor issue afterwards is that the system now insists on using framebuffer video, which I find overkill for a virtual machine. VGA 80x25 is fine.
2017-10-09 Interesting NFS exports problem 2 years ago
I am used to being unable to unmount filesystems as long as they are NFS exported. It took me a while to find out how to correctly unexport filesystems before trying to unmount them. The easy solution would be to unexport everything and just export the other filesystems, but I'd rather not interrupt NFS availability of other filesystems. So it was time to check some large filesystems again and I'd rather not do that during boot as it can delay booting for up to an hour. Currently those filesystems are exported via IPv4 and IPv6. Removing the export for IPv4 is easy:# exportfs -u 192.168.1.0/255.255.255.0:/exportBut for IPv6 it gets harder:# exportfs -u 2001:db8:a::/64:/export exportfs: Invalid unexporting option: 2001So it is still exported via IPv6. And next thing I try to unmount it and notice it's ok to unmount a filesystem that is only exported via IPv6. I guess this shows some interesting bug.
2017-09-28 Duelling standards and anti-spam measures 2 years ago
In today's mail problems:----- Transcript of session follows ----- ... while talking to ecp-nl.mail.protection.outlook.com.: >>> DATA <<< 450 4.7.26 Service does not accept messages sent over IPv6 [2001:980:14ca:61::13] unless they pass either SPF or DKIM validation (message not signed) [VE1EUR01FT036.eop-EUR01.prod.protection.outlook.com] <firstname.lastname@example.org>... Deferred: 450 4.7.26 Service does not accept messages sent over IPv6 [2001:980:14ca:61::13] unless they pass either SPF or DKIM validation (message not signed) [VE1EUR01FT036.eop-EUR01.prod.protection.outlook.com] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days oldRerouting mail for ecp.nl via xs4all servers in the hopes of getting it delivered. Some research shows me that the xs4all outgoing mailservers (smtp.xs4all.nl) do offer incoming connectivity via IPv6 but don't connect to the IPv6 addresses of mailservers they are trying to reach.
2017-07-17 Now NetworkManager generates resolv.conf .. and starts with legacy IP 2 years ago
I removed rdnssd and resolvconf and fixed the symlink linking /var/run/NetworkManager/resolv.conf and /etc/resolv.conf by hand. The file /etc/NetworkManager/NetworkManager.conf now says:dns=none rc-manager=fileBut now I run into the 'NetworkManager prefers IPv4 resolvers' again, leaving me with the resolvers from the DHCP answer before those from the IPv6 route advertisment. The search domains are fine now.
2017-07-15 More resolving via IPv6 2 years ago
I was reading Debian Stretch - Het Lab Henk van de Kamer (in Dutch) which mentions removing package rdnssd to avoid a dependency problem. But I like rdnssd as it helps use the nameservers available via IPv6 in a network with only SLAAC and no DHCPv6. Right away I had to check on my own laptop with Ubuntu 16.04 and noticed all traffic was going to the IPv4 address of the local resolver. Which is not what I want, I want to prefer IPv6 when possible. Searching found Bug #936712 “NetworkManager should put IPv6 DNS servers before I...” : Bugs : network-manager package : Ubuntu which is indeed what I saw, and it's still showing in Ubuntu 16.04 Xenial. My solution was to stop using dnsmasq, and switch to a generated resolv.conf from NetworkManager. To do that I had to update /etc/NetworkManager/NetworkManager.conf to have:#dns=dnsmasq dns=none rc-manager=fileAnd now I have a resolv.conf with only 3 IPv6 nameservers and no search domains. Not exactly what I want, but at least IPv6 is preferred. I considered something using only the first three resolvers because that is a maximum somewhere but just advertising two resolvers via radvd also makes two show up in the generated resolv.conf. This is not perfect. The generated resolv.conf has comments that it is generated by resolvconf so maybe this is a conflict between resolvconf and NetworkManager not in 'use resolvconf' mode.
2017-07-10 Raspbian mirrors sometimes fail when IPv6-only 2 years ago
Just happening:Read the rest of Raspbian mirrors sometimes fail when IPv6-onlyErr http://mirrordirector.raspbian.org/raspbian/ jessie/main libgcrypt20 armhf 1.6.3-2+deb8u4 Cannot initiate the connection to raspbian.42.fr:80 (126.96.36.199). - connect (101: Network is unreachable) [IP: 188.8.131.52 80]It seems mirrordirector.raspbian.org redirects to IPv4-only sites even when the client connects via IPv6. My Raspberry Pi systems have IPv4 disabled. It's a known problem in Bug #1595563 “Native IPv6 client redirected to IPv4-only mirror” : Bugs : Raspbian where people seem to rather ignore the problem. I could reverse the statement there to "a service that can only be accessed by v4 nodes cannot be reasonablly considered to be available on the internet." but I guess that's "different".
2017-03-10 Keeping an eye on planes in the air 3 years agoOlder news items for tag ipv6 ⇒
I usually keep dump1090 running on a raspberry pi. It seems it is quite easy to share the data from dump1090 with Plane Finder so I decided to give that a try. With the installation instructions via the Share your data with Plane Finder page I had the software installed easily. But I needed to visit the configuration page of the software via IPv4... while I disabled IPv4 on the raspberry so it took some changes to make it work again. Next thing the software was reporting the data was available fine but not uploading to the Plane Finder server. Checking with strace shows that the software tries to upload via an IPv4-only connection which will not work. Temporary re-enabling IPv4 fixes things, so it's purely an IPv4/IPv6 thing.