predictable. This is super-annoying to me, maybe it’s the reverse logic of the command.
I want static IP for this particular RPi3B+ which is fully standalone, no dhcp servers, no nada. After floundering around for hours, attempting to remember what the “magic” thing was I needed to do to get the dhcpcd.conf file to allow static IP for eth0, and constantly getting new dhcp address leases, I found some hints in the enable predictable network names area.
Since jessie or so, it appears that raspbian has had a “feature” called predictable network names in the raspi-config setup file. Maybe I understood the logic at one time, since I have had success in the past with setting static ip addresses.
Anyway, in raspi-config, under network options, the N3 Network interface names function has had an “Enable/Disable predictable network interface names” feature. To me, predictable means I know ahead of time and for all time what the network interface is called, like eth0 or wlan0, or whatever. I can predict that, even after some tequila.
But NO, predictable means that the first wired network interface is now called “enx”&[hardware network device interface mac address] instead of good ol’ eth0, which is so much less predictable…
Ah, you say, “enx”&[hardware network device interface mac address] is completely predictable, and, to boot, unique to the device. Yeay! I get that. But, in the default dhcpcd.conf file, there’s a commented area that sez that all you need to do to enable static ip is to uncomment those lines and voila! you’ll have a static ip on the next reboot. However, those sample lines use the eth0 convention, not the more better “enx”&[hardware network device interface mac address], so it’s absolutely misleading.
After lots of cussing and kicking, I finally stumbled on this thread and the post by Dougie Lawson, which kindled a (dim) light in my head and made me attack the enable/disable predictable network interface names feature.
So, now I know that I can make completely customized dhcpcd.conf files by using the handy-dandy “enable” predictable network interface names function, but I now will need to remember to disable that feature whenever I want to follow the sample setup within dhcpcd.conf.
I get these on an irregular basis, but they’re darkly entertaining.
Hello! I am a hacker who has access to your operating system. I also have full access to your account. I’ve been watching you for a few months now. The fact is that you were infected with malware through an adult site that you visited. If you are not familiar with this, I will explain. Trojan Virus gives me full access and control over a computer or other device. This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it. I also have access to all your contacts and all your correspondence. Why your antivirus did not detect malware? Answer: My malware uses the driver, I update its signatures every 4 hours so that your antivirus is silent. I made a video showing how you satisfy yourself in the left half of the screen, and in the right half you see the video that you watched. With one click of the mouse, I can send this video to all your emails and contacts on social networks. I can also post access to all your e-mail correspondence and messengers that you use. If you want to prevent this, transfer the amount of $500 to my bitcoin address (if you do not know how to do this, write to Google: “Buy Bitcoin”). My bitcoin address (BTC Wallet) is: 34C7xtdCzV8vxxmP5kmHnttHe62Br2NmGW After receiving the payment, I will delete the video and you will never hear me again. I give you 50 hours (more than 2 days) to pay. I have a notice reading this letter, and the timer will work when you see this letter. Filing a complaint somewhere does not make sense because this email cannot be tracked like my bitcoin address. I do not make any mistakes. If I find that you have shared this message with someone else, the video will be immediately distributed. Best regards!
I like the “Best regards!” flourish.
I imagine since I’ve “shared the message” and of course, haven’t paid the ransom, that my world as I know it will come to a grinding halt in even less than 50 hours.
I’ve been using Teamviewer for years now to remotely pilot my half-dozen or so Windows boxes that are at remote sites, mountaintops, and other places where I want to do radio monitoring, control amateur radio links, run weather stations, whatever.
About 18 months ago I started getting a regular amount of “COMMERCIAL ACTIVITY SUSPECTED” notices when I’d connect to one of my sites. Repeated missives to Teamviewer would sometimes get me back my connectivity, but it’d be just a few months before I’d be a suspect again.
Now, with my starting to really take advantage of Raspberry Pis everywhere, I’m planning on building out a VPN system where the router at home will be the server and the RPis in the field will be clients. I’m sure I can get this to work, but I don’t know (yet) too much about the intricacies (or even basics) of VPN connections.
I started working on this idea this past week but with the failure once again of the Windows box on White Tank and the subsequent loss of monitoring audio, replacing that became the higher priority. Now that that RPi is installed and working, it’s time to turn back to the VPN thing.
Should be cool and allow me to have all my remote radios on a private network that’s an extension of my home net.
Hopefully you’ve been able to get darkice running and throwing your favorite railroad voice radio channel to railroadradio.net.
In terms of how much overhead it costs to run darkice, at least on this RPi2B it’s about 12% on average. I also have gpsd running on the RPi so that I can get good time no matter what’s going on with the network connection. This is not necessary by any means, but for me it’s exercise.
I’m using for the scanner radio an old RS PRO2052 scanner (Figure 1). I have a number of them in various stages of decay, but they were a bargain way back when they were liquidating them. These have a serial port connection that, if configured and queried properly, will give the radio frequency/scanner memory channel that the scanner is on at that moment; it’d be cool if I got the tap working so that I could send a tag to railroadradio telling the listeners what freq the radio is stopped on during a transmission.
Tomorrow I’ll take this RPi up to the radio site atop the White Tank Mountains west of PHX and swap out the Windows box, hopefully ridding me forever of the need to care and feed a Windows box on that remote site.
The code below is the contents of the darkice.service file. Once you’ve created this file (it didn’t exist before you do this), you’re that much closer to having a darkice auto-run system.
[Unit] Description=darkice-autostart After=network.target #supposed to prevent darkice.service from starting before network is up and running
[Service] ExecStart=/usr/bin/darkice -c darkice1.cfg #need the -c since config file is not where exec file is, note the darkice#.cfg
WorkingDirectory=/etc #this is where the darkice config file resides, i suppose it could be anywhere, like /home/pi
StandardOutput=inherit StandardError=inherit Restart=always #I’m not sure how or if this works, but need to figure that out RestartSec=3 #necessary because default is 100ms, and something makes it fail if not stretched out Restart=on-failure #not sure this is necessary but belt-and-suspenders, doncha know. User=pi #default user
Save the above file contents as darkice.service. Then move this file to the folder /etc/systemd/system with
sudo mv /etc/darkice.service /etc/systemd/system/
Now, run the command
sudo systemctl enable darkice.service
Once you’re done with that, it’s time to reboot.
At least on my RPi, it takes about 23 seconds from boot to the point it connects to railroadradio.net. PDC.
I just built a brand-new out of the package sdcard using the instructions I posted earlier, and except for some fat-fingering, it all worked.
Now it’s time to mess with systemd and get it to auto-start darkice when the RPi is rebooted or after power’s been reapplied after an outage.
This site is your friend for this work. Read it repeatedly.
We want the RPi upon power-up to auto-start darkice. If we can get that to work, then even when your 3-hour-drive remote monitoring site dies from lack of power, when and if the power returns darkice will come up again, and attempt to connect to railroadradio.net.
darkice is pretty simple, at least in terms of the basics. Invoking “darkice” at the command line is easy – but darkice needs to know where the darkice.cfg file is. As you may remember, in the last post I’d left the modified darkice.cfg file in the /etc folder, which is fine for me. The full command, to invoke darkice, is “darkice -c /etc/darkice1.cfg”.
Easy peasy, right? (Apologies to Richard Small for stealing his line)
I found it much harder to get systemd (not local.rc, or some script workaround) to invoke darkice reliably. And that’s because “that’s supposed to be the way it’s done in ‘modern’ Raspbian, so it seemed high time to learn it.
I want darkice to run as a system service, so the command line doesn’t get locked up running one app. I studied other xxx.service files on the web, and figured out what might be needed here. And here is it!
Make sure the following file is saved in /etc/systemd/system as darkice.service
When it’s saved there, you’ll need to remind systemd that it’s there, so next do
sudo systemctl enable darkice.service
While I don’t really know what this is doing, I imagine it’s setting a flag in systemd, or something more complicated, that lets systemd know that darkice.service is there and that it’s part of systemd.
Here’s the actual file contents for darkice.service
While a lot of people use Broadcastify or RadioReference for their audio streams, I’ve had a couple of streams on (or not on) RailroadRadio.net for a long time. Sadly, all these streams originate from remotely located WIndows boxes, running the fantastic RadioFeed streaming client.
Why sadly? Because Windows boxes at remote sites (like 3 hours-drive time away) are troublesome. I don’t need 99% of what Windows brings, and it pulls a lot of electric power just to run a simple app.
I have been employing Raspberry Pis for so many of my interests, and learning more about *nix than I’d ever known (or thought I’d want to know). What I’ve found is a wonderful, powerful language, capable of making incredible things happen. The depth of knowledge that’s in *nix today is as rich as any modern spoken language; there’s so much to learn that digging into any one command shows the tens/hundreds/thousands of *nix engineers, developers, and hackers who each spent countless hours making this language (and its variants) become the basis of modern technology.
Enough of the praise. (But it’s f*’king cool, and I constantly feel like I get a dullard’s glimpse into the minds and personalities of engineers, computer scientists, and old-school hackers back in the 60’s who started all of this.)
First, shout-outs to Martin Higgins and to Jim Groenke. I don’t know Martin, and he don’t know me, but his post started me on this journey. Oh, and to Ray Lewis, a serviceman at Luke AFB nearby who has been extremely generous with cash donations to me to get and keep the White Tank monitoring site going. It’s nice to know somebody’s enjoying the data!
Alrighty. How to install and get Railroadradio.net streaming device running on an RPi. This is not for the faint-of-heart. It’s a good idea to know a bit about RPis and Raspbian, or to have Google at your side, their evil dark heart notwithstanding. Take your meds before starting.
Start with a fresh RPi. I have RPi 3B+ and 3B units, but for this one I happened to find an unused RPi2B, which I was about to turn into a VPN server, so I don’t know (yet) whether there’s any difference between the different hardware platforms for this little project.
Download the most recent Raspbian image; for this project I used the desktop version, but without all the apps. Burn that to an appropriate microSD card. Before undocking that sdcard, write a zero-length file called ssh to the root directory. Literally, create a file that has only a name “ssh”, no content, no suffix, nada. RPi will see that file and think you’ve enabled ssh already, so no need for monitors, keyboards, etc.
Move the sdcard to the RPi, apply power, make sure you know the RPi local network by checking your router’s DHCP tables.
I use PuTTY to talk CLI to the RPi. Do an ssh session to the RPi, at the network address derived from 3 above.
Username and password, then you’re at command line in home/pi/ directory.
If you haven’t yet, run passwd and create a good password, length 10 characters min, and use numbers, upper/lower case alphas, and a symbol or two. Yeah, it’s harder to remember, but once this thing goes remote, you don’t want it easily hijacked.
Do run sudo apt-get update and sudo apt-get upgrade. Make sure you’re at the most current build.
There’s several things needed to make the RPi into an audio streamer. A USB soundcard, setting up alsamixer, downloading, installing, and configuring darkice. Use this link for instructions: RadioReference Broadcastify Build. You’ll use Method 1, for me I stopped at “Enable the feed to start broadcasting at boot”, partially because I couldn’t get the subsequent instructions to work, but also as we’ll be modifying the .cfg file so that it works for Shoutcast, which is what RailroadRadio uses.
So, about now you should have an RPi running the most recent version of Raspbian (this build used Buster and updates/upgrades current to about 25 Aug 2019), a nifty USB sound card (my dongle cost $6), and might look vaguely like this one.
It should behave like any old RPi, but until we get the darkice config updated, and make darkice a service that auto-starts when the RPi is rebooted (which can happen when the remote location loses power or the cat chews through the power cord), we’re not ready to stream!
The instructions in 9) above put the darkice1.cfg file in the /etc directory. That’s fine, but it can be somewhere else if you prefer.
Log in, go to the /etc directory, and sudo nano darkice1.cfg to open the file. One should see something vaguely like the following (which has already been modified):
# darkice configuration file
# Copy this configuration file to /etc/darkice#.cfg
duration = 0 # 0 means forever
bufferSecs = 10
reconnect = yes
# this can be used if darkice is the sole user of audio capture device:
# Import notes for the “device =” setting on this preconfigured image
# Most configurations with one additional USB sound card added will
# use “plughw:1,0” as the setting for the device.
# When adding 2 or more USB sound cards, your first USB sound card will
# start at plughw:0,0 and work it’s way up n+1 (hw:1,0 hw:2,0 hw:3,0 and so on
# If adding just a single USB sound card for a broadcast, simply use the following:
# device = plughw:1,0
# You can verify card and device numbers by running the arecord -l command
device = plughw:1,0 # hw:0,0 then hw:1,0 then hw:2,0 etc
sampleRate = 44100 # don’t know if there’s any value to changing this
bitsPerSample = 16 # again, i tinkered with this but only got silence or chipmunks
channel = 1 # 1 for mono, 2 for stereo
[shoutcast-0] # this is critical difference from the default .cfg file, which had “icecast0-1” here.
bitrateMode = cbr
format = mp3
bitrate = 24 # this is the one that defines the over-the-wire data rate, to me 16 sounds as good as 24
quality = 0.5 # don’t notice much difference between 0.1 and 0.9
channel = 1
lowpass = 4000 #important to get rid of the HF hiss, tried different values but 4000 sounds good
server = railaudio2.railroadradio.net # Your Master Server Name
port = nnnn # whatever inbound port (1 less than the public connect port) has been assigned at railroad radio for the stream
password = yourfeedpwhere # Your Feed Password
name = YourFeedName # Your Feed Name
url = www.railroadradio.net
# URL related to the stream
genre = Rail Scanner # genre of the stream
public = no # advertise this stream?
irc = # IRC info related to the stream
aim = # AIM info related to the stream
icq = # ICQ info related to the stream
You should notice that there are many similarities, but a few significant differences, between the default Broadcastify darkice.cfg file and this one. RailroadRadio demands either 16 or 24 kbps bitrate, even though to my deaf ears 8 kbps sounds acceptable.
Before you modify the .cfg file, save a backup by
sudo cp darkice1.cfg darkice1.cfg.bak
Now, you’ve got the original in case something really gets messed up. Once you’ve edited darkice1.cfg file to have the parameters above, save it. And assuming you already had a RailroadRadio stream port and password assigned, and entered that in the config file, and have a sound source attached to the USB sound card dongle, typing
sudo darkice -c /etc/darkice1.cfg
should get you connected and streaming to the RailroadRadio.net server and you should shortly hear your audio stream coming back at you. Now’s a good time to take a break and savor the success…
Next, I’ll describe how to get systemd to make darkice auto-start on power-up.