[PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)

[Russell Senior]

Random observations follow:

I received another PBE-M5-400 feedhorn today.

It arrived with XW.v6.1.4 installed.

Using its GUI, I tried directly flashing a recent master branch
OpenWrt with my support commit on top and it complained with a
"firmware image check failed".

Using the v6.1.4 GUI, I downgraded to
XW.v5.6.15-sign.31612.170908.1440.bin. That was accepted and the
device rebooted into v5.6.15.

Using the v5.6.15 GUI, I tried to flash my same OpenWrt image and got:
"This firmware is not trusted by airOS. To maintain security, it will
not be loaded. Please load trusted firmware."

>From those observations, I infer that reverting to 5.5.x is still
needed to use the GUI to flash. Reverting to 5.5.x still requires some
ssh'ing and scp'ing, but it does not require TFTP, and might still be
a desirable path for people allergic to TFTP for whatever reason.

I also tried directly TFTP flashing from v6.1.4 to my openwrt factory
image and confirmed that worked.
When I tried TFTP flashing from v6.1.4 to v5.5.10-u2, I got the
message: "Error code 2: Firmware check failed".
When I tried TFTP flashing from v6.1.4 to v5.6.15 (unsigned), that
succeeded, (the uboot partition /dev/mtdblock0 had the same md5sum
hash as on v6.1.4), but from v5.6.15 (unsigned) I could scp v5.5.10-u2
to /tmp/fwupdate.bin and use the built in fwupdate.real to update:

XW.v5.6.15# fwupdate.real -m fwupdate.bin
Current ver: 329231
New version: 328970
No need to fix.
Writing 'u-boot         ' to /dev/mtd0(u-boot         ) ...  [%100]
Writing 'kernel         ' to /dev/mtd2(kernel         ) ...  [%100]
Writing 'rootfs         ' to /dev/mtd3(rootfs         ) ...  [%100]
Done

Then you can ssh into v5.5.10-u2 (with a relaxation of modern ssh key
exchange algorithms):

 $ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ubnt at 192.168.1.20

and confirm the md5sum of the u-boot has changed:

XW.v5.5.10-u2# dd if=/dev/mtdblock0 | md5sum
512+0 records in
512+0 records out
753d74c53339edfd8f8289e772f5abeb  -

and you won't have any pesky "Firmware checks" anymore, if you need that.

I also did some experiments with the current firmware v6.3.2. It has a
yet again different u-boot md5sum, and for as-yet-unknown reasons I
started to have trouble connecting with it at 192.168.1.20. I have
some packet captures that suggest it's trying to phone home,
requesting DHCP and so forth. On an isolated network, I was able to
TFTP directly from v6.3.2 to my OpenWrt firmware. I'll continue
experimenting, but I don't see any of this as a reason to hold up
merging the support-adding commit.


On Mon, Jun 14, 2021 at 1:05 PM Russell Senior
<russell at personaltelco.net> wrote:
>
> On Mon, Jun 14, 2021 at 6:54 AM Joe Ayers <joe at ayerscasa.com> wrote:
> >
> > > > I'm having a bit of heartburn with continuing with these instructions:
> > > >
> > > > > Flashing via stock GUI:
> > > > >  - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
> > > > >    https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
> > > >
> > > > This issue was resolved with:
> > > >
> > > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc
> > > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2
> > >
> > > Those commits resolve the problem for TFTP, but if people want to use
> > > the GUI, they still need to downgrade, right? Both instructions are
> > > included in the commit message. Note that the TFTP instructions don't
> > > mention downgrading.
> >
> > I remember flashing via the stock GUI in AirOS v5.6.? had worked.  As
> > I recall, firmware signatures were not required until a future AirOS
> > version .   If so, downgrading shouldn't need to occur all the way
> > back to v5.5.10-u2.  The AirOS release note history should tell us
> > when firmware signing was introduced.  I'm sorry, I don't have time
> > available to substantiate right now, to make sure my memory is
> > correct.
> >
> > Would anyone ever follow the GUI flash with all the steps, when 1 tftp
> > flash works?    I suspect there is no impact regardless, might just
> > move forward, not worth the time.
>
> No one seems to have tried all the starting condition possibilities, I
> certainly haven't. If we were being crushingly complete in testing, we
> would try every one of them. If we knew how likely each starting
> condition is, we could even weight our instructions accordingly. Given
> that serial access is not easy right now, because of not being able
> (at least I'm not able) to non-destructively open the feedhorn
> enclosure to get access to the serial console pins, I'd rather not
> risk trying an AirOS that might make it impossible to recover. Given
> that this is *JUST A COMMIT MESSAGE* and not a mutable, improvable,
> instruction (which should live on the wiki anyway), it seems to me
> reasonable to accept being a little conservative in the instructions
> here, even if some of the steps turn out to not be strictly necessary.
>
> --
> Russell Senior
> russell at personaltelco.net