Recording FM radio with RetroPie

Note: This works on just about any Linux install. I just wanted the excuse to set up a RetroPie.

Installing and Configuring RetroPie

RetroPie recommends at least a Pi 3. I went with a Pi 4 8GB in order to future proof my setup. Since I plan on leaving it constantly on and hooked up to my home theater I wanted a passively cooled case. The Flirc Pi 4 case fit my needs and looks good as well. Installing the Pi in the case was easy and straightforward. Attach the thermal pad, place the Pi in the case and screw it together. That’s it.

Installing RetroPie is just as easy. Download the RetroPie image, extract it and install it onto a MicroSD card. By default the pi runs samba which allows you to copy your roms over the network to the pi. This is great for ease of use but I don’t want to have to worry about losing my roms if the MicroSD card fails. Instead we’ll be serving the roms over the network.

I originally configured my rom share on my TrueNAS (formerly FreeNAS) server for NFS. That way I could set it to read only with mapall permissions for easy connection. However, NFS doesn’t use a set port and I have my home theater firewalled off because it’s connected via Powerline. NFS can be configured to run on a specific port but that has to happen per client and it’s much easier to just switch to SMB.

Once you configure the network share and open the ports then you just need to set up RetroPie to use the share. First you need to enable SSH on the RetroPie. Then you can copy the existing folder structure from the /home/pi directory to the network share. This allows it to properly pick up the roms. Once that’s done you need to run raspi-config and tell it to wait for the network to boot. After that edit your autostart.sh and add the following line, edited to your share settings.

sudo mount -t cifs -o username=something,password=something,nounix,noserverinouid=userid,forceuid,gid=usergroup,forcegid //REMOTEHOST/path/to/roms /home/pi/RetroPie/roms

I created a user just for the pi on the NAS so that I don’t have to worry about someone getting access to the pi and seeing the password. If they do they only have readonly rom access and can’t hurt anything. If you elect to save games on the NAS as well, I recommend making a separate share owned by the same user which has read and write permissions. I did have to add the uid and gid options in order for the permissions to properly line up.

One thing to note is that you will need to enable write permissions for the roms share in order to install new emulators. Once they’re installed you can change the share back to read only.

Recording FM Radio

Now that RetroPie is all configured and running we move on to recording the radio. We’ll be using a rtl usb dongle to receive the radio signals. Once the radio show has been recorded we’ll then email to ourselves.

First we need to install rtl in order to receive the signal and ffmpeg to convert it to an mp3. We also need ssmtp to email it and mpack to include the mp3 as an attachment.

sudo apt install rtl-sdr ffmpeg mpack ssmtp

Once you’ve installed all of those packages we need to configure ssmtp to know what smtp server to use. Open up /etc/ssmtp/ssmtp.conf and add the following lines. Edit for your email and server.

root=your_email@gmail.com
mailhub=smtp.gmail.com:465
FromLineOverride=YES
AuthUser=your_email@gmail.com
AuthPass=your_password
UseTLS=YES

If you are not receiving emails you can add Debug=YES as well and then look in /var/log/syslog to see what the problem is.

Now create a radio.sh file in the pi home directory and add the following lines.

now=date
rtl_fm -M wbfm -f RADIO_FREQUENCY | ffmpeg -f s16le -ac 1 -ar 32k -i pipe:0 -acodec libmp3lame -ab 32k -f mp3 -y -t 01:00:00 radio.mp3
mpack -s "SHOW_TITLE ${now}" radio.mp3 EMAIL_ADDRESS

The first line saves the current date. If you just used date in the last line the time would be the end of the show instead of the beginning. Originally I was going to use timeout to set the recording time and provide a file for ffmpeg to convert. But ffmpeg accepts a -t option which is the length of the recording. Once that is reached it will automatically stop rtl_fm. Make sure you adjust it appropriately. Also set RADIO_FREQUENCY to the correct station. On the last line configure the title for your email subject and provide the appropriate email address to recieve the recording. Keep in mind that the sender of the email will be whatever email address you have configured in your ssmtp.conf file.

Lastly, you need to configure the recording script to run at the appropriate time. As the regular pi user run the following.

crontab -e

This will bring you into the crontab editor. Add the following line to the end of the file.

0 HOUR * * WEEKDAY /home/pi/radio.sh

If the recording is a weekly show that starts on the hour simply replace the HOUR and WEEKDAY values with the appropriate numbers. Make sure you go through the raspi-config and set the appropriate date, time and time zone. Additionally, you will have to reboot once you’ve set the time zone as it doesn’t take effect until then. I found that out the hard way.

You can test the radio script separately if you don’t want to wait for the appropriate time. Simply run the following command.

/home/pi/radio.sh

This will record whatever happens to be on the radio at the moment but will let you know everything is working.

If you want to record multiple different shows then you can configure the radio.sh to accept variables and call it multiple times with the appropriate settings from the crontab, but I leave that as an exercise for the reader.

DNS Security and Adblock with OPNSense, Part 2

ADBLOCKING

Now that we’ve secured our DNS, we can move on to improving the quality of our experience on the internet by configuring DNS ad blocking. With the 20.7 version of OPNSense it’s quite easy. Simply go to Services -> Unbound DNS -> Blacklist. Click Enable and select one or more items from the DNSBL drop down. Or if you prefer, paste the URLs of your preferred list in the URLs field. I prefer the Stephen Black list as it is composed of multiple lists and is also the default list for the Pi Hole. Click Save and you’re done.

ADBLOCK LIST UPDATE

Now that we’ve configured the block list, we want to make sure that it updates when new domains are found. This doesn’t happen automatically when you configure it but is easy to add. Go to System -> Settings -> Cron. Once there you’ll click on the + button and create a new job. The default options are fine and will update the block list daily at midnight. Select “Download Unbound DNSBLs and restart” from the Command list and provide a descriptive comment in the Description field. There may be two items with the same name in the Command field. Either one should work but you should check back after each update to ensure it’s correctly configured once the bug is fixed. If you wish to investigate further, you will want to look at /var/cron/tabs/nobody and you should see /usr/local/sbin/configctl unbound dnsbl

DNS LOCKDOWN

Now that we’ve configured our DNS to block malware and ads, we’re all set, right? Because anyone on the network can configure their device to use a different DNS and they will completely bypass all of the work that we’ve done. Roku, for example, comes configured to use Google DNS in addition to that provided by DHCP. Firefox defaults to a DoH setup.

Now we have two choices. We can either redirect all DNS queries to our server or we can simply block all queries except for our server. Since the server hands out a DNS configuration with every DHCP lease, I choose to block the queries. It also makes for easier troubleshooting as you don’t query one server but resolve a different one.

In order to block the servers you’ll need to go to Firewall -> Rules -> Floating. This ensures that you’ll block DNS on all interfaces. Click on the Add button and we’ll configure the rule as follows. Select Block as the Action. Select all appropriate interfaces. Select IPv4+IPv6 for your TCP/IP Version.darkness Select TCP/UDP as the Protocol. Select Invert and This Firewall for your Destination. The Destination port is DNS. Provide an appropriate description and click Save. Once that’s done, click on the Clone button for the rule you just made. Change the Port to 853 and give it an appropriate description. Then click on Apply Changes.

You can easily test the standard DNS block by using nslookup like we tested the original Quad9 setup. However, in order to test the DoT block you will need to install kdig or a similar tool. It is part of the knot-dnsutils package so you will need to install that. Then you can make a DoT call to determine if you are able to connect.

DNS OVER HTTPS LOCKDOWN

Do to the way DoH works it’s not as simple to block. Since it runs over HTTPS you can’t just block 443 as that will block all of the internet. As far as I can tell there isn’t a list of DoH servers available so you will have to handle them manually and determine yourself if it’s worth the effort.

Most DoH connections use standard DNS to bootstrap the connection in order to know which DoH server to use. For example, they will query dns.google.com. Obviously, you can add dns.google.com and other DoH domains to your DNS domain block list and that will cover most cases. However, some DoH servers will accept connections via IP. Which means that in order to stop those you will need to completely block all traffic to the IP.

I’m still contemplating how I want to handle DoH, so please pass along any ideas or suggestions you may have.

DNS Security and Adblock with OPNSense, Part 1

If you’re not familiar with DNS, you can think of it as the contact list in your phone. You don’t remember anyone’s phone numbers. You just know their name and have the number stored in their contact entry. DNS is similar in that you just need to know the domain of a website and your computer will lookup the IP address of the site. Here is a primer that goes into a bit more detail.

With OPNSense, you can run a DNS resolver called Unbound. This will validate and cache DNS queries for your local network. It can improve your network performance but it’s usually not noticeable as your browser and other software generally have their own DNS cache. The real benefit of Unbound is that we can modify the DNS for the entire network to provide more security, privacy, and piece of mind.

Continue reading