Joshua D. Boyd

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.

This was a summer project with my son David and myself.

Often when I go up the stairs, this is what I see:

The last post of the banister was turned into a scratching post for Bob.

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
    }
}

In 2021 I purchased the 27.5″ 48v 500w Ancheer branded ebike from Amazon \for $1200. I found a new listing from Ancheer for what looks like the same bike but now only $400. I thought it would be worth sharing my thoughts on the one I bought.

If you aren’t already used to expensive bikes, and you are interested in trying an ebike, this is probably a good choice for finding out if ebikes are for you. It may be that you find you don’t want an ebike, in which case you didn’t waste too much money and can sell it where ever you sell used things. It may be perfect for you. It may inform you that you really like ebikes, but you want a better one. When I paid much more for mine, I expected it to either tell me it wasn’t worth it or that I would want to spend more in the future.

I am a big guy who puts a lot more strain on bikes than most people would (per mile ridden of course). Thus, I wish mine had more torque and better brakes. However, I think for most people, the complaint will only be that the assistance levels don’t offer enough finesse. My bike doesn’t like to provide assistance below approximately 9mph, and that is too fast for writing with children or very slow adults.

In August I gave a quick talk on Gameboy development. Here it is below:

Optical media won’t last forever. I’ve already had a bunch of music CDs and GameCube games rot away on me and be lost. To guard against that, I am attempting to back up as much of my media as possible.

On the topic of ripping disc based media, Redump.org is great for providing reference hashs to let you know that your dump is accurate. They also provide directions, but they are mostly Windows focused. I’d rather use Linux when possible.

Ripping most DVD games is easy enough. A simple run of dd does the trick:

dd if=/dev/sr0 of=backed_up_game.img & progress -mp $!


The & progress -mp $! is just a way to get a nicer display of progress from dd.

One thing that caused me trouble though is PS2 games that were shipped on CDs. I bought a few of the cheaper ones that I already had over again thinking maybe I had bad disks, but eventually I figured something out. I didn’t figure out how to use dd, even though it seems there should be able to make that work (and it does work for PS1 discs), but I did figure out that I could use cdrdao to back up CD based PS2 games.
cdrdao read-cd --read-raw --datafile backed_up_game.bin cdimage.toc

The .toc file can then be deleted. I hope I don’t end up regretting that.

The next issue I ran into was a bad DVD disc. I bought a second copy of the game, but that DVD was also damaged. It was expensive enough that I didn’t want to try a 3rd copy, and I figured that the two copies were probably damaged in different areas, so smarted ripping should let me get a good single image from the two discs.

The tool I found for doing that is ddrescue. Compared to dd it does several things differently. First, for bad sectors, it will write 0s in the img file and make a note of that in the log for further attempts.

Second, it can be set to retry bad sectors.

I ended up using several runs of the program to do the job.

First, starting with the disc that produced the larger file originally with dd, I ran:

ddrescue --no-scrape --no-trim -p -v /dev/sr0 ./backed_up_game.img ./ddrescue.log

That did a best effort of only what worked correctly the first try.

I then did swapped disks and repeated that command. Sadly, this still didn’t quite there, so I followed it with:

ddrescue -p -v /dev/sr0 ./backed_up_game.img ./ddrescue.log

This tells it to ignore tells ddrescue to now work normally, AKA, retrying problem spots and marking off the boundary of them. Eventually it started going incredibly slowly, so rather than wait the estimated 2 days listening to the racket it was making, I swapped discs again and did:

ddrescue -M -R -p -v /dev/sr0 ./backed_up_game.img ./ddrescue.log

The addition of -M -R says to ignore the parts that were marked bad and this time try going backwards.

Finally after all those tries, I had a ./backed_up_game.img that’s sha1sum matched the reference value from redump.org.

At this point, I only have one game uncompleted. In that case, I haven’t received a second copy yet, but according to sources online there was a flawed pressing, and I have one of those discs, so no amount of re-tries would ever make this disc read entirely correctly.

I needed to power on and turn on a server that had been off for 8 years to check for some missing data. Of course, security standards have advanced (and that server probably wasn’t up to date when turned off), and SSH from Ubuntu 20.04 LTS would no longer connect to the old server.

Step 1: Diagnose

Turn on verbose mode.

ssh -v 192.168.0.100

That shows:

Unable to negotiate with 192.168.0.100 port 22: no matching key exchange method found. Their offer: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Step 2: Solution

ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1 -v 192.168.0.100

I got my files, and now I’m documenting this in case it comes up again someday.