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
[email protected]
