2019-12-08 Out of IPv4 addresses, way past time to start using IPv6
2019-11-21 First setup of the remoterig interfaces
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
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
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
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
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
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
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
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 mismatchesItems with tag ipv6 before 2018-04-06
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.