[PLUG] January speaker?
Ted Mittelstaedt
tedm at portlandia-it.com
Thu Dec 19 18:20:52 UTC 2024
Excellent response that agrees with everything I've run into over the years of using DD-WRT.
With the Broadcom-based stuff I've -never- run into a factory tftp server or CFE (Broadcom's bootloader) that permits you to overwrite the bootloader. You can only overwrite the CFE once you get the device running dd-wrt, or openwrt. (even fresh tomato does not have the
Tools to allow this, apparently, in it's distributions)
So I was a bit floored when first dealing with TP-Link recovery tftp servers which on many of those devices seem to merely do a complete overwrite of the entire flash chip, including uboot. Talk about a hack and a half.
The problem is that the CFE bootloaders (for Broadcom) and the uboot bootloaders (for Atheros, Mediatek, etc.) that the factory puts in are mostly horrible crap. A good bootloader would give you a 5 second pause on boot where you could use a TFTP client to push an image and it would only write the image to the linux partition. That would literally cover every possible factory recovery scenario or dd-wrt or openwrt or freshtomato conversion routine. Even better would be dumping the entire flash contents, including bootloader, art partition, etc. on the thing if the tftp server available during the 5 second received a get command for a specific filename.
But alas, common sense seems to be absent the authors of the firmware for these devices. These manufacturers really seem to hate the idea of us scraping their crap off the device.
Ted
-----Original Message-----
From: PLUG <plug-bounces at lists.pdxlinux.org> On Behalf Of Russell Senior
Sent: Thursday, December 19, 2024 9:43 AM
To: plug at lists.pdxlinux.org
Subject: Re: [PLUG] January speaker?
On 12/19/24 07:00, Ted Mittelstaedt wrote:
> Unfortunately I had a conflict the evening when you did your OpenWRT presentation (and I've looked for a link to a video of it) but I don't think the OpenWRT topic is dead by any means. Here are some issues that I doubt were covered but would be interesting - at least, to me:
Michael Dexter is the only one video'ing meetings and he's been AWOL since I got us back into PSU. So, no video. If someone wants to take on that task, that would be great. I'm not that someone.
> OpenWRT is heading towards a major release - 24, from the current release 23. How risky will it be to do a version upgrade via the webinterface? I ran into this with some devices with past major version upgrades - the only fix for those was using the tftp server in uboot to do the upgrade - fortunately for the device in use, I didn't have to open it.
>
> Is there a compelling reason to move to 24? Are there key features/advantages to it?
I am a bad source of information about OpenWrt releases, because I
generally don't use them. To me, every commit is a release and I build
from source. I do that primarily because I have a fleet of 100+ devices
and I want to flash them remotely and have them come up already
configured for their environment and context. And so that people can
"factory reset" them back to a working, reachable state.
If you are clinging to old hardware, there is a reason NOT to upgrade:
the upgrade will have a newer kernel and every kernel gets bigger and
therefore fits comfortably on fewer devices.
The reason to upgrade is basically to get new features or better
debugged features in newer kernels. That might include improved wifi
drivers. Someone recently quipped that the reason to upgrade is to
exchange old bugs, which hopefully got discovered and fixed, for new
bugs that probably haven't been discovered or fixed yet.
I build from the development branch frequently. My rationale is that I
find breakage in support for hardware I care about when it is still
relatively fresh in the minds of the people who broke it. If you let a
few years go by, no one is going to remember what they were thinking
when they broke something and there is a lot of work in tracking down
the change that introduced the breakage. It is just a lot easier to get
things fixed if you can report them quicker.
> There is also this advisory:
>
> https://openwrt.org/advisory/2024-12-06
>
> Which the response seems to have been glossed over or handwaved - yes, they "fixed" it - but - it doesn't appear to be a vulnerability in the distributed firmware images themselves, thus I really question why it was even given the status of a security advisory at all.
I hadn't seen that. From my reading of the advisory, there was a
vulnerability in a firmware generator the project provided. It sounds
like it could have been exploited to contaminate firmwares that
unsuspecting people might have subsequently downloaded. It looks like
that advisory was just to put people on notice that, if they used those
firmwares, they might want to take steps to replace them.
> And speaking of Sas, more ominous:
>
> https://www.msn.com/en-us/money/markets/u-s-weighs-ban-on-chinese-made-router-in-millions-of-american-homes/ar-AA1w51es?ocid=msedgntp&pc=U531&cvid=80581ad4bfb740acb86febe3a64ee658&ei=46
I've discovered that people making these kinds of decisions rarely
consult me. I agree it's dumb. I'll worry more about it if/when it
happens, or if there is a particularly auspicious opportunity to yell at
people making dumb choices.
> Lastly,
>
> For my own projects, I have come to understand that there's a lot more issues with the more advanced flashing of devices like the Cisco MR52 - maybe it's my fate to trigger border cases, but here's the summary of my latest failures with that device:
>
> https://forum.openwrt.org/t/help-in-setting-up-a-meraki52/218232/7
Pretty much *every* device has its particular fiddly installation
procedure. Each vendor randomly makes choices that have to be worked
around by people and their third-party firmware. After a while of seeing
the broad spectrum of possibilities, you begin to notice the common
patterns and develop an intuition. OpenWrt policy is that pull requests
for adding support for new device should have installation instructions
in the commit message.
Key things:
* MAKE A COPY OF THE ORIGINAL FLASH CONTENTS, before you change
anything. This has a good chance of saving your ass if something goes
wrong. You can often do that by TFTP'ing a kernel-initramfs OpenWrt
image to memory and booting that without flashing, giving you a set of
tools that might not be available in the vendor firmware. Sometimes you
can log in to the vendor firmware and dd the /dev/mtdblock* partitions
to a tmpfs and then exfiltrate them. Sometimes you can get to a
bootloader console and dump hex to the console and capture that to a
file (over hours) and then use xxd on the tidied up dump to reconstitute
the flash image. You can use dmesg to discover the partitioning
(/proc/mtd is useless for that, though people often mistakenly think
otherwise). You can also often read the SPI-NOR flash with an SPI
programmer and flashrom or flashprog. Whatever the method, it can save
you throwing the device away. Label your archived version with the
device MAC address printed on the case, so you can associate the backup
with the particular device.
* If you don't have to change it (and sometimes you do), leave the
bootloader alone. You can almost always recover with a serial console if
the bootloader is intact.
* I kind of don't like magic scripts that do the fiddly bits for you,
because you end up not understanding what just happened. You can,
sometimes, read the script and then do the steps manually to better
understand what's going on.
> I now have a FTDI 3v USB console cable on order and will re-test when that arrives, but my jaw dropped when reading:
FTDI is the gold standard, assuming the chips are authentic. If you paid
less than $20 for it, the FTDI chips might be counterfeit. I have a few
FTDI's cables, but I need a bunch of them, and I can't afford to spend
$20 a pop, so I get cheaper ones.
> "Speed 115200 is not a problem when the wires are very short."
>
> I am really struggling with how to answer that extreme an amount of just flat out wrongness information without doing a deep dive into handshaking lines. RS232 serial communications - you gotta love it. 1960s' era communications technology built before most techs were even born - yet still with us in the weeds, and still screwing techs over today the same way it was 40 years ago. Yet working with it brings back fond memories of the CBBS scene of my high school youth, and dialup modems....
Embedded linux devices, like the ones supported by OpenWrt, rarely have
handshaking lines exposed. I have never had any trouble with 115200. I
have used cheap-ass Prolific PL2303 usb-uart adapters (the $1.97 devices
from China), where the chip is in the USB connector and the wires are a
few feet long. I would not worry about handshaking or wire length unless
you are trying to do something crazy long.
--
Russell Senior
russell at pdxlinux.org
More information about the PLUG
mailing list