Replacing the WiFi Card on an Asus ROG Strix B450-I Motherboard

I’ve recently got so fed up with the Linux driver support of the Realtek RTL8822BE network adapter on my motherboard (especially its poor Bluetooth support) that I seriously considered a hardware fix. In the end I’ve replaced it with a much better supported card, an Intel® Wi-Fi 6 AX200.

The Realtek linux driver in Ubuntu Desktop 20.04 up to 21.10 is crappy, to say the least – I’ve constantly had WiFi connection issues and connecting to my stereo via Bluetooth was not even working out of the box. Only after manually extracting the firmware from the Windows driver, copying it to the right location, and adapting a few settings, it worked. Poorly.

Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter
Subsystem: ASUSTeK Computer Inc. RTL8822BE 802.11a/b/g/n/ac WiFi adapter
Flags: bus master, fast devsel, latency 0, IRQ 74, IOMMU group 15
I/O ports at c000 [size=256]
Memory at fc500000 (64-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: rtw_8822be
Kernel modules: rtw88_8822be

Having already dealt with these issues before on my Dell notebook by, surprise, replacing the Realtek card with an Intel AX200 about a year ago, I was eager to try the same on my Mini-ITX motherboard.

Asus Wi-Fi GO! Card Socket

I haven’t found much information about the Asus Wi-Fi GO! card on the board. But I’ve seen quite a few of them on eBay and some were shown in a disassembled state. So I was quite confident that the RF shield could be opened and inside would be a standard PCIe M.2 WiFi card that could be replaced.

The RF shield is held on the board by two screws (from the bottom side) and it can be pulled off the PCIe connector after removing these screws. Another screw holds the two halves of the shield together.

Opened Wi-Fi GO! Card Shield
Removed Realtek RTL8822BE Card

Replacing the PCIe WiFi card should then be pretty straight forward. In my case I’ve bought an Intel AX200 card for under 20,- € (shipping included) as replacement. It should be possible to replace the PCIe card without completely disassembling the the two SMA connectors; I’ve done it for convenience. Also there’s a black rubber block stuck onto the card that you might want to reuse (peel it off carefully).

The reassembly with a new card is pretty much doing the same steps in reverse order, so I’m not describing or showing it here. In the end, it probably took me longer to get the motherboard out of the Mini-ITX case and back in again than disassembling the Wi-Fi card; less than half an hour for the actual card disassembly and replacement.

KVM over IP Switch: Cross-vendor Firmware Upgrade via hidden Option adds VNC Server

At work we have a KVM over IP switch from Inter-Tech, a KVM IP-KVM101. It is really a small and versatile device that, in combination with 16-port KVM switches, allows us to control a complete rack with test hardware.

The KVM switch provides a web interface with a Java Web Start application for remote access. But the latest browser security updates disabled and removed the Java Web Start support . This move was announced quite some time ago (Oracle White Paper). Still, the vendor of the KVM switch, Inter-Tech, was not able to provide a valuable solution to cope with this problem.

After a bit of Googling I found an Amazon review about this particular KVM switch where the reviewer stated to have installed the firmware from another brand, the LINDY KVM over IP Switch. The LINDY switch looks identical (besides a different sticker) and – even better – their latest firmware provides a VNC server. This would allow us a browser and even operating system independent access to the KVM.
Continue reading

Kids + Railway Toilets = Toilet-Blinkenlights…

Today my kids impressed me by repurposing/hacking/misusing the toilet-occupied-light to send (morse-like) signals across a railway car. Their fingers were thin enough to press the micro-switches in the doors which normally would signal a locked door (i.e. occupied toilet). Not sure if someone noticed the strangely flashing lights… 😀


Unbricking a HP LaserJet M1212nf stuck in an “initialization loop”

I recently helped to repair a bricked HP LaserJet M1212nf printer that was stuck in an “initialization loop”. It booted up normally, but after 10-20 seconds the printer stopped to accept any kind of commands and the text “initializing” was shown on the LC-Display. It then restarted and the whole boot/init started over again and again.

My first approach was to make a hard reset, i.e. set the printer to factory defaults. This can be achieved by:

  1. Turning off the printer
  2. Pressing and holding the “Start Copy” and the “Cancel” button. (Easy, both are below each other.)
  3. Turning on the printer

After setting the initial configs (language, country) the initialization loop reappeared —  the problem was not fixed by the hard reset.

Next, I tried to reinstall the latest firmware which failed due to the loop — there simply was not enough time to upload the firmware I would guess.

I then tried to find out if there is some kind of low level bootloader that would accept a firmware image (many devices nowadays have such a semi-failsafe mode) when the printer is turned on — but did not find any info on that either.

My final approach was just to try out if there would be a firmware upload possibility right after a hard reset (steps as described above). I had recognized that the initial settings/configs right after a hard reset were not affected by the reboot loop. To my surprise this actually worked. I was able to upload the firmware when the first init-setting appeared. After updating the firmware the loop was gone and the printer worked again as before.

I hope this description helps others who are also affected by this problem as I have not yet seen any other solution in the HP forum. I can only guess how the “initializing loop” occurred: maybe an automatic firmware update failed and bricked the printer. Anyways, the 200+ MB printer driver software by HP is a PITA and their web site is a maze…

Watched the Solar Eclipse with a Quick and Dirty Pinhole Camera

Of course neither me nor any of my colleagues had an appropriate protection to view the upcoming solar eclipse. So I had to ‘hack’ together a device to still be able to watch the eclipse pass in a safe manner.

Solar Eclipse (Munich, Germany, 2015.03.20 10:40 CET) viewed though a simple (5 minute hack) pinhole camera:
Simple Pinhole CameraThe camera was built from an old rolled conference poster, some adhesive tape, plastic foil, and a cardboard box. I think it is self-explanatory:
One side was covered with opaque foil, only a tiny pin hole (< 1 mm) let light through. The other side was simple plastic foil (from my lunch). The box acted as a shield to protect from accidentally looking into the sun.
Simple Pinhole Camera showing the Solar Eclipse

It’s a mirror image, by the way.

Additionally (out of curiosity) I’ve taken a photo with my iPhone 4S:
Solar Eclipse Photo  / iPhone CameraThe eclipse can be seen in the lense flare (here a 100% cut-out):
Solar Eclipse Photo  / iPhone Camera (Lense Flare)

Kabel Deutschland TR-069 Auto-Configuration on a FritzBox 7390

The cable provider Vodafone (Kabel Deutschland) does not officially support VoIP connections from other routers than the ones they have issued: in my case a FRITZ!Box 7270. They do not provide the VoIP credentials; their boxes are auto-configurated via TR-069 protocol. Having a FRITZ!Box 7390 led me to investigate how to enable this full auto-configuration in other boxes than the 7270.

This is a follow-up to my previous post on how to clone CWMP settings between FritzBox 7270s.

I started with a freshly recovered FritzBox 7390, i.e. all previous configuration settings were erased. Also I did not connect any devices to the FritzBox. The Power/DSL LED is blinking.

The following changes were made via the UART interface on the PCB. I have not tested them via the FritzBox Telnet connection. It might be possible to write and  trigger them as a shell script (as the network connection is shut down in the process), I have not tested that either.

FritzBox 7390 UART Connection

Start with a shell on the FritzBox and shut down the network and DSL daemons:

cd /etc/init.d/

./ stop
    [...takes some time...]

./ stop
    [...takes some time...]

Then reconfigure the environment settings. I’ve used the urlader / boot loader (EVA) to set the tr069-credentials (as described here). I’m not sure if they can be also defined later, but if so, it should look something like this:

echo "tr069_passphrase XXXXXXXXXXXX" >> /proc/sys/urlader/environment
echo "tr069_serial 00040E-XXXXXXXXXXXX" >> /proc/sys/urlader/environment

You might also want to check the MAC addresses: maca, macb, macwlan, macwlan2, macdsl, usb_board_mac, usb_rndis_mac
If the default addresses are set the FritzFox might completely fail to establish an internet connection. You then should set them to (pseudo)random values.

The following settings have to be adapted temporarily to simulate a FritzBox 7270. These environment variables will be reset on the next reboot (unlike the changes in the urlader, btw.). The remote TR069 server is checking the product name and the software version (besides the previously defined tr069-credentials).


export CONFIG_PRODUKT="Fritz_Box_7270_16"

export CONFIG_VERSION="06.05"



export EXTERNAL_BOX_PARAMS="hardware=${HWRevision}&oem=${OEM}&language=${Language}&country=&version=${CONFIG_VERSION_MAJOR}.${CONFIG_VERSION}&subversion=${CONFIG_SUBVERSION##*-}"

After that restart the network settings:

./ start
    [...wait 10-20 seconds...]

Connect the FritzBox to the cable modem (via LAN1). After a while the FritzBox should fetch the CWMP/TR069 settings, including the telephone settings. This can be checked by entering:

 cat /var/flash/tr069.cfg
     [...should list tr069 settings...]
cat /var/flash/voip.cfg
    [...should list telephone settings...]

P.S. I recommend to disable the TR-069 auto-configuration settings if not needed. They theoretically poke a quite huge hole into the security of your router.

Cloning FritzBox 7270 CWMP Settings

I own an over 5 years old AVM FritzBox 7270 router which is after all that time becoming slightly unstable. (The capacitors might be wearing out.) The router uses the CWMP (TR-069) protocol to authenticate itself at my cable provider Vodafone (Kabel Deutschland). As these settings are tied to the box and the FritzBox 7270 is neither sold nor supported anymore I bought two cheap 7270_v2 boxes (identical hardware, different branding) on eBay and successfully transferred the authentication credentials from my old box onto the two new ones.

Warning: Please keep in mind that the following steps worked for me but I do not feel responsible if you brick your FritzBox by trying them out yourself. I tested it on two spare routers I’ve explicitly bought for this purpose.

0. Debranding & serial connection

Opening the cases of the routers allowed direct access to the serial interfaces on the PCBs. This might not be necessary as all (following) steps, at least the debranding (here: “1und1” to “AVM”), can be done without access to the serial interface. I have not tested that. But the serial interface allowed the “deepest” access to the routers’ system.

I will not describe how to set-up a terminal connection and how USB to RS232 adapter work. This is sufficiently covered by other tutorials. It is also not necessary to solder pins onto the RS232 interface on the PCB. For me it worked perfect to just stick a few pin headers into the pads as seen on the following two images. (It’s best to not touch the cable during the process though.)

FritzBox 7270 RS-232 Connection FritzBox 7270 RS-232 Connection

1.Test: Directly connecting the two new boxes to the cable modem

After a factory reset (“Werkseinstellungen”) via the web interface I’ve first connected the two boxes to the cable modem. As expected they were able to fetch the general provider settings but not the VoIP (telephone) settings.

Comment: The VoIP settings can be extracted by hand from a fully authenticated FritzBox but I wanted them to also do that for me.

2.Backups: Storing the environment settings and MTDs

It is always a good idea to make backups of the devices you are going to hack. I attached an USB stick to the box and changed into a newly created directory on it.  You will need to backup the following file on all of your FritzBox routers. (Adapt the destination filename as necessary.)

cp /proc/sys/urlader/environment environment-source-fritzbox.txt

It’s also a good idea to make backups of the block devices… just in case. (The FritzBox 7270 there should have 6 block device “mtd0” to “mtd5”.)

dd if=/dev/mtd0 of=mtd0.bin

3.Cloning the CWMP settings

I once again ran a factory reset while having the serial interface connected to the box. I halted the boot process directly after the reset when the bootloader (“urlader” / Eva_AVM) appeared. The bootloader shows a prompt for 5 seconds and the boot process can be interrupted by entering a command, e.g. “h<enter>” for help.

system is going down ..
The system is going down NOW!
Sent SIGTERM to all processes
Requesting system reboot

(AVM) EVA Revision: 1.455 Version: 1455
(C) Copyright 2005 AVM Date: Apr 1 2008 Time: 13:07:03 (1) 2 0x0-0x41D

[FLASH:] ST Uniform-MirrorBit-Flash 16MB 64 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 128 sectors a 128kB) 
[SYSTEM:] UR8 on 360MHz/120MHz syncron

 Commands Description
 -------- -----------
 help help
 dm dump mem <addr> <range>
 cm change mem <addr> <value>
 erase Erase Flash <mtd>
 printenv print Env. Variables
 restart reboot Device
 setenv set Env. variable <var> <value>
 unsetenv unset Env. variable <var>
 go load & start kernel from mtd1
 setmac set mac addresses <addr> (like 12:23:40)
 memtest test memory

To really erase all settings from the FritzBox 7270 I’ve used the “Erase Flash” option. The settings are stored in two TFFS blocks: mtd3 and mtd4.

Warning: stay away from mtd2 (the bootloader)! Erasing this block device will brick your router.

Eva_AVM >erase mtd3
erase from 0x90F80000 to 0x90FC0000

Eva_AVM >..
Eva_AVM >erase mtd4
erase from 0x90FC0000 to 0x91000000

Eva_AVM >..
Eva_AVM >restart
<create new TFFS>

[...break here! ...]

After a restart the TFFS partitions are recreated based on the hardcoded settings in the bootloader. Again interrupt the boot process directly after the TFFS blocks were restored. Now you have to look into the previously stored environment settings from the original FritzBox and add (or overwrite) the CWMP settings in the destination box. It might be necessary to also set the MAC addresses as they might have been set to default values. (The default MAC addresses possibly won’t let you connect at all – I’ve had that problem with one of my boxes.)

Eva_AVM >setenv tr069_passphrase XPASSPHRASEX

Eva_AVM >setenv tr069_serial 00040E-XXXSERIALXXX

Eva_AVM >restart

Comment: You can check with the “printenv” command if the settings were successful and if the default environment (MAC) settings were set.

Eva_AVM >printenv

In my case that was all I had to do. I then let the router boot as normal and connected it to the cable modem. After a minute or so it fetched all necessary settings (including the VoIP settings) and pre-configurated the FritzBox.

Surprisingly it was not necessary to transfer the MAC addresses or any other settings from the original FritzBox to the other two boxes. (Something I expected based on various forum posts.).

I’ve later also tried the same steps on a FritzBox 7390 but failed to receive the VoIP settings. The ProductID (FritzBox 7270) and the software version is additionally transmitted along with the tr-069 credentials. In a second post I’m providing a possible solution on how to achieve an auto-update via TR-069 on other FritzBoxes.

Homemade minimal Raspberry Pi (Raspbian) image

I have to admit that I’m a big fan of single-board computers for specific tasks like home-automatation, backup systems, network gateways, or file-sharing. I also like the approach of the Raspberry Pi Foundation to provide an image file with Raspbian (an adapted Debian) for easy use. For most people out there it is the best way to fetch an SD-Card with a capacity of at least 4 GBytes, download and copy the Raspbian image onto the card. I have a few unused 1 and 2 GByte SD-Cards lying around which should be sufficient for my tasks but are too small for the ‘generic’ Raspbian image. So I had to create my own minimalistic Raspbian installation. Here is a step-by-step example of the creation process.

I started with the installation of a few later required packages. I’m pretty sure this list is incomplete as I’ve already had quite a lot dev-tool packages installed before…

sudo aptitude install qemu-user-static \
binfmt-support fakeroot debootstrap git

To get Qemu running to support armhf I had to add a parameter to itc configuration file:

echo "EXTRA_OPTS=\"-L/usr/lib/arm-linux-gnueabihf\"" > /etc/qemu-binfmt.conf

I used “/tmp/” as my working directory which might not be the best location (temporary, as the name says). Feel free to use another dir, but you might need to keep an eye on the (root) access permissions…

cd /tmp/
mkdir raspi raspi/bootfs
cd raspi

Next I downloaded a minimalistic list of Raspian packages that will later go onto the root partition. I’ve tried to avoid working with root permissions as far as possible (therefore ‘fakeroot’).

fakeroot debootstrap --foreign --no-check-gpg --include=ca-certificates --arch=armhf testing rootfs

No we need to (temporarily) add some arm binaries to the root directory.

cp $(which qemu-arm-static) rootfs/usr/bin

The following step will start the actual installation process of the Raspian packages. For some reason I was not able to continue at this point without root permissions. (Any tips to fix this are welcome.)

sudo chown root.root rootfs -R

sudo chroot rootfs/ \
/debootstrap/debootstrap --second-stage --verbose

You will need some of the Raspberry Pi firmware files. The following commands download and install them . The Git repository is huge (3.1 GB), so this might take some time…

git clone \

sudo cp -r firmware/hardfp/opt/* rootfs/opt/

At this point you could create a custom kernel image based on the downloaded files. In my opinion the stock kernel is just fine so I just used it as is:

mkdir -p rootfs/lib/modules/

sudo cp -r firmware/modules/* rootfs/lib/modules/

Create the boot partition (i.e. copy the necessary files):

mkdir bootfs
cp -r firmware/boot/* bootfs/

Next we can make some adaptions to the future image files: set a new root password, hostname, adapt the sources list, etc…

sudo chroot rootfs/ /usr/bin/passwd

vim rootfs/etc/hostname

cat >> rootfs/etc/apt/sources.list deb testing main contrib non-free rpi

It might also be a good idea to adapt the future system to your local settings, e.g. keyboard layout.

sudo chroot rootfs/ apt-get update

chroot rootfs/ apt-get install console-data \ 
console-common console-setup tzdata most locales keyboard-configuration

sudo chroot rootfs/ dpkg-reconfigure locales

sudo chroot rootfs/ dpkg-reconfigure \

sudo chroot rootfs/ dpkg-reconfigure tzdata

Now we can do some clean-up:

sudo rm rootfs/usr/bin/qemu-arm-static

Next step is the creation of the actual boot and root partitions on a SD-Card. I’ve not documented these steps in detail as everyone has a different favourite partition manager. This step can be done with fdisk, (g)parted, or other tools.

You have to create two partitions on your SD-Card. For the boot partition 64 MB are sufficient, the remaining space is used for the root partition. The boot partition needs to be a FAT32 partition. The nice thing about the Raspberry Pi is, that boots of the first FAT32 partition without further installing a boot block or so.

Here an example how a 2 GB SD-Card could look like:

fdisk -l /dev/sdd
  /dev/sdd1 2048 133119 65536 b W95 FAT32
  /dev/sdd2 133120 3987455 1927168 83 Linux

Now we can copy the files from the two directories we previously created onto the two SD-Card partitions (you might need to mount them first) and test the card.

cp -R rootfs/* /media/USER/root/ && sync
cp -R bootfs/* /media/USER/boot/ && sync

I also have created an image file, mounted is (as a block device), partitioned it similar to the steps above. But I have not yet documented these steps. Might be added in a future update…