Engenius ECW230 (Wifi6 4x4 AP) - $125

[slidermike]

EU site to the rescue! Download Result | EnGenius Networks Europe B.V

Doesn't have the .73 release, but the previous .70 release is there

Release notes: ECW230 | Cloud Release Note

Thanks again Dave.
I googled but zero results for the firmware itself.

Now if / when the AP is restored to a functional state, I have the goods!
I pinged you on the side with the loss of access to the AP.
(trying to revert from the hak firmware)

Thanks again guys! Always an adventure and not bad either!

 

[Dave Corder]

So, slidermike and I bricked one of is ECW230-converted-EWS377APv3 units trying to get it back to the original ECW230 firmware.

I was able to unbrick it tonight, but I couldn't figure it out through the web UI like all the other cross-flashes I've done. So in the end it required serial console access (cracking it open, soldering on header pins, using a USB-TTL (3.3v) adapter, etc). Happy to share the details if anyone needs them (or is just curious about it).

On the other hand, I converted my two ECW230 first to EWS377APv3 and then to EWS377AP-FIT without issue and they're humming along nicely for me (after hacking the MongoDB for my local Fit Controller first to allow their serial numbers to register).

 

[Dave Corder]

Some solid news for everyone - I've been complaining to the folks at engenius regarding the cloud lockin, and it looks like they finally acquiesced!

Been this way for the switches since forever, but now the same applies to your AP's... You no longer need to flash hacked FW to connect your ECW devices to a Fit Controller (VM or physical). Verified on both my ECW336 and ECW230 APs, where you'll see something like the below in the local AP mgmt UI - just input the IP of your VM/controller in the `EPC Address` field:

Annoyed that it took em this long to cave, but sincerely glad they finally agreed to enable it!

@bvd did you have to do anything other than enter your local VM/controller IP in that field to add the ECW APs to the controller? Does the controller need to be set up with FitRegister or anything? Having some trouble getting slidermike's restored ECW230 connected to a test local controller (as in, I stood up a fresh controller, put its IP in that field, and nothing really happened other than the "test" button reports success)

 

[slidermike]

@bvd did you have to do anything other than enter your local VM/controller IP in that field to add the ECW APs to the controller? Does the controller need to be set up with FitRegister or anything? Having some trouble getting slidermike's restored ECW230 connected to a test local controller (as in, I stood up a fresh controller, put its IP in that field, and nothing really happened other than the "test" button reports success)

@Dave Corder my cloud account has both the 230 in your place and the 2nd I have at my home.
Weird (to me) is that in the cloud portal both show their true model but to get the 230 to connect to my VM ezMaster I had to use your freedom firmware. In ezMaster it reports accurate to the firmware. Perhaps because I had both APs registered in the cloud prior, it is not actually interrogating them for model info. Just an observation.

 

[Dave Corder]

At the risk of turning this into even more of a generic "what can we do with EnGenius hardware?" thread, here's last night's fun: turning an ENS620EXT into an ECW160.

Why do this? Well, the ENS620EXT is old enough that it only works with the EZMaster controller and not the newer Fit Controller (local or cloud). But I've migrated my other gear to a local FIT controller and I want everything there (this ENS620EXT is intended to go under the eaves and cover my backyard). Plus, you know, I just love tinkering.

Working theory: the ENS620EXT and ENH1350EXT are basically the same hardware (same specs, same CPU, same WiFi chips, etc). The main difference is that the ENS620EXT has two Ethernet ports, and uses EnGenius's proprietary 24v PoE implementation instead of standard 802.3at PoE, so in theory cross-flashing the ENS620EXT to the ENH1350EXT firmware should, in theory, work. On top of that, the ENH1350EXT and the ECW160 are the same hardware (same FCC ID), so cross-flashing between ENH1350EXT and ECW160 FW is easy. So by the transitive property of cross-flashing, it should be possible to run the ECW160 firmware on the ENS620EXT

And, in practice, that is sort of true - it was fairly easy to flash my ENS620EXT with the ECW160 firmware. At least, with the Linux Kernel and root filesystem. But the flash layout on those two models differs by a little bit. (And the flash partitioning scheme appears to be embedded in bootloader itself, not in the u-boot environment variables like a lot of OpenWRT devices). The main difference is that the ENS620EXT doesn't have a cert flash partition, which is where the certificates used to communicate with FIT controllers/EnGenius cloud are stored. So while I was able to flash the ECW160 firmware onto the ENS620EXT, I couldn't get it to register with my local FIT controller.

However, if you have serial console (UART) access to the ENS620EXT (which requires opening it up and soldering onto some pads), you can get into the stock u-Boot, and reflash it from there with the u-Boot from an ECW160. At that point you have a brick, since the kernel location on flash is different and you have a flash with the kernel at the ENS620EXT address and a bootloader trying to load it from the ECW160 address. But you can use TFTP from the new u-Boot to transfer and write the kernel image and the root filesystem. Voila! Your ENS620EXT is now an ECW160.

(It may be possible to do all the flashing from inside Linux - that's how I did uBoot itself - but I didn't go down that route.)

One of these days I'll write up exactly what I did on this and put it somewhere online...

 

[bvd]

@bvd did you have to do anything other than enter your local VM/controller IP in that field to add the ECW APs to the controller? Does the controller need to be set up with FitRegister or anything? Having some trouble getting slidermike's restored ECW230 connected to a test local controller (as in, I stood up a fresh controller, put its IP in that field, and nothing really happened other than the "test" button reports success)

I don't recall having any issues with mine... Are you getting any errors captured, or...?

Sorry for the delay Dave, I've been lagging behind on pretty much all my non-work-related stuff recently

 

[Dave Corder]

I don't recall having any issues with mine... Are you getting any errors captured, or...?

Sorry for the delay Dave, I've been lagging behind on pretty much all my non-work-related stuff recently

No worries. Same thing here, for the most part.

We got it working, though - it appears to have just been related to the "factory reset" script I was using from the shell on the AP wasn't doing enough of a cleanup - once I did a reset through the Web UI on the AP, it seemed to reset some more "stuff" and now it's working as expected.

Edit to add: Working, once I also inserted an entry for the ECW230 into the MongoDB backend.

 

[Dave Corder]

FYI, if anyone is wondering, the EnGenius ENS620EXT seems to be perfectly fine being powered by a Ubiquiti 24v passive PoE injector (wasn't able to confirm beforehand that their 24v implementations were compatible, but it looks like they are.)

 

[slidermike]

Thanks @Dave Corder , the ecw230 looks good in my fit container.
The data collection and display is nice. Will see how it rolls for stability now.
For anyone curious my fit container is an a debian LXC in Proxmox, 2 cores, 4gb ram & 32gb hdd space. Its overkill as shown. I could go down to 1 core and 2gb ram easily.
I use the "notes" tab for access info and other relevant data per container/vm.

 

[foureight84]

Has anyone gotten the FitCon docker stack to run correctly on an ARM system? I've tried 1.3.15 and 1.3.16 and I get stuck with the mdns container not wanting to run properly with a python error of:

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./mdns/mdns_reg.py", line 101, in <module>
NameError: name 'zeroconf' is not defined. Did you mean: 'Zeroconf'?
Unregistering...
Traceback (most recent call last):
  File "./mdns/mdns_reg.py", line 66, in <module>
ValueError: You must specify a valid interface name.

 

[bvd]

They never built an arm version of the containers that I'm aware of other than the full OS image they have for the fitcon hw device

 

[foureight84]

They never built an arm version of the containers that I'm aware of other than the full OS image they have for the fitcon hw device

The ECR repo has ARM variants of the x86 versions. I figured it could work on a Raspberry Pi I have laying around. I suppose I'll just deploy it on an x86 machine for now.

 

[bvd]

The ECR repo has ARM variants of the x86 versions. I figured it could work on a Raspberry Pi I have laying around. I suppose I'll just deploy it on an x86 machine for now.

Hmmmm, I'll have to check it out sometime, thanks for the Intel!

 

[foureight84]

Hmmmm, I'll have to check it out sometime, thanks for the Intel!

When you do, edit the epc-prod.sh from Software Packages (VM) | FitController User Manual

LATEST_VERSION=$(curl -s "http://ocu-sqa.engeniuscloud.com/epc/version?stage=1&os=0" | tail -1)

Append "-arm" to the latest version. E.g. 1.3.16-arm.

You'll also need to install docker prior to running. Script uses x86 repo.