2019-07-29 Tried receiving ISS SSTV with the FUNcube Dongle Pro+
This evening had scheduled Amateur Radio on the International Space Station slow-scan TV transmissions so I took Arrow antenna, the new FUNcube Dongle Pro+, cables and laptop outside. I found out gqrx crashes when the dongle is on the righthandside USB port of the laptop, so that one is out. On the backside port everything was working, and audio routing worked routing the analog output audio (created by qgrx) to the recording by audacity and the image decoding with qsstv. Gpredict was set up to control the reception frequency in gqrx, and this whole setup was working ok. But the signal from the ISS looked very very weak in gqrx, just a small rise in level above the noise when I pointed at the general direction of the ISS. No idea why. No images were decoded from it. After the pass I tried receiving some other sources with this setup and receiving the PI2NOS repeater went fine. But that's on the 70 centimeters band. I saw no activity on PI3UTR which would have enabled a test on 2 meters. This needs more testing. Maybe something to hold the antenna cables so they don't get pulled from the laptop/radio during a pass. Update: Most likely culprit: interference in the 2 meter amateur band. With a handheld radio that has received ISS packet sounds before I could now only hear them very faint in the noise. The local 2 meter noise is killing weak signal reception.
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-07-25 First onewire stats ageing out
I was looking at some onewire temperature stats and noticed the first stats being aged out. I started monitoring temperatures with 1-wire sensors in January 2007 using rrdtool. I set up round robin archives with an expiry in 11 years, and those 11 years have passed now for the first measurements.
2019-07-21 BrewDog Indie Pale Ale
Another random find in the 'special beers' rack in the local supermarket. I usually like IPA beers, so this one sounded good to me. Not as strong a taste as I would expect from an IPA. The influence of hop is just a mere touch, not as strong as some other IPA beers. On the grand scale of beers it's a tasty but not too complex.
The beer details
Company BrewDog Beer name Indie Pale Ale Beer style IPA - India Pale Ale Alcohol by volume 4.2 %
2019-07-20 Going full duplex with amateur satellites, part 14: Switch to FUNcube Dongle Pro+
I saw a radio amateur offering a secondhand FUNcube Dongle Pro+ for a very reasonable price and remembered my work to get into linear satellites and the problems with the input filtering on an rtl-sdr while transmitting. So I checked the specifications for that dongle and saw a lot better filtering. I decided to go for it and a few mails later the dongle was on the way to my letterbox. Literally, as it fitted in a small package that could be delivered in the letterbox. With tracking, so I received a notification from the package tracker app after the mailman put it in the letterbox. There is good support for the FUNcube dongle Pro+ in gqrx so I tried that first. It does give some USB errors:[46918.612090] usb 2-1: new full-speed USB device number 10 using xhci_hcd [46918.762268] usb 2-1: New USB device found, idVendor=04d8, idProduct=fb31 [46918.762273] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [46918.762276] usb 2-1: Product: FUNcube Dongle V2.0 [46918.762278] usb 2-1: Manufacturer: Hanlincrest Ltd. [46918.797477] usb 2-1: 1:1: cannot get freq at ep 0x81 [46918.803092] hid-generic 0003:04D8:FB31.0003: hiddev0,hidraw0: USB HID v1.11 Device [Hanlincrest Ltd. FUNcube Dongle V2.0 ] on usb-0000:00:14.0-1/input2 [46918.917284] usb 2-1: 1:1: cannot get freq at ep 0x81 [46918.955162] usb 2-1: 1:1: cannot get freq at ep 0x81It does show as a valid device in gqrx and I was soon decoding audio with it. The easiest decoding was in the VHF II FM broadcast band. After all the work with the 2 MHz wide spectrum from the rtl-sdr it takes a bit of adjusting to start working with 192 kHz spectrum from the FUNcube dongle but qgrx moves that bit nicely when needed. To the computer, the dongle is an USB device with two subfunctions: an usbaudio device and a usbhid device. The audio device is used to deliver sampled radio spectrum and the hid device is used to control the dongle. This is why it's relatively easy to use softwarewise: modern operating systems have usbaudio support and usb hid control from a user application isn't too hard either. One of the things I do want is a lot of interesting audio routing to be able to record both the downlink audio and my own audio. So I fired up pavucontrol and gqrx crashed. Restarting gqrx did not work until I closed pavucontrol. Some searching found gqrx crash with Funcube Pro+ which suggests to turn the device off for PulseAudio. Which may seem strange but PulseAudio is also using the alsa drivers which gqrx tries to use. I guess there is some conflict between gqrx and PulseAudio in dealing with the alsa drivers. After switching the FUNcube Dongle Pro+ in PulseAudio I could open the dongle in gqrx and play with audio settings for other channels in pavucontrol. The setup with gpredict controlling the receive frequency of gqrx also worked fine, so this is looking good. Now to find out how things work on an FM or linear satellite.
2019-07-15 Still SMTP floods from 185.222.211.x addresses
A month later I'm still seeing SMTP floods from 126.96.36.199 and adjacent addresses. I activated the sendmail-reject filter ruleset in fail2ban which keeps several addresses in that range blocked most of the time. Given reports like 188.8.131.52 | Cloud Core LP | AbuseIPDB and 184.108.40.206 | Cloud Core LP | AbuseIPDB I'm not the only one seeing abuse from this range.
2019-07-14 I participated in the IARU-HF championship 2019
This weekend I participated in the IARU HF Championship and made a nice number of contacts given the available time in which I could call out my callsign. Before the contest the radio propagation was a bit dissapointing and I did most of my preparation at the very last minute. For the contest logging I used the TLF linux contest logger which does not support the IARU HF Championship out of the box. But someone posted about this contest to the TLF development mailing list and shared the configuration and initial exchange list, so it was minimal work to get going. With this configuration TLF worked as a logger, it just didn't calculate the multipliers in the contest correctly. In the end I made 95 contacts, which is a nice improvement over the previous time I participated in this contest: IARU HF Championship PE4KH 2017. Of the 95 contacts, 19 were on the 40 meter band (Saturday evening) and 76 on the 20 meter band (Saturday afternoon and Sunday morning). I did not participate in the 2018 edition because it was the weekend we left for our summer holiday. The 2018 IARU HF championship was also the World Radio Team Championship 2018 so I missed the chance to work one of those stations. I did follow the whole preparation for the WRTC 2018 and had a look at the developments in the scores during that weekend.Read the rest of I participated in the IARU-HF championship 2019
2019-07-10 Einde van (weer) een tijdperk: geen DVB-T meer in Nederland
Op 9 Juli is de laatste omschakeling van DVB-T naar DVB-T2 geweest in Nederland, waarmee DVB-T ten einde gekomen is. In de ether is dus van 2 oktober 1951 tot 10 december 2006 analoog uitgezonden en van 10 december 2006 tot 2 oktober 2018 (eerste regio) - 9 juli 2019 (laatste regio) in DVB-T. De Samsung televisie die we aangeschaft hebben in mei 2013 snapt er niets meer van bij een scan op het UHF spectrum. Vooraf had ik gezocht of deze televisie DVB-T2 en de gebruikte codec ondersteunde en dat was wat onduidelijk, het hing af van de taal van de handleiding. Uiteindelijk werkt het dus duidelijk niet, de scan voor digitale tv signalen levert helemaal geen resultaat op. Dus we hebben geen NPO 1/2/3 meer free-to-air wat we gebruikten sinds de prijsverhogingen en wijzigingen van Ziggo in 2015. Bij een eerste test bleken de livestreams van de NPO applicatie met chromecast ook te werken. Alleen heeft een hapering van de internetverbinding ook gelijk het gevolg dat de televisie stopt. Het voelt wel raar om voor 'broadcast' televisie een stream aan te zetten, maar dat zal wel liggen aan de geschiedenis die er voor mij achter zit.
2019-07-08 I participated in the DL-DX RTTY Contest 2019
This weekend was the DL-DX RTTY Contest 2019. In the category 'B': single operator, multiband, 6 hours. Not in the category for dipole or groundplane antenna since I used the endfed antenna. I made 80 contacts, 37 on the 20 meter band and 43 on the 40 meter band. Propagation wasn't great and most of my contacts were search & pounce mode, answering calls from other contest stations. I did call CQ a few times, and one of those was spotted by the reverse beacon network instantly and gave me 3 contacts in short succession. Operation in the contest was limited due to other things in the weekend so I fitted in the 6 hour category nicely. I did some other things on the radio on Sunday and somewhere in the afternoon I noticed a funny electronics smell and the output power from the amplifier had dropped. I found out the output voltage from the modified HP DPS-700 GB server power supply had dropped to about 10.6 volts. Time to find out whether this problem fixes itself or it's time to find another server power supply that will deliver over 40 ampere current at somewhere around 13 volt.Read the rest of I participated in the DL-DX RTTY Contest 2019
2019-07-05 I tested the randomness setup
Doing some more reading on haveged made me decide to test the actual randomness of my setup with haveged and randomsound which I created to fix the lack of entropy for dnssec signing operations so I booted the same testing virtual machine which can tap from the host /dev/random. I ran rngtest until it was time to shut down the laptop which was showing the output. The result:$ rngtest < /dev/random rngtest 2-unofficial-mt.14 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... ^Crngtest: bits received from input: 4999640 rngtest: FIPS 140-2 successes: 249 rngtest: FIPS 140-2 failures: 0 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 0 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=303.011; avg=543.701; max=5684.774)bits/s rngtest: FIPS tests speed: (min=43.251; avg=64.587; max=84.771)Mibits/s rngtest: Program run time: 9194254192 microsecondsI ratelimited the virtio-rng-pci driver from the host, so the test took a really long time. Given earlier tries with dnssec-signzone this is fast enough. No need to buy a hardware random generator, although they are way cool and it would be an idea to have a source of correctness (NTP) next to a source of randomness. Update: I ran rngtest on /dev/urandom and I had to ask for a really big load of blocks to get failures. The first test with 249 blocks gave the same result as above, just a lot higher bit rate. So now I know less about the correct randomness of my setup but at least the test shows that I can safely run dnssec-signzone which was the original idea.
2019-07-04 First tests with dnssec show a serious lack of entropy
I was looking at the options for implementing DNSSEC on the domains I have, and started doing this on a domain name that is just used for web redirects, so I won't break anything serious when I make an error. And I am looking at monitoring options at the same time. Looking for usable documentation I found DNSSEC signatures in BIND named - sidn.nl which shows and explains a lot of the options for doing this with bind9, including full automation. I want to take steps I understand, so I will start with careful minimal automation on a domain name that I can 'break'. Following that documentation I created a key-signing key (KSK) and a zone-signing key (ZSK). I used the /etc/bind/keys directory which is the standard location. The first dnssec-signzone action took 54 minutes. After waiting for a bit I started wondering what was happening and it turned out to be a problem with entropy: the signing uses a lot of data from /dev/random. I have the virtio-rng module loaded but the host wasn't making randomness available to the guest operating system. The host server does run randomsound to get more entropy since there is no hardware random number generator available. Documentation on how to 'forward' randomness from the host to the client virtual machine: Random number generator device - Domain XML format So I did some tests with a test virtual machine with a similar configuration. The results:
Installing haveged which gathers entropy from hardware processes fixes the whole problem. Now to implement the same settings for the virtual machine running the production nameserver and I'll be able to take the next step.
- Just software kernel rng in the virtual machine: 54 minutes.
- Offering virtio-rng randomness from the host from /dev/urandom running randomsound: less than 1 second.
- Offering virtio-rng randomness from the host from /dev/random running randomsound: 11 minutes 10 seconds.
- Offering virtio-rng randomness from the host from /dev/random running randomsound and haveged: less than 1 second.
2019-07-03 Unix printing isn't what it used to be
My wife bought a new inkjet printer because the previous one was failing. The new one is a HP deskjet 2630, and it has wifi support. Out of the box it was playing access-point on the busy 2.4 GHz band making it even more crowded so I asked her to disable the wifi. She used the printer nicely with the USB cable and asked me to look into putting it on the network so it can be in a different room and not in the way. Today I had a look into that. I hoped it could be a wifi client. Yes it can. The first two explanations on how to set that up started with 'using the windows HP software'. The third one had 'press and hold the wifi button to connect using wps'. So I enabled wps on the wifi network, did the wps mating and saw arpwatch note the new IPv4 addres in use. For a laugh I tried whether it has an IPP server running. It has. So adding it under linux should not be completely impossible. Search for 'linux hp deskjet 2630' and notice it needs the hplip package. Which is already installed in my recent Ubuntu. So I just opened the cups printer browser, saw the HP deskjet show up, selected that and printed a test page. Which came out correctly. Typing this took longer than the actual steps I took, and searching websites with explanations took most of the time. I'm still in the "what just happened?" stage, remembering long fights with printer drivers, network printing and losing everything at upgrades. Update: Adding the printer in Windows 10 was harder, we needed to use the HP software to add it which tried to sell us "HP instant ink" service before allowing the printer to be used in Windows.