Can EnGenius EWS377AP v3 be directly flashed with EWS377-FIT firmware

[Alfa147x]

I have a whole bunch of EWS377AP v3 APs currently managed locally by ezMaster, plus one unused EWS377-FIT and an unused FitController100. I want to retire ezMaster and keep the deployment fully self-hosted.

The documented EWS377AP v3 → FIT bridge image, `ews377apv3-5.1.4-1.zip`, appears to have been removed.

EnGenius’s public firmware archive still has:
ews377-fit-1.1.30-13.bin

Has anyone successfully flashed `ews377-fit-1.1.30-13.bin` **directly** onto an EWS377AP v3 and adopted it into FitController/FitCon100/EnGenius Private Cloud (EPC)?


I do not want to blindly cross-flash it without firsthand confirmation.

 

[olev]

We flashed a few EWS377AP v3 into the Fit version. No issues at all.
Support provided us with "ews377apv3-5.2.1-2.zip" for the update, I just checked the email from back then.
Unfortunately the link isn't active anymore so I can't send you that version.

 

[Alfa147x]

We flashed a few EWS377AP v3 into the Fit version. No issues at all.
Support provided us with "ews377apv3-5.2.1-2.zip" for the update, I just checked the email from back then.
Unfortunately the link isn't active anymore so I can't send you that version.

Thanks — good to know the official zip worked. That bridge image is gone and the vendor will not share a link due to EOL.

So here's a workaround I've been able to get working: flash the plain ews377-fit-1.1.30-13.bin with no special zip.

It's a one-field patch. The EWS377AP v3, EWS377-FIT, and ECW230v3 are the same board (IPQ807x / ap-hk07, vendor_id 257). The v3's upload check (/lib/upgrade/check_senao_image_header.sh) only gates on vendor_id + product_id; not the model string, md5, or checksum. Stock FIT is rejected purely because product_id is 300 (FIT) vs 282 (v3). Patch that one field:

import struct
d = bytearray(open("ews377-fit-1.1.30-13.bin","rb").read())
assert struct.unpack(">I", d[8:12])[0] == 300   # FIT
d[8:12] = (282).to_bytes(4,"big")               # -> passes the v3 gate
open("ews377-fit-282.bin","wb").write(d)

The header md5sum only covers the (untouched) payload, so it stays valid; the vendor chksum is never read, and the obfuscation key is universal, the FIT payload de-wraps fine on v3 hardware.

Flash it: LuCI (System Manager > Firmware, two-step confirm) or sysupgrade -n /tmp/ews377-fit-282.bin. It writes to the inactive A/B slot, so holding the factory reset button reverts you to the original EWS firmware—keep the stock .bin off-box.

Getting root to do it: telnet/SSH land in a restricted CLI. Use the SSH exec channel (runs uid=0): ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa root@<ap> '<cmd>'. User is root, password = the web admin password.

Now to adoption. Flashing is easy; a cross-flashed board reports a blank serial (sn=0000) to the controller, which keys devices by serial, so it never adopts. Fix: on the EWS firmware, write a valid serial to config field 19 before re-flashing — setconfig -s 19 <SERIAL>, verify with setconfig -g 19. The serial's model code has to match the target firmware (X45 for FIT, X42 for cloud/ECW). (I'm testing this part now)

 

[Dave Corder]

Looks like you're the one who found my Engenius notes repo. Glad it's helped someone!

I've got a pair of ECW230v3 units that I've flashed back and forth between the stock firmware, the EWS377APv3 firmware, and the EWS377-FIT firmware, just by editing the bytes in the header as you found. I've also done the FIT conversion on the EWS850 - same process.

I like your Python way of editing those bytes. Nice and quick.

I have a couple other ECW devices on my workbench right now, along with a few in active use. I will have to check out that serial number thing with setconfig - I seem to recall I just set the serial number in the FW variables (via uBoot or fw_setenv, IIRC) and then did a factory reset, but it's been a while.

 

[Alfa147x]

ha, your notes repo was the Rosetta Stone for all this, thank you! Small world.

Good call on fw_setenv over setconfig — your memory's right, and I learned why the hard way:

• The controller keys on config field 19 — the "extra serial," a 20-char field (snextra in u-boot env; setconfig -g 19 reads it).
• Set it with fw_setenv snextra <serial>, NOT setconfig -s. setconfig's write path is a temp-file dance, and setconfig -a 5 with no temp reads stdin straight into /dev/mtd7 and wipes the whole env. Ask me how I know. fw_setenv writes a valid CRC; they share mtd7.
• Minor: SSH on the EWS build is port 8822, not 22 (dropbear Port '8822') — cost me way too long thinking SSH was off.

Big footgun moment for me: an erased/invalid env is safe (u-boot falls back to complete compiled defaults, bootcmd=bootipq, boots fine). A valid-but-incomplete env is worse — u-boot trusts it, ignores defaults, and any missing boot var = the slot won't boot. I rebuilt the env by hand after the wipe and turned a running AP into a bootloader brick. Rule: only fw_setenv single fields on a known-good env, or env default -a — never hand-assemble it.

So one unit's parked at the bootloader (my fault, not the flash's). Waiting on a pogo-pin clip + isolated FT232RL to hit the J2 UART header, env default -a; env save, then set the serial cleanly. Will report back once it's adopting.

Open to any suggestions you might have for connecting to the UART headers and flashing.

 

[Dave Corder]

On mine, I just soldered some header pins into the 4 holes of the UART port and connected my USB/serial devices with Dupont cables. Right angle pins fit on the board and still allowed the case to close back up.

Yeah, the bootloader env can be tricky. I recently flashed EWS5912FP (rev 2) switch to an ECS1112FP and had to work through some of the env variables, like snextra IIRC, before it was properly recognized and adopted. Speaking of which, I should do a writeup of that process one of these days, too (long story short, I took the easy route of dumping the whole flash from an ECS1112FP with a CH341a and writing it to the EWS5912FP, then modifying a couple things in the env to give it a unique serial number and MAC address).

 

[Alfa147x]

On mine, I just soldered some header pins into the 4 holes of the UART port and connected my USB/serial devices with Dupont cables. Right angle pins fit on the board and still allowed the case to close back up.

Yeah, the bootloader env can be tricky. I recently flashed EWS5912FP (rev 2) switch to an ECS1112FP and had to work through some of the env variables, like snextra IIRC, before it was properly recognized and adopted. Speaking of which, I should do a writeup of that process one of these days, too (long story short, I took the easy route of dumping the whole flash from an ECS1112FP with a CH341a and writing it to the EWS5912FP, then modifying a couple things in the env to give it a unique serial number and MAC address).

Happy long weekend! I was able to recover the board and swtich firmware pretty easily once i got my uart pogo pin clip.




Also, I've had luck getting OpenWRT kernel boot from NAND on this board using parts of the openwrt-nss-edma fork.