Problems when replacing the Wi-Fi adapter

Hi,

Once again, I’m coming to you with what might be a trivial problem that I haven’t been able to solve properly yet.

Unfortunately, there’s no one in my personal circle who knows Linux.

That’s why, as always, I’m turning to this forum with confidence.

Enough with the preamble.

Ultimately, it’s about two RPi 4s that are connected to the network via Wi-Fi for space-related reasons. For the most part, that works well.

But now I’d like to improve or optimize the Wi-Fi connection by using better Wi-Fi adapters.

The old Wi-Fi adapters have a Realtek chip, while the new ones have a MediaTek chip.

In my naivety, I thought it would be plug-and-play—just take out the old ones, put in the new ones, and that’s it.

Unfortunately, that’s not the case.

So far, Wi-Fi0 has been set up.

I “experimented” a bit to set up Wi-Fi 1, but that went wrong.

In the end, out of desperation, I temporarily removed a Pi 4 and connected it via LAN, but that didn’t really work either—the network was unstable and kept dropping out.

Now I’ve wiped the system; I still have the original on the SD card (a copy from about 3 days ago).

My question:

With DietPi OS running in the latest version and using ONLY a Wi-Fi connection as Wi-Fi0, what’s the best way to swap out the Wi-Fi adapter for a different one?

If necessary, I can also physically remove the Pi 4 and perform the setup via LAN.

I hope I’ve managed to explain my plan in a way that makes sense.

Thank you in advance for your time!

Edit: I forgot to mention that I’ve at least noticed that the kernel supports and recognizes the MediaTek adapter without any additional drivers.

Have you enabled the onboard Wi-Fi? Or are you only using external adapters? The RPi4 does come with its own Wi-Fi, after all.

Is your system running right now? If so, which adapter are you using? The onboard one? An older external one? If the system is running, just plug in the new adapter and restart the system. Then you can check to see if the system recognizes the new adapter.

Generally, the RPi will assign “wlan0” to the Wi-Fi adapter that becomes available first. The second adapter will then be assigned “wlan1.” It all depends on how quickly the kernel can initialize the individual adapters. As a rule, the internal adapter should be the fastest (if enabled).

Of course, it would also be advantageous to perform the configuration via LAN. This avoids the problem of potentially not having Wi-Fi access if something goes wrong during configuration.

I’m going to try connecting the Pi via LAN again for now. Then, as before, both the LAN and the WLan0 connections should be active. When I connect the new adapter—which will become WLan1—how can I configure it properly so that WLan1 is and remains the primary connection, or becomes WLan0 when I remove the old adapter?

I’m only doing this whole project to make the Wi-Fi connection a bit more stable and to get higher data throughput.

Realtek components aren’t exactly known for good performance. Finding adapters suitable for the Pi wasn’t that easy, since I didn’t want to have to install any additional firmware drivers.

That’s why I settled on the BrosTrend WiFi 6E AXE3000 Wi-Fi stick, which is supposed to be plug-and-play for the Raspberry Pi OS (DietPi/Debian), among other things.

It seems to be, but I just can’t get the switch from WLan0 to WLan1 to work.

I don’t know how important this is, but ZeroTier is also installed on both of the relevant Pi devices for remote access.

One Pi is purely an ADSB feeder running on the ADSB.im base—but with DietPi OS—while the other Pi is a Wingbits system running on DietPi OS.

If you’re connected via LAN, simply remove the old Wi-Fi adapter and plug in the new one. After a reboot, the new adapter should be recognized as wlan0, since there are no other adapters. All settings for wlan0 should have been carried over, since the settings apply to the wlan0 device and not directly to the physical adapter. If wlan0 isn’t working correctly, you’ll need to figure out what’s causing the problem. That’s why it’s best to do the entire configuration over LAN.

Okay, from what you’ve said, I gather that:

1. it’s not rocket science

2. my attempt to configure the Wi-Fi while connected to the current Wi-Fi network was counterproductive

3. with an existing LAN connection, switching the adapter should actually be completely hassle-free

Well then, I’ll give it a try that way.

ZeroTier isn’t tied to a specific adapter, so a new setup shouldn’t be necessary, right?

Correct

A direct swap from onboard WiFi to a USB adapter is also possible: Toggle “onboard WiFi” in dietpi-config network options to off, poweroff, attach the USB adapter, boot. With the onboard WiFi adapter disabled, the USB adapter becomes wlan0, hence /etc/network/interface seemingly uses the USB adapter, without any other change required.

OK, but I’d already disabled the internal Wi-Fi during set-up because the connection was too poor. That’s why I used the external adapter. Now, as I said, I want to do a bit of ‘tweaking’ and hope to achieve a completely stable Wi-Fi connection.

Swapping USB WiFi adapters works the same way. Just unplug the old and plug the new one, and it will take the same interface name, hence no need to fiddle with the network configs.

Of course you can manually setup a wlan1 with 2 attached adapters, or switch to LAN. But since your original question was

With DietPi OS running in the latest version and using ONLY a Wi-Fi connection as Wi-Fi0, what’s the best way to swap out the Wi-Fi adapter for a different one?

all this is at least not needed. You just need to unplug the old adapter, to assure the new one becomes wlan0, else it is essentially random, as Joulinar pointed out.

Every adapter requires a certain firmware package, but they are all pre-installed on DietPi (taking a significant fraction of our image size :sweat_smile:): The onboard Broadcom/Cypress/Infineon ones firmware-brcm80211, Realtek ones firmware-realtek, MediaTek/Ralink firmware-mediatek, etc. If you use a very new adapter, the needed firmware blobs might not be included in older Debian’s firmware packages yet. You would see a related kernel error:

dmesg -l 0,1,2,3

Might be the case for the BrosTrend WiFi 6E AXE3000, in which case backports can be tested:

sudo apt install -t "$G_DISTRO_NAME-backports" firmware-mediatek

They do say it should work “plug&play” on Debian and RPi OS, which is in that absolute wording always wrong, since the firmware package is always needed, and a certain minimum distro version (or backports) is needed. Since Debian ships firmware packages for all major vendors (adding Intel and Qualcomm Atheros), support for all WiFi adapters is basically the same. Just do not take any very newly release adapter :wink:.

I’ll take your comments on board tomorrow and let you know whether it was a success or a failure. :grin:

Well, unfortunately, I’ve fallen into the same trap as I did the other day.

I logged into the Pi 4 via SSH over Wi-Fi using the “old” Realtek adapter.

The Wi-Fi0 configuration is static.

Then I had the “brilliant” idea to re-enable Ethernet as well, hoping it would make my life easier when I swap out the Wi-Fi adapter.

But that was a huge mistake, because after a brief SSH login using the eth0 IP, I lost a stable network connection again. The Pi 4’s network is acting up—no matter whether I try to use eth0 or wlan0, I can’t connect to the Pi anymore.

Now I’m stuck and don’t know what to do next. The AI here is also extremely dumb and isn’t much help.

That’s why I’m counting on human intelligence here in the forum.:wink:

I’ve moved the SD card to another Pi via a USB adapter and have access to ext4.

Would someone please walk me through this step by step? I’ll provide the details as requested. It would be great if we could get the Pi 4 up and running again.

It has to be just a minor issue that threw the whole thing off track.

What command outputs can I provide to get to the bottom of this?

To reiterate my goal:

I’d like to first regain clean access to the Pi 4 via LAN. Then we’ll see what’s next.

The ultimate goal is then to get a new Wi-Fi adapter up and running and to disable the LAN again.

Thank you very much for your efforts!

Having Ethernet and WiFi enabled concurrently is often not working well. dietpi-config sets up both with a gateway/default route, which conflicts: If an inbound request arrives through Ethernet, it may be answered through WiFi vice versa. Especially if you use different IPs, that will end in nirvana.

When enabling both, you’d at best need to bring down one of them manually before bringing up the other in a single instruction, like

systemctl stop ifup@wlan0; systemctl restart ifup@eth0

So Ethernet is assured to have the default route. Then it should be possible to swap and test the WiFi adapters.

But as said, to me this seems unnecessary hassle: just swap the WiFi adapters while the system is powered off. If it does not come online, because driver or firmware is missing (unlikely), you should be able to swap the adapters mid operation: ifup@wlan0 is started once a WiFi interface is detected, not fixed at boot. In case of missing driver/firmware, no WiFi interface is detected, until you attach the functional adapter

It might be even possible to swap the WiFi adapter mid operation while the connection is up. wpa_supplicant should re-connect automatically, and the interface remains configured. But I did not practically test this.

I’ve already tried all of this.

Let’s stop here. I’m going to set up this Pi 4 from scratch and try it with the new adapter. How should I proceed?

A standard installation of the DietPi OS, connect via Ethernet, basic configuration, install ADSB.

Then comes the part with the new adapter. There’s still an Ethernet connection at that point. I’ll plug in the new adapter—what should I test first? I’ll disable the internal Wi-Fi. If the new Wi-Fi adapter is detected, what should I do if I want to switch from Ethernet to Wi-Fi only? That’s probably the key point.

I don’t get why you want to temporarily enable Ethernet at all? Just setup things with WiFi directly, boot with the new adapter attached, disable onboard WiFi after first boot, or add dtoverlay=disable-wifi to config.txt before first boot to assure the new adapter is used right away.

Else, via SSH only, the only 100% failsafe way to switch from Ethernet to WiFi is to enable WiFi, then comment out allow-hotplug eth0 in /etc/network/interfaces manually, and reboot. If you disable the Ethernet connection currently used for SSH, it naturally drops. Usually, since ifup@ services are stopped/restarted accordingly, it should be possible to reconnect via WiFi some seconds later. But if that takes too long, the SSH server might terminate the processes before the WiFi connection, authentication, and in case DHCP, fully finished. A power cycle would then be needed.

But now I have to ask a really silly question again:

I’ve never set up a Pi with dietpi using only Wi-Fi.

Where can I enter the Wi-Fi name and password so that the Pi connects automatically?

I can’t find anything in dietpi.txt, anyway.

Oops, sorry—you just need to be able to read; it’s all in the dietpi.txt file. I have to use the dietpi-wifi.txt file…

Yes do this before first initial boot

  1. Open the file dietpi-wifi.txt and set aWIFI_SSID[0] to the name of your WiFi network.
  2. In the same file dietpi-wifi.txt, set aWIFI_KEY[0] to the password of your WiFi network.

It’s as well documented on our online docs. Not that obvious but it’s there :rofl:

Right, + AUTO_SETUP_NET_WIFI_ENABLED=1 in dietpi.txt.

@MichaIng / @Joulinar

Let me put it this way: your tip worked.

I’m setting up the Pi now and will configure everything for adsb.im. That should work, but it still doesn’t quite solve my biggest problem.

The “normal” ADSB feeder is quick to set up, but after my experience with this “trial run” here, I’m hesitant to touch the second Pi 4 running Wingbits.

That’s because the same problem exists there. The Wingbits Pi is also currently connected only via Wi-Fi.

I’d like to replace the external Wi-Fi dongle I’m currently using with a different, better one. By the way, it’s exactly the same one that’s now working with this Pi here.

I’ve already followed the instructions—“shutdown -h now,” swap the dongle, reboot, and it should be fine”—on this Pi here, but without success and ultimately resulting in the chaos I described.

After this whole ordeal, I’m really hesitant to reconfigure the other Pi.

Sure, I could start this installation from scratch, but that’s exactly what I want to avoid at all costs! Over time, a lot of specific configurations have been built into it that I wouldn’t be able to get right on my own.

First, I’m going to get this ADS-B feeder fully up and running, and then I’d like to reach out to you again for tips—and maybe provide some additional information—so I can switch out the Wi-Fi adapter without any issues.

I hope you’ll support me in this!

Shutdown, swap dongle, boot, without enabling Ethernet or touching network configs, did not work, using the same adapter which does work on the new system?

Is it a different Debian version? As said, the firmware-mediatek might be too old on Debian Bookworm (dongle release 2024, Bookworm release 2023). Could be tested with backports as suggested above, or upgrading to Debian Trixie: Debian 13 Trixie has been released – DietPi Blog

EDIT: Side note: firmware-mediatek is actually available from trixie and bookworm-backports only, split off from linux-misc-nonfree. But RPi Ltd ships an older backports version of the firmware-nonfree packages with their own archive.raspberrypi.com repo, to address some issues with the RPi onboard WiFi with the older version from Debian Bookworm. But it is still ~1 year older than the one from bookworm-backports now.

So here’s what I can report:

The newly set up Pi 4, now with the MediaTek adapter, works perfectly.

I didn’t have to install any drivers at all—it’s truly plug-and-play. Compared to the other Pi 4 with the Realtek adapter, the connection is 2–3 times better.

That’s exactly what I’d been hoping for, and now I’ve achieved it.

However, I also made 1–2 “optimizations” to the router—a Fritzbox 7530—which have also made a noticeable difference.

Instead of “Auto Channel,” I set the channel manually and disabled features like coexistence and mesh steering.

Apparently, those sensational marketing claims from Fritz were counterproductive in my situation.

So, a little more work, but everything turned out fine in the end—especially thanks to your professional help.

The ADS-B feeder is up and running again.

Now I’ll soon be tackling the “more important” Wingbits feeder.

I definitely won’t be enabling Ethernet.

Then I’ll follow the tip again and swap out the Wi-Fi adapter while the system is running, since it works perfectly on the newly set up Pi.

If that doesn’t work, I still have the option to reboot the system to see what happens. If, contrary to expectations, that doesn’t work, I’ll get back to you, so I don’t want to mark this thread as resolved just yet.

Thank you very much for your help so far!