[PATCH] realtek: fix ZyXEL initramfs image generation

[Sander Vanheule]

On Sat, 2021-10-30 at 10:38 +0200, Bjørn Mork wrote:
> Sander Vanheule <sander at svanheule.net> writes:
> 
> > I wanted to verify that your patch fixes OpenWrt flashing, but V2.60(AAHH.4) on
> > my
> > GS1900-8 actually accepts images with bogus trailers.
> 
> This is so strange.  I just went through my notes from the experiments
> on my first GS1900-10HP, and they confirmed what I suspected: I did
> upgrade the OEM firmware on it to V2.60(AAZI.2) before trying to load
> OpenWrt via the web GUI.
> 
> My first attempt installing an OpenWrt image from the V2.60(AAZI.2) GUI
> failed with the message
> 
>  "Device only can support firmware from V2.10(AAZI.0) and later version"
> 
> I guess ZyXEL could have intentionally relaxed this between V2.60(*.2)
> and V2.60(*.4), but I really don't see any good reason for them to do
> that...
> 
> Note in particular the minimum OEM version requirement.  This is
> hardware specific value coded into their turnkey/install/board_conf.ko
> module.  AFAICS, this is required to prevent anyone from trying to
> install an older image on new hardware, since they use unified images
> for this family and have added some models later.
> 
> Another more likely explanation could be that the OEM GUI doesn't care
> about the version trailer on hardware where the minimum version is
> V1.00(*.0).  To ZyXEL, this means that any firmware is acceptable on
> that hardware.  So it would make some sense to just allow anything
> regardless of trailer.
> 
> This would explain why you see that on the GS1900-8 since board_conf.ko
> lists it as (simply using strings to "analyze" the hardware table in the
> binary): 
> 
>  GS1900-8
>  RTL8380M
>  V1.00(AAHH.0)
>  V2.60(AAHH.2)
> 
> (The last version number is 2.60.2 because this is a binary from that
> release).
> 
> If this theory is correct, then any of the following hardware might work
> without a valid trailer:
> 
> model        hwver  mim OEM ver
> GS1900-8     V1.0   V1.00(AAHH.0)
> GS1900-8HP   V1.0   V1.00(AAHI.0)
> GS1900-16    V1.0   V1.00(AAHJ.0)
> GS1900-24E   V1.0   V1.00(AAHK.0)
> GS1900-24    V1.0   V1.00(AAHL.0)
> GS1900-24HP  V1.0   V1.00(AAHM.0)
> GS1900-48    V1.0   V1.00(AAHN.0)
> GS1900-48HP  V1.0   V1.00(AAHO.0)
> 
> But these, and any newer models, would require a matching trailer:
> 
> model        hwver    mim OEM ver
> GS1900-8HP   V2.0   V2.10(AAHI.0)
> GS1900-10HP  V1.0   V2.10(AAZI.0)
> GS1900-24EP  V1.0   V2.60(ABTO.0)
> GS1900-24HP  V2.0   V2.60(ABTP.0)
> GS1900-48HP  V2.0   V2.60(ABTQ.0)
> 
> One very interesting candidate for testing is the GS1900-8HP, which uses
> the same four-letter code for both hardware revisions but with different
> minimum firmware versions.
> 
> A final question: Did you try to install an image *without* any trailer
> at all? I was hoping we could use the trailer to prevent users from
> trying to flash a sysupgrade image from OEM.  That would still work if
> the OEM firmware requires some trailer.

Thanks for the in-depth analysis! I've now also tested without any trailer, and this
image is also accepted in the vendor's web interface. I don't have any devices in the
former list, so I'm afraid I can't check whether a trailer-less firmware is rejected
on these devices.

> 
> > That being said, an image
> > produced with your patch applied, thus a correct trailer, can also be flashed and
> > the
> > trailer is recognized by the stock firmware.
> > 
> > So I guess I can already provide this:
> >  
> > Tested-by: Sander Vanheule <sander at svanheule.net>
> 
> Thanks.
> 
> > >  target/linux/realtek/image/Makefile | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/target/linux/realtek/image/Makefile
> > > b/target/linux/realtek/image/Makefile
> > > index ebc0c0a78480..38b4d5e441cc 100644
> > > --- a/target/linux/realtek/image/Makefile
> > > +++ b/target/linux/realtek/image/Makefile
> > > @@ -10,7 +10,7 @@ DEVICE_VARS += ZYXEL_VERS
> > >  
> > >  define Build/zyxel-vers
> > >         ( echo VERS;\
> > > -       for hw in $(1); do\
> > > +       for hw in $(ZYXEL_VERS); do\
> > >                 echo -n "V9.99($$hw.0) | ";\
> > >                 date -d @$(SOURCE_DATE_EPOCH) +%m/%d/%Y;\
> > >         done ) >> $@
> > 
> > Would it be worthwile to make zyxel-vers fail if $(ZYXEL_VERS) is not
> > defined/empty?
> > A user could still define a wrong value of course, but at least they would know
> > to
> > provide something.
> 
> We could do that, but I don't think that sort of failsafe coding is
> common in our image make rules.  They are not intended for end users
> anyway.  If you add a new device, then you're supposed to know what you
> do.
> 
> Let's see of we can get this fix in there first so that OpenWrt becomes
> installable again on the supposedly supported devices.

I agree, adding the check should be for another patch. It was more just something
that crossed my mind as I was reading the patch :)

Best,
Sander