2021-01-20 Playing with DUDE-Star and actually hearing audio 1 week ago
I recently noticed the DUDE-Star software which allows access to D-Star, DMR, YSF, NXDN, P25, M17. For those who read here and got dazzled by these abbreviations: These are radio systems where voice data can be transported both via radio signals and via Internet data streams. In all of these systems there are ways to connect radio / network interfaces together to make contacts over longer distances possible. This software allows access to all these interfaces and will do the audio encoding/decoding so it will use a microphone and loudspeaker. I haven't had any luck in hearing D-Star audio yet which may be due to not being a registered D-Star user or due to not selecting busy reflectors (the computer systems that allow linked radios and networks to have the same audio data: an audio chatroom). I browsed around other systems and found busy talkgroups in YSF where I heard chatter in Dutch and English last night. It is nice to see software like this making it all accessible without investing in hardware. The codecs used have a serious influence on the audio quality, and I was warned the quality from DUDE-Star isn't as good as from the actual radios. From what I heard some of the digital audio modes the quality isn't very good (to leave lots of room for error correction).
2021-01-15 Fiber to the shed: testing the fiber optic transceivers 1 week ago
I wanted to get an idea whether the network over the fiber optic transceivers is reliable. So at the moment our dining room table looks like a network lab. For testing networks there is iperf. I found out the Raspberry Pi 3B+ can't keep up with 100 Mbit/second UDP packets, so I searched for a speed where the Pi performs ok. This turns out to be 30 mbit, at higher speeds there is packet loss. I also had to reduce packet size to avoid fragmentation which costs CPU. I use IPv6 because that's what I'm used to. It turned out later the maximum speed without loss is higher with IPv4 than with IPv6. Server on the raspberry pi:koos@raspberrypi:~ $ iperf --version iperf version 2.0.9 (1 June 2016) pthreads koos@raspberrypi:~ $ iperf -s -V -u ------------------------------------------------------------ Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 160 KByte (default) ------------------------------------------------------------Test without fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - raspberry pikoos@wozniak:~$ iperf --version iperf version 2.0.9 (1 June 2016) pthreads koos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c .. ------------------------------------------------------------ Client connecting to .., UDP port 5001 Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ .. [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec [ 3] Sent 321430 datagrams [ 3] Server Report: [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec 0.004 ms 0/321430 (0%)Test with fiber optic transceivers in the path. Layer 2 route: virtual machine - host machine - utp - network switch - utp - network switch - utp - fiber optic transceiver - fiber - fiber optic transceiver - utp - raspberry pikoos@wozniak:~$ iperf -V -u -b30M -i 10 -t 120 -M 10 -l 1400 -c .. ------------------------------------------------------------ Client connecting to .., UDP port 5001 Sending 1400 byte datagrams, IPG target: 373.33 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec [ 3] Sent 321430 datagrams [ 3] Server Report: [ 3] 0.0-120.0 sec 429 MBytes 30.0 Mbits/sec 0.007 ms 0/321430 (0%)Trying with IPv4 shows that packet loss starts to occur above 45 mbit. This is an interesting difference. But the important conclusion is that there is no packet loss over the fiber path. There may be a bit more latency, but that's not a surprise. As a last test I looked at purely ping traffic using IPv6. Without fiber in the path:koos@wozniak:~$ ping -c 100 -i 0.2 -q .. PING ..(.. (2001:xxxx)) 56 data bytes --- .. ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20192ms rtt min/avg/max/mdev = 0.567/0.680/0.866/0.063 msWith fiber in the path:koos@wozniak:~$ ping -c 100 -i 0.2 -q .. PING ..(.. (2001:xxxx)) 56 data bytes --- .. ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 20191ms rtt min/avg/max/mdev = 0.625/0.738/0.828/0.046 msThis also shows a bit more latency over fiber. The extra latency is probably due to the fiber optic transceivers containing a network switch.
2020-12-23 A bluetooth speaker that is also a serial port 1 month ago
I acquired a Blaupunkt BLP6100 Bluetooth speaker. Which turns out to support the following services via bluetooth:
That last one I did not expect. I have tried opening the port with minicom and it will say carrier detect but sofar trying to wake it at 115200 or 9600 hasn't resulted in anything. As a linux audio device it works fine. Or as a bluetooth speaker for my phone so I can listen to podcasts while walking around at home. But the serial port makes me wonder!
- Headset (audio for phone calls)
- Handsfree operation (use buttons to accept, hangup or reject calls)
- Audio sink (the main function of a bluetooth speaker)
- Serial port
2020-12-13 Makefile logic not working perfectly 1 month ago
I noticed the certificate for idefix.net was expired according to my webbrowser. I dug up the reason and found out the scripts to maintain the ocsp files managed to confuse the Makefile to keep the haproxy certificates updated. The ocsp responses have more updates than the certificates, but a certificate update needs to be processed anyway. So I updated the Makefile in the previous post. The dependency is now certificate-stamp depends on installed certificates, installed certificates depend on copied certificates. And installing the certificate also updates the ocsp response.
2020-12-05 Playing with a fully programmable LED strip 1 month ago
At work there is a sort-of competition for the best christmas decorations in the office. At the end of last year I considered doing something with programmable LEDs to 'participate' in this competition in 2020. This year turned out somewhat different, but slowly my son is also somewhat interested in electronics, soldering and making the computer do something. So I set out to find fully programmable LED strips. I found a good comparison of LED strips in a Youtube video: LED Strips, what's the difference? WS2811, WS2812B, 2812Eco, WS2813, WS2815, SK6812, SK9822. which compares the several available types and their pros and cons. After viewing this video and for my limited experiment I thought the WS2812B based LED strip would be the best choice. The next hurdle was controlling it and I found Connect and Control WS2812 RGB LED Strips via Raspberry Pi which has pointers to the right code. I am not following the advice on that page about working with mains power cables. That looks dangerous. I ordered a WS2812B based LED strip and a matching power supply for 5V 40Watt from a Dutch webshop and got it in a few days later. I was amused by the warning the webshop gave that a LED strip like this is for advanced users only because you have to add a controlling device and do all the programming. That is exactly what I intended to do! Programming is in Python3, and I haven't written any Python code before. But with a lot of google searches and looking at samples I got the idea right. I now have the LED strip blinking in exactly the patterns I want, including a nice pattern for a christmas tree. And it blinks 'MERRY CHRISTMAS' in morse code, because why not!
2020-12-04 Using a snapshot for an upgrade so I can roll back 1 month ago
This evening I upgraded the production webserver from Devuan ascii to Devuan beowulf and to have the option available to roll back everything I created a snapshot and left that running until I was satisfied with the new configuration and everything worked. The steps were simple, found via Commit or revert a Linux LVM snapshot? - serverfault: Before starting the upgrade, create a snapshot:# lvcreate -L 10G -s -n turing_upgrade /dev/conway_ssd/turing_rootDo all the upgrade stuff, reboot, make sure everything works again. The usage of the snapshot went up to 22.38 percent:# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert turing_root conway_ssd owi-aos--- 30.00g turing_upgrade conway_ssd swi-a-s--- 10.00g turing_root 13.17After everything worked, remove the snapshot:# lvremove /dev/conway_ssd/turing_upgrade
2020-10-26 Speeding up TLS connections for Apache with OCSP 3 months ago
I have one Apache server exposed to the outside world for IPv6 clients (because of a history in hostnames going back to the 20th century). So after enabling OCSP for haproxy I decided to have a look at OCSP stapling for Apache 2.4. That's even easier than haproxy since Apache 2.4 will fetch the ocsp data itself. I followed Apache 2.4 SSL/TLS Strong Encryption: How-To OCSP Stapling and it works. So now the current score at the Qualys SSL server test for koos.idefix.net is A+ both via IPv4 and IPv6.
2020-10-21 Upgrading Devuan linux from ascii to beowulf 3 months ago
I am upgrading Devuan linux installations from ascii to beowulf to get newer packages and continued security updates. There is only one package where I really want a newer version: openssl, so I can start using TLSv1.3. This upgrade is just as simple as the upgrade from Devuan jessie to ascii three years ago. Just change the release name version and use apt update and apt dist-upgrade commands. Today I did the development webserver and apache didn't start afterwards. I found out I need to enable php7.3 by hand, in the previous configuration php7.0 was enabled. A thing to keep in mind when upgrading the production webserver.
2020-10-14 Speeding up TLS connections for haproxy with OCSP 3 months ago
On my to-do list was the idea to look at OCSP stapling for haproxy. OCSP is Online Certificate Status Protocol which wraps the revocation status of a certificate in the certificate negotiation. This speeds up the TLS setup a bit since the client doesn't have to make an extra connection to the OCSP responder of the certificate issuer and it adds a bit of privacy because the certificate issuer doesn't see which client requests the status of a certificate. Finding the right way to get the ocsp updates to haproxy was a bit of work, eventually made some modifications to the script in HAProxy OCSP stapling. I also used the remarks in OCSP stapling with HAProxy. From pitfall to euphoria because I saw the "OCSP single response: Certificate ID does not match any certificate or issuer" error message. I had to restart haproxy first to make it enable ocsp processing (because now each server certificate has its own .ocsp file) and now it accepts the "set ssl ocsp-response" command. Update: I'm not completely happy yet: after a certificate was renewed haproxy complained about the .ocsp file being out of date. Which is fully correct, since that .ocsp file was about a previous version of the certificate. This needs more work. Ideally I would check the validity of the .ocsp file before deciding to renew it. And fetch the new ocsp data before reloading a renewed certificate. Anyway, the 'TLS setup' part of connecting to sites like idefix.net goes from 20-21 milliseconds to 5-8 milliseconds. Not a blinding fast improvement but all bits help and I like to have optimal security and privacy.Read the rest of Speeding up TLS connections for haproxy with OCSP
2020-10-10 The igate is igating 3 months agoItems with tag linux before 2020-10-10
I dug into 'how to build code for the ESP32' and found Installing ESP32 Add-on in Arduino IDE (Windows, MacOS X, Linux) and since I have the Arduino IDE working enough for the previous project with a programmable microcontroller: the nanoKeyer morse keyer I did the steps to add ESP32 support. I had to find the right settings for the specific ESP32 chip and since it is labeled "ESP-WROOM-32" I ended up at ESP-WROOM-32: Uploading a program with Arduino IDE and used the settings 'Board: FireBeetle-ESP32', 'Flash Frequency: 80 MHz', 'Upload Speed: 921600'. The sourcefile to compile and upload to the ESP32 in the pi4raz igate is pa2rdk/APRS_IGate/APRS_IGate.ino. I changed the definition of struct StoreStruct for a bigger wifi password (64 chars) and noticed that after uploading the updated code the last parts of the StoreStruct got mangled. I changed to #define EEPROM_SIZE 174 which seems to fix this. I will admit to doing a bit of cargo-culting here: just following some google results and fiddling a bit until it works, with limited idea what I'm actually doing and what the effect of my changes is. The kind of weird results I got after growing the wifi password buffer suggested clearly to me that I was looking at some sort of buffer overflow, so I started looking for buffer sizes. But the igate is now talking to the APRS network. First results visible at PE4KH-10 tracked on aprs.fi.
pi4raz igate running showing packet