The iPhone 17 Event
This time I actually forgot to watch the live event.
I’m now fully back to work, so there hasn’t been any free time for anything but finishing overdue posts. I have, however, managed to sneak in a few leisurely half-hours in the mornings reading work e-mail from my balcony before my calls start, which has been a great way to enjoy the lingering summertime.
I am, however, pretty certain someone will spoil that for me with more project management calls any day now.
Nevertheless, I’ve spent a few hours this weekend trying to get DaVinci Resolve and KDEnlive to work via RDP inside my Proxmox cluster (for science!) with… dramatic results.
Resolve (which has a reputation of being fiddly in Linux overall) crashed the NVIDIA drivers and the Proxmox host several times, but KDEnlive actually ran surprisingly well with just VAAPI and Intel QuickSync—and it was able to do so directly on my NAS, which saves me time and energy managing video clips and assets.
I have a vested interest in doing video editing “remotely” because my Macs (especially my desktop Mini) don’t have enough storage for handling videos, so this was an interesting experiment. But I suspect I will eventually fire up Final Cut Pro and investigate how good the UX is with network-mounted media (the workarounds I knew about used to require setting up sparse bundle images in the NAS, which is just stupid).
I can always revisit the notion of paying for it again on the iPad and get a Thunderbolt SSD, but… why?
Lack of free time to do my projects is one thing, but my evenings are still manageable, so I was somewhat surprised that Foundation ended the season in such a weird way (fine, we all know it’s not canon Asimov, but still… some plot twists just don’t make sense) and pleasantly amused with the end of this season of Strange New Worlds, which is well on its way to be the best modern Trek (although that isn’t hard given recent history).
I’d watch a full original series reboot if this trend keeps up.
As I’ve been writing about once or twice, I’ve recently upgraded my Wi-Fi after an attempt to use ISP-provided equipment to replace my remarkably long-lasting (and extremely reliable) Airport Extreme base stations.
The short of it is that I ended up getting a few Cudy M3000 and setting up OpenWRT on them:
Disclaimer: Although I sought out (and paid for) several M3000 units myself, I’m following my standard format and review policy for consistency, since this is more or less a “review”.
The long of it has been a somewhat fun journey, so here’s the full story.
In case you’ve landed here without any context, I recently switched ISPs and the initial configuration included a set of Wi-Fi 7 extenders to replace my (very) long-lived Airport Extreme base stations.
This was a somewhat protracted thing and I had plenty of time to lay down the groundwork by upgrading my LAN to 2.5GbE Ethernet with a few 10GbE ports, but after a week of living with the system I decided I wanted something I could manage myself due to a bunch of management restrictions and outright compatibility problems I could not re-configure it to overcome, because everything is locked out by my ISP.
My functional requirements were pretty clear:
And the M3000 doesn’t look half bad compared to an Airport Extreme, so that was definitely a reason for me to take a second look (they come in black too, but the white ones were drop-in replacements for the Airports in our decor).
Technically, I had a few more requirements:
OpenWRT was not really a requirement, but since my first-ever Wi-Fi access points were indeed WRT54G devices and I have a long history with it, that’s where I started my research, and Cudy hardware had quite a few positive references.
Moreover, they actually provide instructions on how to re-flash their devices with OpenWRT, and there is an upgrade path to the currently supported version (as well as a likely runway of official OpenWRT support for a few years at least), so they soon rose to the top of my list.
The factory firmware is actually very nice, and makes an excellent job of exposing all of the features as well as guiding users through initial setup of the devices either as a router or as an access point in various configurations:
I didn’t run it for long, but it seems to do a very good job of exposing both OpenWRT core functionality and the additional features Cudy added. Although I didn’t install their app or tried to manage it remotely, I’d say most people would be well served by the factory firmware.
But my objective was to make sure I had full control of the hardware and run these on the latest vanilla OpenWRT, so there were a few more steps involved.
The first thing I needed to do was unlock the factory firmware. The white/grey devices I have are “V2” hardware, but Cudy themselves say that the firmware is identical to the V1 (which is black with red trimming) and provide a vanilla OpenWRT 23.05 image, so I started out with that.
The Cudy support page links to their Google Drive, where you can download the M3000 V1.zip
file (for both V1/V2).
That ZIP file contains a Windows version of tftpd
(which is an extra nice touch, even if it triggers a bunch of virus warnings), a comprehensive set of instructions for Windows users in a PDF and a few firmware files, which we’ll get to in a moment.
To get the latest supported firmware, I went to the OpenWRT Firmware Selector and looked for the Cudy M3000, downloading the latest sysupgrade
file. I downloaded 24.10.2 (r28739-d9340319c6)
.
I then set up tftpd
on one of my Fedora laptops (because, I don’t have personal Windows machines anymore) and wired it up to the LAN port on the M3000.
To enable it to get at the recovery.bin
file via TFTP, I copied that file to /var/lib/tftpboot
, set my laptop to IP address 192.168.1.88
and restarted tftpd
.
I then held down the power button on the M3000, plugged in the barrel jack, waited until the lights settled (solid red in my case) and then reset my laptop to use DHCP, because the next step is to log in to the (now unlocked) Cudy web UI at http://192.168.10.1
.
Once you’re there, go to Advanced Settings/Firmware and upload cudy_m3000-v1-sysupgrade.bin
(checksum d09cdb39e9544b1d33a4daf28964c50b
), which is also provided in the ZIP file.
This gives you a vanilla OpenWRT 23.05 install, and you then go to http://192.168.1.1/cgi-bin/luci/admin/system/flash
, upload the 24.10.2 file and… you’re done.
192.168.1.88
.tftpd
with the recovery.bin
file in /var/lib/tftpboot
.192.168.1.88
to DHCP.http://192.168.10.1
), go to Advanced Settings/Firmware and upload cudy_m3000-v1-sysupgrade.bin
(d09cdb39e9544b1d33a4daf28964c50b
).http://192.168.1.1/cgi-bin/luci/admin/system/flash
and upload the 24.10.2 sysupgrade image.I initially got a standalone unit to test and then bought a 3-pack and another standalone unit (to keep as a cold spare), so I had a working configuration I could use to set up the new nodes way before I got them all.
Over that initial week with the first unit, I sorted out all of the details:
br-lan
bridge to allow pass-through (this way I can plug an Apple TV or similar directly into the gigabit port)rsync
and luci-app-statistics
to play around with configuration files and monitoring802.11ax
data rates (I also punched up the channel width to 160Mhz and set up 802.11r
for faster hand-overs)This bit is probably the most interesting for everyone, so here’s a redacted version of my initial /etc/config/wireless
:
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/18000000.wifi'
option channel 'auto'
option band '2g'
option htmode 'HT40'
option legacy_rates '1'
option country 'PT'
option cell_density '1'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'my_ssid'
option encryption 'psk-mixed'
option key 'my_key'
option ieee80211r '1'
option mobility_domain 'dead'
option ft_over_ds '0'
option ft_psk_generate_local '1'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/18000000.wifi+1'
option channel 'auto'
option band '5g'
option htmode 'HE160'
option cell_density '1'
option country 'PT'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'my_5GHz_ssid'
option encryption 'sae'
option key 'my_5GHz_key'
option ocv '1'
option ieee80211r '1'
option mobility_domain 'beef'
option ft_over_ds '0'
option dtim_period '3'
To set up the other nodes, I just uploaded the first one’s configuration backup, changed the hostname and IP address (given the vagaries of our new home gateway, I opted for static IPs) and plugged them in.
My iPhone and MacBook Pro can both do 1.2 Gbps down / 1.5 Gbps up within 2–3 meters of any of the access points when connecting to our internal OpenSpeedTest instance—which I’m hosting on one of my TerraMaster’s 10GbE interfaces:
Running a second simultaneous test gives obviously lower (but similar) individual results and maxes out the 2.5GbE uplink, so I would say this is about as good as it’s ever going to get, since I suspect that even if we were using Wi-Fi 7 and 6GHz, physics and the 2.5GbE backhaul would start factoring in.
Again, this is in a pure “flat” configuration, with all physical interfaces and radios set as part of the br-lan
–no routing is taking place, and no layer 3 handling is happening.
Our staple latency test (streaming games using Steam Link from a 2.5GbE server) is buttery smooth, but then again it was already good with the Airport Extremes (you only really need 30-50Mbps for crisp 1080p streaming), and the Logitech G Cloud (which, ironically, has worse Wi-Fi than any of our iPads) works perfectly.
But I’ll let the data speak for itself:
This is the same kind of performance I was getting with the Wi-Fi 7 extenders from my ISP, but:
So I’m calling this a success performance-wise.
There is some occasional flip-flopping between access points, but that only happens in Linux and in places where coverage has strong overlap, so I’m not worried about it (I can always turn off 802.11r
if it becomes a nuisance, and I consider it an experiment, not a requirement):
Looking at the logs from both APs involved it seems to be a client issue:
Sun Sep 7 09:50:00 2025 daemon.notice hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: did not acknowledge authentication response
Sun Sep 7 09:50:46 2025 daemon.notice hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: did not acknowledge authentication response
Sun Sep 7 09:50:48 2025 daemon.info hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: associated (aid 5)
Sun Sep 7 09:50:48 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED a6:a8:e5:87:20:d0 auth_alg=sae
Sun Sep 7 09:50:48 2025 daemon.info hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 WPA: pairwise key handshake completed (RSN)
Sun Sep 7 09:50:48 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED a6:a8:e5:87:20:d0
Sun Sep 7 09:54:34 2025 daemon.info hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: authenticated
Sun Sep 7 09:54:45 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED a6:a8:e5:87:20:d0
This hasn’t recurred, but I will be keeping an eye on things–and if you want to dig deeper into 802.11r
configuration, this great page has a bunch of detail on it.
So far there haven’t been any unexpected behaviors, and since I am not using band steering (which you can add by installing usteer
or dawn
and their corresponding luci
packages, by the way) everything’s been fine with my legacy devices.
While I was going through this process, I got a bunch of feedback from people online:
802.11r
anyway but see no need for it.luci-app-statistics
via collectd
is a wheel that’s already been invented, so I don’t need a controller for that.All in all, I don’t even need the LuCI web UI, and if I need to test a complex configuration I can hack something together with ssh
and ansible
for reproducibility in around 30 minutes.
The Cudy AX3000/M3000 models make for pretty great Airport Extreme replacements, and in this age of networking devices with cloud features nobody asked for OpenWRT turns them into very nice locally managed access points that I will never have to worry about again (until I break the configuration myself, of course).
Although it is much too early to weigh in on hardware reliability (some of the 802.11ac
Airport Extremes I was using were manufactured over a decade ago), the price/performance ratio is great, and right now I don’t mind it not being Wi-Fi 7.
After all, it took almost ten years for the 2.4GHz band to become saturated in my building, and it doesn’t look as if the 5GHz band is going to be massively swamped anytime soon, so I’m expecting something like 3-4 years of hassle-free operation if the hardware holds up.
A relevant thing I should point out again is that people who have less need for low-level control might actually be fine with the stock firmware—I did not use it extensively (nor did I try the Cudy app or any of the router/firewall features), but it already exposes a lot more functionality (and seems a lot more flexible) than ISP gear, so I would encourage people to give it a go.
I suspect I will eventually come across some OpenWRT corner cases as I succumb to the temptation to fiddle with the configuration a bit more, but given our particular situation there’s a very high chance these will just fade into the background and “just work”, which was the ideal outcome that Apple pretty much nailed with the Airport Extremes…
A great visual walkthrough that reminds me I still don’t get how Apple can ship it looking like this. Like I said [earlier](blog/2025/09/09/2200:
If “design is how it works”, then Apple hasn’t really tested any of their upcoming releases.
I want the improved QuickSilver-like Spotlight, but I don’t want my desktop to look this bad—-even if they’ve toned down Liquid Glass to be a set of incoherent visual sprinkles, the overall design is just bad.
It’s also worth noting that Tahoe is the last version to support Intel Macs. Not that I’ve dabbled in hackintoshes in the past few years, but it’s still remarkable they supported Intel this long.
The way Apple has pretty much set the Watch Series apart from the SE is by shipping more health features, and this is a nice one for them to target, especially considering they bothered to make it available to older devices as well and are targeting to ship it pretty much worldwide.
I think a lot of people are going to be interested in this (I’m lucky enough to be reasonably sure I don’t have hypertension, but most people my age have some sort of concern around it).
Of course, like all things in this space, a lot of the actual measuements need to be taken with a grain of salt (HR and Afib have been spot on over the years, but sleep tracking and other things that, like this feature, rely on indirect inference from sensors designed to do other things naturally have difference confidence intervals).
I trust Apple more than anyone else to handle the data for this (given that processing will happen on-device), but I wonder how far we are from the dystopia where insurance companies are going to start asking for access to this kind of data when negotiating policies…
(I don’t like linking to The Verge ever since they went full-on paywall+subscriptions, but the gist of the matter is still readable and it was the first place I saw this.)
As regular readers will know, I am quite fond of the various Ryzen APUs that have hit the market over the past couple of years, and I take a look at them whenever I can, since they have proven to be quite popular options—partially because of the high core counts and partly because of their increasingly powerful iGPUs.
This time I actually forgot to watch the live event.
Summer break is now completely over, so I did my usual Summer “cleansing”—disabling notifications from annoying apps, unsubscribing from a few more online services, ditching a half dozen YouTube channels, and (surprisingly) keeping my Twitter/X account afloat. I also poked at BlueSky with a metaphorical stick, only to find it very much alive.
It’s been a pretty crowded couple of weeks—the most intense part of summer break: a few days at the beach, some in the countryside, plus plenty of walking and reading.
The 3D printing world has been abuzz over the past couple of weeks with this, and after watching pretty much all the (p)reviews I could find on YouTube, I’m very curious to see what the final product will perform like, and how reliable it’s going to be.
Their Kickstarter has pretty much gone through the roof (I find it quite tempting myself), and multi-material printing without the piles of waste associated with single-nozzle devices is clearly something people want–plus the price point is way more accessible than, say, Prusa (ok, fine, that’s a low ball).
I’m going to be watching this carefully over the next few months. The U1 isn’t a perfect fit for me as is since I’ve started using “harder” materials, but I do need something that can handle at least two materials for some of my projects, and on paper, this would be almost perfect with a top lid.
Late to the party on this, but still…
The new Android security measures are an interesting piece of revisionist thinking—“developer verification” is now set as the gatekeeper for sideloaded apps in Brazil, Indonesia, Singapore, and Thailand by September 2026, with what looks like full side-loading lockdown coming 2027.
Regardless of the malware angle, this seems to effectively kill side-loading on Android in the near future, making it as hobbyist-hostile as iOS and very likely spelling doom for open ecosystems like F-Droid (which I rely upon to customize every Android device I get my hands on).
As someone who’s been doing Android development on the side for decades because Apple still doesn’t allow you to run your own software on the devices you own without stupid restrictions, this is very annoying, and a good reminder that regulators like the EU have been focusing on entirely the wrong things.
I wasn’t going to go anywhere near this because it is too close to actual politics for my taste, but Ben Thompson’s take on the U.S. government’s 10% stake in Intel is a great read.
A heady mix of long-term manufacturing woes and geopolitics, it still manages to raise a few skeptical eyebrows as it lays out how decades of strategic missteps have left Intel trailing behind rivals like TSMC, while also highlighting how chip production isn’t something you can fix overnight.
Nor, should I add, the actual success of their products—their top consumer CPUs have been plagued with issues over the last couple of years, and, rather ironically, their most successful products (by volume) are the new low-end Alder Lake chips that have been quietly flooding the Mini-PC market, even as AMD take the most profitable niches.
There’s a dry wit to Ben’s critique—government intervention might be the “least bad” option, but it’s hardly a cure, especially when national security and commercial realities clash and government itself is going through a credibility crisis.
I don’t think Apple understands how badly they’re messing up in regards to visual design in their latest crop of operating systems.
There’s a degree of nostalgia, sure, but nobody on the planet can disagree that Apple’s current design team seems to have completely lost the plot where it regards both respecting the history of their operating systems and… well, just doing something that doesn’t look like it was phoned in.
I just don’t feel like Apple actually cares about the quality of their software experience any more, and am happier and happier that I’ve been running GNOME alongside as my possible future desktop. And let me tell you, a world where Linux is at least as good as polished as macOS is not science fiction anymore.
I’ve spent most of the past couple of weeks using my M1 iPad Pro, and have some follow-up on the iPadOS 26 beta that might be interesting.
I always loved Pez, and this seems like a wonderfully well crafted game. There’s a resurgence of interest in retro computing, yes, but what I like the most are “backports” and entirely original software created for 80s hardware…
Most of the week was spent rummaging through storage to get rid of obsolete hardware and troubleshooting ISP and Wi‑Fi issues, so there isn’t a lot of interesting stuff to report.
Josef Prusa dissects the current state of open hardware in desktop 3D printing in blunt terms (and yes, the headline really tells you everything). As someone who got into it back in the early, heady days of Maker Faires, this was a sobering read.
He walks through how a once-vibrant scene has been stifled by a flood of patent filings since 2020, and it’s rather ironic (even if you have been in the tech game long enough) that an industry built on sharing ideas is now toothlessly battling a patent minefield.
Pragmatically, and although there will likely always be a post-market or DIY angle, I think the mainstream of 3D printing is now squarely about selling semi-closed appliances–and I might be getting one myself.
Even though my current preferences in the “Intel” space actually lean towards AMD, I’ve been keeping an eye on industrial x86-64 for a while. But not too closely, so I was pretty surprised to get my hands on a LattePanda Mu, and it feels like a fresh take on the entire compute module concept.
It’s been pretty much impossible to go anywhere online without stumbling onto the Framework Desktop this week, but DHH’s take is more interesting than all of the gaming and AI fanfare around it because of its pragmatism.
Like I pointed out back in February, the Strix Halo iGPU and its unified memory architecture make it a very compelling setup, and even if [Jeff Geerling’s clustering antics are a bit over the top, the fact that we can now tweak VRAM allocation under Linux makes this a very viable alternative to a Mac Studio for me.
I’d love to review one, but I don’t think Framework even knows I exist…
After all, why should anyone pay four times as much the going rate for equivalent RAM and storage in something that can have a broadly similar power envelope?
I’ve been wanting to get my hands on one of these for both the ability to run local AI workloads and silent, power-efficient operation–and now that the Linux support is coming in the prospect of running a Fedora desktop on this kind of hardware is appealing enough for me to consider dropping macOS–I’ve spent the past few years slowly hedging my platform bets, and other than Mail.app and random compatibilty hassles, it wouldn’t be much of a change.
In the long run, APUs like this are the future for PCs of any size. Apple will of course keep improving their silicon, but the premium they charge for memory and storage makes no sense when AMD can match most of their performance for nearly half the going rate.
I got COVID (again) this week, which made it a hard slog to go through work hours (which I trimmed a bit) and pretty much impossible to do anything. And yet, I sort of persevered.
Let’s say that you need to resolve .local
addresses from either another subnet or a VPN of some sort. Since mDNS uses multicast on a local LAN segment, that won’t cross subnet boundaries and is generally impossible without workarounds most people don’t want to deal with (including me).