Category: Uncategorized

sudo dd if=2025-05-13-raspios-bookworm-arm64-lite.img of=/dev/mmcblk0 bs=4M status=progress oflag=sync


Want to be able to ssh nas instead of having to do ssh nas.local? What you use your own domain to get SSL working correctly for local hosts without having to ssh nas.mycustomdomainislongsohelpme.dog? Wondering why you can’t just add .local and mycustomdomainislongsohelpme.dog to the search field in the ol’ /etc/resolv.conf?

Systemd is eating everything. It ate resolvd. Now we have to configured systemd for local search.

Edit `/etc/systemd/resolved.conf, and add or change the following line:
Domains=local,mycustomdomainislongsohelpme.dog

Then sudo systemctl restart systemd-resolved

Now Bob is your uncle.

This is largely going to just require slight modification for any other appimage.

Create a file named /home/jdboyd/.local/share/applications/bitwarden.desktop
and give it the contents of:

[Desktop Entry]
Type=Application
Name=Bitwarden
Icon=/home/jdboyd/.local/bin/bitwarden-256.png
Exec=/home/jdboyd/bin/Bitwarden-2024.10.2-x86_64.AppImage
Terminal=false
Hidden=false
Categories=Utility

Also download the png icon from https://github.com/bitwarden/brand/blob/main/icons/256×256.png

Then place it at /home/jdboyd/.local/bin/bitwarden-256.png

Now the application can be launch from the dock correctly.

In this post, I will explore what is the ethernet chip in the official Mevo Start Ethernet Power Adapter, as well as what other USB-C ethernet adapters that I have are compatible with the Mevo Start as well as what ethernet chip is in them.

Here is what dmesg shows when plugging it into a Linux machine:

[219146.587703] usb 1-1: Product: Mevo Start Ethernet Power Adapter
[219146.587708] usb 1-1: Manufacturer: Mevo, Inc
[219146.587714] usb 1-1: SerialNumber: 662d6f
[219146.596966] smsc95xx v2.0.0
[219146.691715] SMSC LAN8710/LAN8720 usb-001:014:01: attached PHY driver (mii_bus:phy_addr=usb-001:014:01, irq=148)
[219146.692622] smsc95xx 1-1:1.0 eth0: register 'smsc95xx' at usb-0000:00:14.0-1, smsc95xx USB 2.0 Ethernet, 38:f0:c8:0a:26:27


The Mevo help pages https://help.mevo.com/hc/en-us/articles/360043944091-Mevo-Start-Ethernet-Power-Adapter-3rd-Party-Ethernet-Adapters-PoE also list some non-PoE third party adapters that are supposed to work. One they recommend is simply listed as “Anker USB C Hub”. When I followed that link in 2023, it led to this item on Amazon, “Anker USB C Hub Adapter, PowerExpand+ 7-in-1 USB C Hub” https://www.amazon.com/gp/product/B07PPGWQ15/ Now the link leads to “Anker USB C Hub Adapter, 5-in-1 USB C Adapter” https://www.amazon.com/gp/product/B07X8ZLYLR/ which has fewer features and is about the same price. It is smaller though.

The Ethernet portion of the Anker I bought shows up in dmesg as:

[1452039.065319] usb 3-10.2: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
[1452039.065331] usb 3-10.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1452039.065335] usb 3-10.2: Product: AX88179A
[1452039.065339] usb 3-10.2: Manufacturer: ASIX
[1452039.065342] usb 3-10.2: SerialNumber: 00000000000809

I paired that with a “UCTRONICS PoE Splitter USB-C 5V” https://www.amazon.com/gp/product/B087F4QCTR/

It is ugly to put the two together, but the 2 products together are less than half the price of the Mevo Ethernet PoE adapter.

I also bought a “Revotech PoE to TypeC Adapter Converter” https://www.amazon.com/gp/product/B09M2N3NHX/ The picture on the Amazon listing now no longer matches what I received. I didn’t but it for this, but it turns out that it does show up as working with the Mevo Start. I haven’t not tested it extensively for reliability though.

It shows up in dmesg on a linux system as:

[1452778.512687] usb 3-10: New USB device found, idVendor=0bda, idProduct=8152, bcdDevice=20.00
[1452778.512696] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1452778.512699] usb 3-10: Product: USB 10/100 LAN
[1452778.512701] usb 3-10: Manufacturer: Realtek
[1452778.512703] usb 3-10: SerialNumber: 00E04C36116E
[1452778.514900] cdc_ether 3-10:2.0 eth0: register 'cdc_ether' at usb-0000:00:14.0-10, CDC Ethernet Device, 00:e0:4c:36:11:6e
[1452778.530795] usbcore: registered new device driver r8152-cfgselector

This is about 1/4 the cost of the official solution and it is much tidier that the combo of Anker hub and separate PoE extractor. The complaint I have about it is fallback though. Recently my field PoE injector failed, so I had to supply power to the Mevo via the USB-C power port on the Mevo Ethernet unit. Had I this unit with me, I would have been stuck since I would have had to choose between ethernet or power when I needed both. This could have been protected by making sure the Mevo was charged before I left the office, but I stopped doing that after I switched to always using PoE.

At this point, I kind of expected virtually all USB-C -> Ethernet adapters to work but then I tried what I considered my best one, the “OWC USB Type-C Travel Dock E Multiport Travel Adapter” https://www.bhphotovideo.com/c/product/1626291-REG/owc_owctcdk6p2sg_usb_c_travel_dock_hdmi.html

This unit refused to work on the Mevo. Below is the dmesg section relevant to the ethernet adapter:

[287527.450004] usb 2-1.2: new SuperSpeed USB device number 18 using xhci_hcd
[287527.462943] usb 2-1.2: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=31.00
[287527.462960] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[287527.462968] usb 2-1.2: Product: USB 10/100/1000 LAN
[287527.462973] usb 2-1.2: Manufacturer: Realtek
[287527.462979] usb 2-1.2: SerialNumber: 001000001
[287527.532577] r8152-cfgselector 2-1.2: reset SuperSpeed USB device number 18 using xhci_hcd
[287527.569047] r8152 2-1.2:1.0: load rtl8153b-2 v2 04/27/23 successfully
[287527.597915] r8152 2-1.2:1.0 eth0: v1.12.13

What is different about this one is that it is a USB3 ethernet device, while the previous USB-C ethernet devices appear to all have shown up as USB 2 devices. Interestingly, that last device also refuses to work with any of the USB-C->USB A adapters that I have.

That ends all the devices I have for testing currently. So far I would call none entirely satisfactory for PoE ethernet adaptation.

My ideal device would consist of a small unit with support for both PoE power and USB-C power, an ethernet interface with a common USB 2 gigabit ethernet chip, a USB hub and one or two USB2 interface. Additionally, it would connect to the Mevo via a USB-C port rather than having a USB-C cable built in. The purpose of the USB2 interface would be to support an external sound device. The purpose for more than one would be in case something other than a Mevo had a use for more options. For instance an iPad wanting power, ethernet, USB audio and a USB MIDI or Gamepad interface on one USB-C port.

On Unix-like systems, ports below 1024 are considered privileged, meaning that only the root user can bind to them. Web servers traditionally listen on port 80 for HTTP and port 443 for HTTPS. A key innovation of Podman is not running containers as root to enhance security. This presents challenges when containers need to use privileged ports like 80 or 443 for web server functions.

If you google solutions to this problem there are three common solutions suggested. First, run container as root. Second, use a proxy server like nginx or Caddy running outside a container, as root. Third, redefine where unprivileged ports start to be 80 or below.

Running containers as root to bind directly to privileged ports is the simplest approach but it significantly compromises security. Also, wasn’t getting away from containers require root one of the main reasons to move to podman?

Running a proxy server on the host without any container is what I did at first for docker and podman. It was a good transition from no containers to starting to run some services in containers. Still, that means more stuff that has to be be deployed separately from the containers. If you are going to use containers, it will be nicer to more fully embrace them.

Quite a few posts on various forums recommend redefining where unprivileged ports start to port 80. This means that you no longer need root to run a web server on port 80. It also means that hostile software or users no longer need root to serve on other privileged ports. For the purposes of this post I chose to believe that the people who decided that everything below 1024 is privileged knew what they were doing.

I have come up with a method I think is better for small deploys. Use the host’s or upstream’s firewall capabilities (with tools such as UFW, iptables, or nftables) to redirect traffic from privileged ports to non-privileged ones. This means minimal configuration change to the host OS (possibly none if you can do it with the upstream firewall), and you don’t give up running your containers without root. For now it seems like the best choice. What follows are partial examples for doing it with three firewalls likely to be included in your Linux system.

UFW example:

sudo ufw allow 80/tcp sudo ufw allow 443/tcp

sudo ufw route allow proto tcp from any to any port 8000 sudo ufw route allow proto tcp from any to any port 8443

sudo ufw enable

iptables example:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8000 

sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443

nftables example:

sudo vi /etc/nftables.conf

table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        
        # Redirect HTTP (port 80) to port 8000
        tcp dport 80 redirect to 8000
        
        # Redirect HTTPS (port 443) to port 8443
        tcp dport 443 redirect to 8443
    }
}