Debian 12 and AllStarLink on 3040 Thin Client
Installing Debian 12 and AllStarLink on a Dell Wyse 3040 Thin Client machine
Building a DMR duplex hotspot
Wait, what? This was supposed to be a post about building a DMR hotspot from components purchased on Amazon! I made the purchases more than a week ago and then a couple of ice storms interrupted us in the Portland, Oregon area. One of the interruptions was delivery of these components, so while I have the lovely case by C4 Labs, it is an empty case, lacking the Raspberry Pi board and MMDVM duplex hat.
The Raspberry Pi board was shipped from the east coast but was, according to Amazon, damaged in shipment. The shipper returned it before it got halfway across the country. A few days ago, I ordered a new board from a different vendor and it is scheduled to arrive today. My cynical self says: well, we’ll see. The MMDVM hat is delayed, no reason given.
Yesterday morning, I assembled the case. It reminds me very much of the clean case my ClearNode lives in. This case is described as: Zebra DRPi-1S .096 Screen Case – Raspberry Pi 3 B+ and Duplex MMDVM (Black Ice). You can see the holes in the top of the case where the two antennas on the MMDVM hat will poke through.
Installing Debian 12 and ASL on a 3040
So to fill the time, I decided to embark on one of my back-burner projects: install Debian 12 and AllStarLink on a Dell Wyse 3040 Thin Client computer. Did that process go smoothly? Not completely!
Installing Debian 12
First 3040 unit did not work
Recently, I picked up a used Dell Wyse 3040 Thin Client unit from an eBay seller. Yesterday, I tried to boot it up for the first time and found a few problems. The area of the case near where the power supply is plugged in grew quite warm and the machine would not boot up, even though the main switch was getting power. Removing the case, I saw that the CMOS battery was dated 2017. In my experience, many of the units I’ve used with batteries that old have trouble booting because the battery is worn out, so the configuration doesn’t “hold” from boot to boot.
Spare 3040 thin client did work
What to do? I bought this particular unit because it had the internal wireless card installed. Digging through my bin of various 3040 units, I found a younger 3040 with wireless. That unit had a battery dated 2020 so after finding the correct power supply (12 VDC 2 amp output), I powered it up. It booted cleanly. The downside to this specific unit — and the reason it was in my bin of 3040s — is the LED illuminating the power switch is not working, making it hard to tell if the machine is on, off, booting, or sending an error via a sequence of flashes. Still, for this experiment involving loading Debian 12 onto a 3040, I decided it would do.
First installation with LXDE desktop
The first installation last night did not go well. I downloaded an ISO image of Debian 12 and used balenaEtcher to create a bootable image on a USB 2.0 thumbdrive. Inserting that drive into one of the front USB ports on the 3040, I powered up the machine and began pressing the F12 key. During bootup, a screen pops up asking if you want to enter the boot menu. That’s what the F12 key brings up. I chose to boot from the USB drive and soon Debian 12 was running on the 3040 from the USB thumbdrive.
I chose to proceed with a graphical install of Debian 12. The internal wireless card was found and I configured it to authenticate on my local area network. Toward the end of the installation sequence, I chose to try a different desktop environment, selecting LXDE. I had spent about 30 minutes reading various forum and Reddit posts about Debian desktops, looking for a fast, lightweight environment. LXDE seemed to fit the bill.
LXDE was not a good fit, however. Once installed, it would not automatically find the internal wireless card, nor would it retain the wireless settings when the 3040 was rebooted. I spent a few hours struggling to make it work and finally threw in the towel and went to bed.
Second installation with XFCE desktop
In previous versions of a Debian install on a 3040 unit, I had chosen the MATE Desktop Environment. That remains my “go to” desktop for Debian because it seems to always work they way I want it to. However, I was still wanting to try a different desktop that might use less system resources than MATE, so my fallback was to install XFCE.
I had loaded a lot of packages on the machine the night before and I wasn’t sure what might conflict or override XFCE, so I started over with a fresh install from the thumbdrive. This time, I selected XFCE. Immediately, I could tell that XFCE found the wireless card after rebooting and it retained the correct settings. Score 1 for Tom.
Packages installed
Secure connections: Tailscale
I use Tailscale extensively to connect my machines because Tailscale generally manages to navigate through whatever routers and firewalls happen to be between my often distant machines. Tailscale runs on many architectures and operating systems, including Linux. For my nodes, I generally disable key expiry which is somewhat less secure than rotating keys, but it makes it much more convenient to use saved credentials to negotiate a connection.
Headless operation: xrdp
I wanted to run the 3040 headless (without a monitor attached) so I installed xrdp:
xrdp provides a graphical login to remote machines using RDP (Microsoft Remote Desktop Protocol). xrdp accepts connections from variety of RDP clients: FreeRDP, rdesktop, NeutrinoRDP and Microsoft Remote Desktop Client (for Windows, macOS, iOS and Android).
Firewall: ufw
Connecting my Windows 11 Pro machine to the 3040 using Microsoft Remote Desktop Protocol (RDP) generally required passing traffic on port 3389, so I installed the ufw firewall on the 3040. Digital Ocean has a tutorial on setting up ufw on Ubuntu 20.04 that works perfectly in Debian, so I followed those instructions.
Remote connection dropping
OK, with the firewall configured properly and running, and xrdp up and running, I was ready to call up RDP on my Windows laptop and make the connection. Authentication went smoothly and I could see that I had connected to the 3040…and then the connection dropped. Puzzled, I tried this several times, finding that immediately upon authentication, the connection died.
Time for more internet searching. Eventually, I found the likely culprit: I had not told xrdp to use XFCE as the desktop environment. After editing the /etc/xrdp/startwm.sh file and rebooting, the remote window session stayed alive and I could see the XFCE desktop. Score 2 for Tom.
Searching: mlocate
One of the utilities that I find very useful on Linux is a command-line search function. For that, I use mlocate. It is a fast, lightweight solution. (Pro tip: if it doesn’t return anything when you search, run updatedb in the terminal window as root, then try your search again.)
How much is left?
Running df -h in the terminal yields this result:
There is plenty of space left for the AllStarLink installation. (By the way, to get this image, I took a screenshot on the Debian machine, then sent it using Tailscale directly to my laptop. That took only a moment. I use this utility a lot to move individual files between my computer in Olympia and my computers in Portland.)
I’m getting ahead of myself, but after installing AllStarLink as outlined below, the amount of space used on the largest partition went from 38% to 44%. There is still plenty of space on the drive.
Installing AllStarLink
Now that the Debian 12 instance is working the way I want, it’s time to install ASL. For this, I’m going to use the installation routine created by Allan Nathanson WA3WCO. This is how I changed my cloud-based node from Debian 10 to Debian 12 so I know it can work, but the question before me is: will it work with a 3040 thin client computer?
Install git
First up is to install git:
# install git
sudo apt update
sudo apt upgrade -y
sudo apt install -y gitThen pull in the repository
With that done, I clone Allan’s git repository (I suggest executing cd ~ to make sure you’re in your home directory first):
# download the repository
git clone https://github.com/Allan-N/ASL-Install.git Install AllStarLink
And then install AllStarLink:
# build and install AllStarLink
cd ASL-Install
./asl-install.shStep 1
Step 1, Setup, takes at least a couple of minutes. On the 3040, it takes a bit longer than that. Lots and lots of packages downloaded, unpacking, setting up, creating config files, enabling modules, creating symlinks, processing triggers, cloning packages…it’s a busy step that takes a while.
Step 2
Step 2, Clean before build, took far too long. Something went wrong. It’s possible I bonked the mouse by accident, since I had two keyboards and two mice on my desk. When I hit Ctrl+C to get out of the process, the installation menu came up and said “Clean before build” completed “OK.” But when in doubt, start over with step 1. Since everything is already done in step 1, that only took seconds. Then “Clean before build” ran for 15 seconds and returned OK. Good!
Step 3
Step 3, Build/install DAHDI, took about four minutes. (It’s a bit nerve-wracking to watch the screen and see nothing happening!)
Step 4
Step 4, Build/install Asterisk. A minute-and-a-half in, a message shows up next to the make command: Note: this make take a while. No kidding! The make process took slightly more than six minutes to complete!
Step 5
Step 5, Build/install AllStar, happened almost instantly.
Step 6
Step 6, Build/install Nodes-Diff, took a couple of seconds.
Step 7
Step 7, build/install Supermon, requires interaction: setting a username and a password, and verifying the password.
Step 8
Step 8, Build/install AllScan, took less than a minute.
Step 9
Step 9, Configure node settings, requires interaction as it is the AllStar node setup menu.
Testing and problems
Time to test! And…something was wrong. DAHDI is exiting with an error code. I ran
systemctl status dahdito understand what was going on.
I reached out to Allan who pointed me to a note by David Gleason NR9V regarding this problem. David found that sometimes the Secure Boot checkbox is set to Enabled in the BIOS for the 3040 device. (In mine, it is a boot choice called UEFI Firmware Settings, if I remember correctly.)
Secure Boot and DAHDI
When I rebooted and accessed those settings, that’s exactly what I found so I disabled Secure Boot and rebooted again. Then using Allan’s script, I ran steps 1, 2, and 3 again. That resolved my problem with DAHDI but I still had login failure when trying to log into Supermon and AllScan.
Login failure
The login failure problem was resolved by removing the password in the Supermon directory:
sudo rm /var/www/html/supermon/.htpasswdAfter that, I ran step 7 (Supermon build/install) in Allan’s script, allowing me to enter the initial Supermon login and password. While I was there, I also checked the node settings (step 9) and the web application settings (step 10).
Project complete
And that almost completed this project to put AllStarLink on a Dell Wyse 3040 thin client computer running Debian 12. All that remained was testing it.
I was able to connect to my cloud node 57945 instantly. After adding some port forward parameters in my router, I could access 588415 from 57945, again almost instantly.
Score 3 for Tom, with assists from Allan and David!
Project complete!
Hi, i have change 8gb emmc chip with 64gb. Installed Win 10 on it and it works fine. Chip is EMMC BGA-153 on Wyse 3040.