RoonServer on Ubuntu 22.04.4 [Apple hardware]: a high rate of reachability/discovery storms and other issues [Solved?]

Jeff_Greenberg · April 5, 2024, 5:05am

Updated on 4/22/2024

Not sure if this is a solution or just a workaround but I have been able to stop the reachability events without any adverse effect on Roon. Hopefully, RoonServer will be more stable now but that’s TBD. Here’s a copy of the latest post so it isn’t necessary to scroll to the bottom of this thread to get to the punchline:

I’ve been spending some time looking through the Network Manager logs in trace mode and finally come to the conclusion that it is Network Manager that is the source of the erroneous reachability changed messages. To test this, I disabled Network Manager completely while leaving the static IP configuration unchanged (i.e. manually configured static IP, manually configured DNS, etc.)

The result was the complete elimination of the reachability events described in my initial post!

So far, I have observed no ill effects on Roon or anything else as a result of this change. However, I have not tested long enough in this configuration to know if the occasional RoonServer crashes are also gone. And network traffic between my server and Roonlabs looks like it may be reduced by close to 99% based on the elimination of the 1 per minute re-authorization exchanges that have been happening (I haven’t directly snooped the network to verify that but it seems likely given what I’m seeing in the logs).

As for what exactly is going wrong in Network Manager I can’t say for sure. Symptomatically, NM appears to adjust the routing table entry associated with my wired interface by dramatically increasing the routing metric. Then, it changes it back to its original reasonable value moments later. But the routing table change is associated with a network change event that must be filtering down to RoonServer. It’s not clear if the metric change is a cause of the problem or just the first visible manifestation of some other change that isn’t reported in the logs. I’m not really motivated enough to dive into the Network Manager source code to track it further at this point.

I’ve changed the title of this thread to be more specific about the issues I’ve encountered. I’m also correcting an error in the original post related to the rate at which the “reachability changed” messages occur (thanks to @Andreas_Philipp1 for catching that!), I’ll also be updating with actions taken since the original posting and the current state of play. In all likelihood these edits will not occur all at once as I have limited time available to post. – Jeff

I’ve read the various threads and elsewhere about running RoonServer on Ubuntu and some conclude happily and others never find a solution other than trying a Fedora or some other Linux. I’m familiar with a variety of *nix systems but, oddly not Linux. So it is very possible that the anomalies I am seeing are due to installation or configuration errors.

I’m posting here first to see if I’ve made any obvious errors or if the issues I’m seeing are well-known and solvable. If that doesn’t yield a solution I’ll put a ticket in for Roon support. Ok so let’s start with the basic environment:

Server Hardware
Previously I ran RoonServer on a Synology 916+ with DSM7.2. However, my Macbook Pro 15,2 developed a broken screen and I decided to repurpose it as a RoonServer. Roon was running on well on the Synology but as I started to use more DSP functions to tune my headphones I could see the load creeping up substantially. I thought the core i7 in the macbook would be great for Roon.

I like MacOS but I do not trust it as 24/7 server OS. Too many software updates requiring reboots for example. After reading the official Roon comments on Linux I chose to install Ubuntu. I may have chosen…poorly.

Updated 4/12/24:

System:
  Host: jeffsubuntuserver Kernel: 6.6.25-t2-jammy x86_64 bits: 64 Console: pty pts/3
    Distro: Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Machine:
  Type: Laptop System: Apple product: MacBookPro15,2 v: 1.0 serial: <superuser required>
  Mobo: Apple model: Mac-827FB448E656EC26 v: MacBookPro15,2 serial: <superuser required>
    UEFI: Apple v: 2022.100.22.0.0 (iBridge: 21.16.4222.0.0,0) date: 02/14/2024
Battery:
  ID-1: BAT0 charge: 46.5 Wh (95.3%) condition: 48.8/58.0 Wh (84.1%)
CPU:
  Info: quad core Intel Core i7-8569U [MT MCP] speed (MHz): avg: 475 min/max: 400/4700
Graphics:
  Device-1: Intel CoffeeLake-U GT3e [Iris Plus Graphics 655] driver: i915 v: kernel
  Display: server: X.org v: 1.21.1.4 with: Xwayland v: 22.1.1 driver: X: loaded: modesetting
    unloaded: fbdev,vesa gpu: i915 tty: 214x27 resolution: 1680x1050
  Message: GL data unavailable in console. Try -G --display
Network:
  Device-1: Broadcom BCM4364 802.11ac Wireless Network Adapter driver: brcmfmac
  Device-2: ASIX AX88179 Gigabit Ethernet type: USB driver: cdc_ncm
  Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
Drives:
  Local Storage: total: 931.84 GiB used: 17.22 GiB (1.8%)
Info:
  Processes: 326 Uptime: 2d 3h 1m Memory: 15.48 GiB used: 2.74 GiB (17.7%) Init: systemd
  runlevel: 5 Shell: Bash inxi: 3.3.13

I installed Ubuntu via the Roon easy install script and that went fine. Check.sh runs successfully. And this system does play music. But it also crashes a couple times a day and restarts which is not good.

A few other fun facts:

No music plays directly on the server
** i.e. the server is not a zone and I don’t rely on linux audio drivers
WiFi is disabled
My initial network setup had the wired adapter connected to my Cisco SG 200-08 8-port switch. Because Roon doesn’t recommend smart switches I have since connected the 1gb ethernet adapter directly to one of the 1Gb ports on my Orbi RBR50 router.
Over the last few days I have also replaced all ethernet cables in my system with new cat6 cables. I had a few older cat 5e cables in the mix and these were removed. In an abundance of caution I also replaced the existing cat 6 cables with new ones as well.
There are 2 wired ethernet adapters available. One uses a RealTek 8153 and the other uses an ASIX AX88179. Currently the ASIX adapter is connected to the network. The reachability issues occur with both the RealTek and ASIX adapters.

Network:
  Device-1: Broadcom BCM4364 802.11ac Wireless Network Adapter driver: brcmfmac
  IF: wlan0 state: down mac: a4:83:e7:8b:d6:89
  Device-2: ASIX AX88179 Gigabit Ethernet type: USB driver: cdc_ncm
  IF: enxf8e43bb75797 state: up speed: 1000 Mbps duplex: half mac: f8:e4:3b:b7:57:97
  Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
  IF: enx00e04c6814bb state: down mac: 00:e0:4c:68:14:bb

The server now has a fixed ip address rather than relying on DHCP
There are 3 zones in use:
** A Bluesound Node 2 connected to the server through the cisco switch via 1Gb ethernet
** An NAD T777v3 connected via ethernet to a Netgear Orbi satellite (RBS 50)
** A WiiM Pro Plus connected via WiFi

All these zones use RAAT as transport. There are also 3 Homepod Minis that use Airplay but I have not attempted to play music in those zones since i moved RoonServer to Ubuntu.

Music files reside on the Synology DS916+ which is connected to the RoonServer via 1Gb ethernet through a Cisco SG200-08 Gb switch. My library is small by Roon community standards with about 9150 tracks. Tidal and Sirius XM are connected services. Roon ARC works correctly and I can access it from outside my network.

Ubuntu Anomalies
For now, I’ll concentrate on just three of them:

Invalid Atom

● roonserver.service - RoonServer
     Loaded: loaded (/etc/systemd/system/roonserver.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2024-03-30 20:26:00 EDT; 5 days ago
   Main PID: 2040 (start.sh)
      Tasks: 112 (limit: 18931)
     Memory: 3.1G
        CPU: 11h 50min 18.652s
     CGroup: /system.slice/roonserver.service
             ├─  2040 /bin/bash /opt/RoonServer/start.sh
             ├─264986 /opt/RoonServer/RoonDotnet/RoonServer RoonServer.dll
             ├─411997 /opt/RoonServer/RoonDotnet/RoonAppliance RoonAppliance.dll -watchdogport=35917
             ├─411998 /opt/RoonServer/Server/processreaper 411997
             └─412043 /opt/RoonServer/RoonDotnet/RAATServer RAATServer.dll

Apr 02 23:38:00 jeffsubuntuserver start.sh[265022]: has mp3float: 1, aac_fixed: 1
Apr 02 23:38:04 jeffsubuntuserver start.sh[264986]: Running
Apr 04 19:16:08 jeffsubuntuserver start.sh[265022]: atom with <8 bytes is invalidatom with <8 bytes is invalidatom wit>
Apr 04 19:16:14 jeffsubuntuserver start.sh[264986]: Not responding
Apr 04 19:16:44 jeffsubuntuserver start.sh[264986]: Error
Apr 04 19:16:46 jeffsubuntuserver start.sh[264986]: Initializing
Apr 04 19:16:46 jeffsubuntuserver start.sh[264986]: Started
Apr 04 19:16:47 jeffsubuntuserver start.sh[411997]: aac_fixed decoder found, checking libavcodec version...
Apr 04 19:16:47 jeffsubuntuserver start.sh[411997]: has mp3float: 1, aac_fixed: 1
Apr 04 19:16:49 jeffsubuntuserver start.sh[264986]: Running

Notice the 3rd start.sh entry: “atom with <8 bytes is invalid” I have no idea what this means or what causes it or if it’s even a problem.But I see this message frequently when RoonServer needs to restart.

Dotnet failures

/var/crash contains this file:

_opt_RoonServer_RoonDotnet_dotnet.0.crash

The first section of the crash log is human readable:

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Thu Apr  4 19:16:08 2024
DistroRelease: Ubuntu 22.04
ExecutablePath: /opt/RoonServer/RoonDotnet/dotnet
ExecutableTimestamp: 1712062388
ProcCmdline: /opt/RoonServer/RoonDotnet/RoonAppliance RoonAppliance.dll -watchdogport=35917
ProcCwd: /opt/RoonServer/Appliance
ProcEnviron:
 SHELL=/bin/sh
 LANGUAGE=en_CA:en
 LANG=en_CA.UTF-8
 PATH=(custom, no user)
ProcMaps:
 55e58a970000-55e58a974000 r--p 00000000 103:03 1969222                   /opt/RoonServer/RoonDotnet/dotnet
 55e58a974000-55e58a98a000 r-xp 00004000 103:03 1969222                   /opt/RoonServer/RoonDotnet/dotnet
 55e58a98a000-55e58a992000 r--p 0001a000 103:03 1969222                   /opt/RoonServer/RoonDotnet/dotnet
 55e58a992000-55e58a993000 r--p 00021000 103:03 1969222                   /opt/RoonServer/RoonDotnet/dotnet
 55e58a993000-55e58a994000 rw-p 00022000 103:03 1969222                   /opt/RoonServer/RoonDotnet/dotnet

etc. It goes on for a while with standard dump info followed by many megabytes of hex dump. I must say that these dotnet crashes are less frequent after the lastest update but they still happen. I have no idea how to track this further.

The Great Reachability Heartbeat

Now for the strangest one of all. I looked at RoonServer logs file over a 3 day period and noticed many, many errors of the type Trace:` [remoting/brokerserver] network reachability changed. Kicking off discovery cycle.’ This is followed by a flurry of network activity that pings every zone and then communicates authorizataion info back to roon labs via api. Over that 3 more than 3 day span I counted the number of “reachabilty” entries in the logs:

updated 4/13/2024

Over the entire span of almost 4 days RoonServer was repeating this discovery process at 60Hz! That just cannot be right! So I looked at the RAATServer logs which actually grow much more slowly than the RoonServer logs. For those I was able to collect data over a longer period of time:

I’m going to end this here because this post is long enough and I’m sure I haven’t included everything that folks may want to see. So if you have any ideas on what could be happening here I would be highly appreciative!

addendum 4/13/2024:
In spite of the actions outlined above, namely:

Tried.2 different ethernet adapters with different chipsets and different drivers
Recabling my entire system to ensure new cat6 cables are in place everywhere
Having the wired connection from my server bypass the smart switch and and connect directly to the Orbi router integrated switch
Replacing DHCP with a fixed IP address

The results are basically unchanged. I still get frequent reachability events at about a rate 1/minute. Roon mostly ‘works’ despite this – music plays well in all zones and ARC works as expected. However I do suffer from Roon restarts that occur approximately 1/day.

Peter_Bruderer · April 5, 2024, 5:38am

Running Ubuntu on Apple Hardware, is that really a good idea?

Apple used Intel chips for quite a while. But it was never their intention to have other OS running on their platform.

You will always have some incompatibilities with Apple hardware. It is not in the interest of the Linux community to waste a lot of time, to reverse engineer Apple’s hardware.

It is not Roon and Ubuntu which are unhappy together.

Jeff_Greenberg · April 5, 2024, 6:38am

Well it’s good idea if that’s the hardware I’m trying repurpose. And Apple did officially support Windows (remember BootCamp?

As for Ubuntu not being the problem, time will tell.

It is not in the interest of the Linux community to waste a lot of time, to reverse engineer Apple’s hardware.

You’d be surprised,

Martin_Webster · April 5, 2024, 8:33am

This means the number of bytes written doesn’t match the declared size.

Nonetheless, the symptoms you are experiencing are most certainly a result of running Linux on a MacBook. I know from experience that it is unsatisfactory, and certainly not recommended for production use, i.e., where reliability is important.

For instance, kernel drivers for the soundcard almost certainly don’t exist, and graphics can be problematic, especially if the MacBook has two graphics cards. The latter, probably is the cause of the .NET issue. Similarly, support for Broadcom is shaky.

These are all symptoms of running Linux (not just Ubuntu) on unsupported hardware.

You’d definately fare better running Roon on macOS. Many community members do this successfully.

Andreas_Philipp1 · April 5, 2024, 9:36am

I agree with @Peter_Bruderer and @Martin_Webster and just wanted to add that whatever the OS you put on that MacBook, if you use it as Roon server, connect it to your network via Ethernet and turn off WiFi.

BTW, I have been running Roon server on Ubuntu server and compatible hardware for nearly five years now, starting with 18.04 LTS, and it’s a good platform.

Jeff_Greenberg · April 5, 2024, 1:36pm

First I want to sincerely thank @Peter_Bruderer , @Martin_Webster and @Andreas_Philipp1 for taking the time to read and add their comments. I really do appreciate it.

Having said that, I’m not convinced we’re on the right track yet. First let me add to Martins comments:

Thanks but written by which component of the Roon software? How would I track down where this originates and find the root cause? I’m still in the dark about this.

I’d be grateful if you could share the source of this certainty. I have no wish to dive further down into a Linux rabbit hole so if you have specific insights into the causes of the errors I’ve posted please share!

As I mentioned in my post, the server audio is not being used. Nonetheless it does work for other system sounds. I just don’t use the server machine as an endpoint. It’s strictly a server. As for graphics, I do have an external monitor connected (along with a usb keyboard and mouse). But >90% of my interaction with the server is via either ssh or occasionally with NoMachine (which i did not previously mention), Something else Ii didn’t mention in my original post is that Bluetooth is also turned off.

By Broadcom, I assume that you’re referring to WiFi. Something I neglected to include in my post is that WiFi is turned off on the server. The servers sole connection to my network is via 1Gb ethernet that runs about 3 feet to the Cisco switch.

I’m not sure how to interpret the word unsupported in this context. Do you mean unsupported by Roon? I didn’t think Roon supported any platforms outside of their packaged server solutions. As for Linux in general, most variants are community supported which is the same for my hardware. There is a Linux community dedicated to supporting Linux (many varieties) on the hardware I’m using. See https://t2linux.org for details.

@Andreas_Philipp1 offers the following experience:

Downgrading to 18.04 LTS is certainly a possibility. I’ve tried to stay current with 22.04LTS because 18.04 LTS loses its 5-year long-term support status at the end of next month [edit: actually LTS ran out for 18.04 at the end of May 2023 not 2024. My bad]. And while your experience with Ubuntu 18.04 is encouraging a brief search will show that there have been mixed results running Roon on 22.04.

That’s what’s so puzzling, Some people find success using 22,04 LTS and others run into a variety of issues that never have solutions (at least solutions posted to the forums where the problems are discussed),

So I do appreciate the speculation regarding the influence of my hardware but I was hoping for insights into the actual errors I posted (thank you @Martin_Webster for addressing the invalid atom issue), In particular what could be causing the suspiciously constant 60Hz network bombardment revealed in my logs?

What conditions trigger the [remoting/brokerserver] network reachability changed. Kicking off discovery cycle' message?
Why is it so regular?
Is this behavior considered normal ? (I do not recall seeing this when running on my Synology)

Thanks in advance.

Andreas_Philipp1 · April 5, 2024, 2:16pm

I said I started on 18.04 five years ago… for the last couple of years I have been happily running on 22.04.

I can’t know to which negative experience you are alluding, but I think that every experience must be evaluated in its own context. The Roon server experience on Linux in general (and not particularly restricted to Ubuntu) was less than optimal, while Roon was still using the Mono libraries and runtime. After porting to .NET (don’t remember exactly when that occurred, but maybe two years ago), things have been rather good.

There were and there still are issues related to increasing memory consumption or file handles increases which apparently are not released, but I am not at all sure that this is an OS-related issue. The good news is that Roon recently has begun to address performance problems, and my impression is that things are getting better. I am running a library with 310 k tracks on a Core i5-8600K and 16 G RAM, and Roon is running rather well…

Edit:

I might add that if you intently peruse the forum threads, you might come to the conclusion that very much the same can be said for near any OS Roon users have been using to run their core server on… this includes Roon Rock and, of course, Windows (10/11) and Mac OS…

That’s what I am referring to when I say that every experience must be evaluated in its own context. All these OS are well suited to run Roon, and if things go wrong as in your case with the network reachability issue, something in the setup is not quite right. I remember having read about network reachability issues in the context of the use of a VPN, but your issue with very frequent log entries to me looks as if there maybe were some network driver issues… but in fact I really don’t know…

I would open a support ticket and ask Roon support for help with the debugging of this issue…

Martin_Webster · April 5, 2024, 3:23pm

Quite simply, Ubuntu doesn’t support Apple hardware. Any attempt to install Ubuntu, or any other distribution, requires a community side project, typically from GitHub, to install the OS (you cannot install directly from an official ISO image.)

As I said, I’ve run Ubuntu on MacBooks, and the experience wasn’t great, and certainly not reliable. Results in the community vary wildly, and most installations depend on community kernel patches etc. Updating can be unreliable.

For Ubuntu running on non-Apple hardware, absolutely not. Linux is the most widely used OS for servers because it is secure and robust.

Incidently, Ubuntu 22.04 has been rock solid for me, although I now run 23.10 on all my machines, and will move back to LTS (24.04) in a couple of months.

I suspect Roon will consider this configuration unsupported, too (in the same way running Roon in a VM is.)

Jeff_Greenberg · April 5, 2024, 3:25pm

@Andreas_Philipp1 I couldn’t agree more.

I may do that but I thought I’d give this thread a few days so others can weigh in. I suspect I’m not the first to see these specific behaviors.

SpicyMusic · April 5, 2024, 8:30pm

I am running Ubuntu 22.04.4 (headless) on some AMD hardware. I just checked and I don’t get more than one of those network issues per file. Have you run a memory test? Have you tried with a different Network Card? I’m inclined to think you might want to run memtest on it. I’ve seen people say it’s best to test with one stick of RAM at a time, but I’ve never done that. If it’s not memory, maybe grep through dmesg for some network related things?

Full disclosure, I have a cron job setup on mine to install updates and reboot every morning as I was getting memory leaks in the past. I’m not sure if that’s been fixed or not, but it doesn’t bother me as it’s only down for like a minute out of the day.

Jeff_Greenberg · April 5, 2024, 8:36pm

@SpicyMusic Good suggestions. I’m not sure a memory test is the first line of attack but I may get there. I have tried 2 different network adapters and the results were unchanged. The nature of these messages is very specific though and it just doesn’t smell like a generic adapter failure. I haven’t posted sections of those logs because they include plaintext personal details that get sent (encrypted) back to Roonlabs as part of the authentication process. I’ll look at redacting the personal stuff and posting more detail on the events. Perhaps looking at more context will shed some light on the situation.

It’s worth re-emphasizing that the server actually works perfectly >99% of the time. I’m listening to it right now and it’s playing beautifully. That’s one reason why I’m not inclined to throw out my entire server hardware as some have suggested. I think the setup is actually really, really close. But there’s configuration error or something similar that I need to find.

Andreas_Philipp1 · April 5, 2024, 9:21pm

Just had a look, too… My logs cover March 28 to April 5, and there are 18 events with

Trace: [broker/accounts] network reachability changed. refreshing

In fact, every time such a log entry occurs, there is a whole bunch of corresponding entries like this:

RoonServer_log.19.txt:03/28 21:44:52 Trace: [broker/accounts] network reachability changed. refreshing
RoonServer_log.19.txt:03/28 21:44:52 Debug: [tidal] network reachability changed. refreshing token
RoonServer_log.19.txt:03/28 21:44:52 Debug: [kkbox] network reachability changed. refreshing token
RoonServer_log.19.txt:03/28 21:44:52 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
RoonServer_log.19.txt:03/28 21:44:52 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, not testing port opening because automatic config is disabled
RoonServer_log.19.txt:03/28 21:44:52 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
RoonServer_log.19.txt:03/28 21:44:54 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle

After this event at 9:44:52 PM, the next event occurred the following morning at 08:57:27 AM…

This I think is expected and normal… I haven’t seen info though on why or when this is triggered…

Jeff_Greenberg · April 5, 2024, 9:37pm

@Andreas_Philipp1 Thanks that’s useful to know. The big clue here is the 60Hz frequency of occurence. That’s not an accident. It’s either a system scheduler, an internal roon scheduler or network errors induced by 60Hz powerline noise. That last possibility is testable and I’ll work on that tonight.

Andreas_Philipp1 · April 5, 2024, 9:45pm

This I don’t think is quite right… 60 Hz implies 60 events per second, but if I interpret your tables from your original post right, it’s about one event every 60 seconds…

Jeff_Greenberg · April 5, 2024, 10:54pm

@Andreas_Philipp1 Of course! Mea Culpa you are correct. This is what happens when I analyze logs at 3AM . So no power line testing for me tonight! But even as 1/minute rate indicates some non-random scheduled process. The big question is what scheduler is actually driving this?

Andreas_Philipp1 · April 5, 2024, 10:59pm

You’re right, this isn’t random, but I’m not so sure it is a scheduled job… I’d rather talk about something which triggers these events roughly every minute… Only Roon staff will have a more precise idea what it is that can trigger this … which might bring you closer to discover the culprit on your system or network…

Fernando_Pereira · April 6, 2024, 12:22am

Ubuntu network configuration & management is quite complex, and it depends on well-functioning device drivers. My guess is that the network driver is regularly dropping the carrier, causing the network reachability issue. Since Ubuntu does not officially support Mac Intel hardware, I’m not surprised.

Andreas_Philipp1 · April 6, 2024, 12:54am

Yes, that is my guess too, and I hinted at it in a previous message on this thread.

If this were the case, would a supported USB Ethernet interface be a possible workaround for the OP?

I would try something like this:

https://www.amazon.com/TP-Link-Foldable-Gigabit-Ethernet-Compatible/dp/B00YUU3KC6/

A quick check on Google suggests that most adapters will work on Linux, especially those with a Realtek chip. Avoid those with Broadcom chip…

Jeff_Greenberg · April 6, 2024, 6:01am

I know this is TL;DR but I don’t have time tonight to edit this stream of consciousness post. Apologies in advance.

@Andreas_Philipp1 & @Fernando_Pereira It is possible that this is an ethernet adapter issue as you suggest. I have tried two different adapters and experienced issues with both of them. In particular the RAATServer logs that span over 18 days included both adapters and yet the frequency of reachability events was unchanged. It wasn’t a controlled experiment though – I had not focused on the reachability events until recently so I do not have record of exactly when I changed adapters.

Note that the adapter I’m currently using is based on the same RealTek 8153 chip used in the Amazon link. The ad extols the compatibility of this adapter with Linux and Ubuntu specifically, yet a crude search (Google realtek 8153 ubuntu) reveals that the 8153 is not always trouble free. I know this because I spent hours looking through these posts a week ago trying to determine if better/newer drivers are available for the 8153.

None of the reported issues are specific to Apple hardware. In fact the most commonly reported issues are with power management and system sleep states on many types of systems. You’ll find a variety of recommendations for kernel tweaks that may or may not help. I’m not confident enough around Ubuntu to feel safe implementing any of these tweaks and their track record is mixed – works for some, others say no it doesn’t work at all.

Issues seem to extend to the 8152 as well and Ubuntu identifies my adapter as 8153 but uses the 8152 driver. I found source code for an 8153 driver (supposedly from RealTek but I can’t find the link and I’m tired) but the author driver described it only as a stopgap for situations where the 8152 driver could not be used – implying that the 8152 driver is correct.

Have a look at Bugzilla to see issues begining in 2018 and contnuing as late as last month.

This is a long winded way to say that I cleared up many of my adapter issues once I changed power management to deny sleep no matter the battery or attached charger state. That seemed clean up a great many issues. But I did this at high level through the GNOME settings interface and it may be that not all parts of the power management system are disabled.

So I will try different adapters – the one @Andreas_Philipp1 suggested along with its native usb-c implementation (eliminates having to use another usb-c/usb-a adapter). I can always return one or both if they don’t work.

Now I’m off traveling to place my self in the path of totality for Monday’s total eclilpse of the sun. The very center of totality runs right over the house where I was born ( and where I’ll observe the eclilpse, weather permitting!)

Thanks for the help so far!

Martin_Webster · April 6, 2024, 8:20am

Can’t you eliminate the power line, and use Ethernet, to see if things improve? At the best of times theses devices aren’t entirely reliable.