Somewhat related to this thread, I just converted an ECW160 outdoor Wave-2 AP to an ENH1350EXT and am currently adopting it into my ezMaster stack, using the same hex editing and cross-flashing process as the ECW230 conversion. Details to follow.
Scan Time: 2023-09-25 12:53:46
Target File: /Users/dcorder/Desktop/ecw160-conversion/enh1350-firmware/enh1350ext-all-v3.9.3.2_c1.9.51-decoded.bin
MD5 Checksum: 37476fe7941e0ff92c466f6e0c5f79d8
Signatures: 411
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Flattened device tree, size: 21333828 bytes, version: 17
2668 0xA6C ELF, 32-bit LSB shared object, ARM, version 1 (SYSV)
326169 0x4FA19 Certificate in DER format (x509 v3), header length: 4, sequence length: 1284
326285 0x4FA8D Certificate in DER format (x509 v3), header length: 4, sequence length: 1288
388052 0x5EBD4 CRC32 polynomial table, little endian
389740 0x5F26C CRC32 polynomial table, little endian
449096 0x6DA48 HTML document header
449882 0x6DD5A HTML document footer
449934 0x6DD8E HTML document header
450058 0x6DE0A HTML document header
450837 0x6E115 HTML document footer
475636 0x741F4 Flattened device tree, size: 3814464 bytes, version: 17
475864 0x742D8 gzip compressed data, maximum compression, has original file name: "Image", from Unix, last modified: 2021-12-12 14:13:22
4174752 0x3FB3A0 Flattened device tree, size: 23270 bytes, version: 17
4198292 0x400F94 Flattened device tree, size: 28868 bytes, version: 17
4227428 0x408164 Flattened device tree, size: 23171 bytes, version: 17
4250868 0x40DCF4 Flattened device tree, size: 18202 bytes, version: 17
4269340 0x41251C Flattened device tree, size: 18310 bytes, version: 17
4290328 0x417718 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 16796422 bytes, 3303 inodes, blocksize: 262144 bytes, created: 2021-12-12 14:14:54
Scan Time: 2023-09-25 12:53:35
Target File: /Users/dcorder/Desktop/ecw160-conversion/enh1350-firmware/enh1350ext-all-v3.5.1.2_c1.9.04-decoded.bin
MD5 Checksum: cc6af57cd0cfef7302ead640498c9ee2
Signatures: 411
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Flattened device tree, size: 19824220 bytes, version: 17
2004 0x7D4 Flattened device tree, size: 3437380 bytes, version: 17
2232 0x8B8 gzip compressed data, maximum compression, has original file name: "Image", from Unix, last modified: 2018-11-21 09:13:01
3181556 0x308BF4 Flattened device tree, size: 36624 bytes, version: 17
3218448 0x311C10 Flattened device tree, size: 40176 bytes, version: 17
3258892 0x31BA0C Flattened device tree, size: 40254 bytes, version: 17
3299416 0x325858 Flattened device tree, size: 33655 bytes, version: 17
3333340 0x32DCDC Flattened device tree, size: 33805 bytes, version: 17
3367416 0x3361F8 Flattened device tree, size: 33958 bytes, version: 17
3401644 0x33E7AC Flattened device tree, size: 36717 bytes, version: 17
3439612 0x347BFC Squashfs filesystem, little endian, version 4.0, compression:xz, size: 16056235 bytes, 3586 inodes, blocksize: 262144 bytes, created: 2018-11-21 09:14:21
88:DC:97
MAC prefix, but it's not listed in the official registry at https://standards-oui.ieee.org/ - just the older 88:DC:96
prefix?)Yup, same - all my switches have the older prefix, (as to the wifi5 units I had installed at parents/in-laws), but anything wifi6 or newer seems to be getting 96 here as well:Side note: has anyone else noticed that EnGenius is now using the88:DC:97
MAC prefix, but it's not listed in the official registry at https://standards-oui.ieee.org/ - just the older88:DC:96
prefix?
I have two ECW220v2's, one is 88:dc:97 and the other 88:dc:96. I got the :97 new last summer, the :96 was older. They likely changed late 21 or early 22 in my estimation.(Side note: has anyone else noticed that EnGenius is now using the88:DC:97
MAC prefix, but it's not listed in the official registry at https://standards-oui.ieee.org/ - just the older88:DC:96
prefix?)
This is a mildly educated guess, but here's what I see as the three main scenarios:I have two ECW220v2's, one is 88:dc:97 and the other 88:dc:96. I got the :97 new last summer, the :96 was older. They likely changed late 21 or early 22 in my estimation.
If I were to try flashing my devices to the EWS357v3 fw and it didn't take what are the failure scenarios? Would it simply be rejected immediately in the web interface and never written? I get that impression based on your experience above. My concern is that it might write and not boot like I ran into with my foolish attempt at flashing to the WAX610 fw. It was just the backup FW2 image that saved my hide, I'd prefer to avoid that experience again since I was never able to get input access to the console, just read.
I did capture this in the boot log, do I need to see if this layout matches that of the 357 fw file? Thanks for any comments, I'm at the edge of my understanding here.
[ 2.261282] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xa1
[ 2.266711] nand: ONFI 10-Compliant Macronix MX30UF1G18AC
[ 2.273175] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 2.278579] 13 ofpart partitions found on MTD device qcom_nand.0
[ 2.285950] Creating 13 MTD partitions on "qcom_nand.0":
[ 2.292100] 0x000000000000-0x000000180000 : "0:SBL1"
[ 2.299361] 0x000000180000-0x000000280000 : "0:MIBIB"
[ 2.303877] 0x000000280000-0x000000600000 : "0:QSEE"
[ 2.310710] 0x000000600000-0x000000680000 : "0EVCFG"
[ 2.313492] 0x000000680000-0x000000700000 : "0:RPM"
[ 2.318474] 0x000000700000-0x000000780000 : "0:CDT"
[ 2.323255] 0x000000780000-0x000000800000 : "0:APPSBLENV"
[ 2.328076] 0x000000800000-0x000000fa0000 : "0:APPSBL"
[ 2.338920] 0x000000fa0000-0x000001000000 : "cert"
[ 2.339969] 0x000001000000-0x000001100000 : "userconfig"
[ 2.344112] 0x000001100000-0x000001180000 : "0:ART"
[ 2.349198] 0x000001180000-0x0000048c0000 : "rootfs"
[ 2.394840] mtd: device 11 (rootfs) set to be root filesystem
[ 2.395098] mtdsplit: no squashfs found in "rootfs"
[ 2.399563] 0x0000048c0000-0x000008000000 : "rootfs_1"
Thanks for the offer Dave, I appreciate it. As I consider it more I may just pass, I'm a little concerned it seems like EnGenius isn't too inclined to update the firmware on these devices going forward. Updates were already pretty infrequent and now that the 357 and 377 are discontinued I'd expect updates even less or not at all whereas the 220 and 230 are regularly being updated.This is a mildly educated guess, but here's what I see as the three main scenarios:
The boot log is possibly useful, but for the ECW160 conversion I was looking only at the flashable firmware files from the EnGenius site(s) themselves and how they're packaged (I fixed the output in my post above, so the differences I was talking about are actually shown now). I'm not sure how much that relates to the layout of the partitions on the flash chip itself - I'd probably need to get a root console on one of my devices to poke around.
- Failure mode #1: Magic numbers in the header don't match, so the web UI just rejects the upload completely.
- Failure mode #2: Magic number check passes, but firmware extraction from .bin file fails (due to corrupt checksum, different layout of the .bin file, whatever) - nothing bad happens since nothing was extracted to write to the flash
- Failure mode #3: New FW (aka root FS) gets extracted from the .bin but write to flash fails or FW is not fully compatible with device. Congrats, you have a brick...
I can't remember if it's come up before in this thread, but firmware for Senao devices (which includes the EnGenius brand of devices) aren't quite your regular embedded Linux firmware images for OpenWRT or something like that - they are built like that initially, but then they are "encoded" with a Senao-specific header block (and maybe a couple other things? - I'd have to look back at the encoder's code). There's code floating around out there to decode (and also re-encode) Senao images into something more familiar (that, e.g., utilities like binwalk can handle), which is what I used to decode the EnGenius files and figure out that the layout of the actual packaged filesystems and stuff inside those files were different).
Feel free to PM me and I can try to help you sort out the process for converting your ECW220v2.
Not really in the same ballpark IMO, though the pricing's already been mentioned above. The pricing for the engenius unit will almost certainly come down as well; same thing happened with the ECW336, where they were asking something like 700 friggin bucks for the thing initially, they realized that was a bit steep after their distributors complained it left them basically no margin, and now after they've adjusted wholesale $ some, you can fairly regularly find them on sale for $500-550.I noticed EnGenius has the wifi 7 ECW536 up for preorder on their store, it's 50% off right now and will normally be $1k. Feels like Ruckus money to me but thought I'd pass that along if anyone cares.
It's been a fun journey for me as well, with all the tinkering I've done (mainly on my EWS850-AP that I finally successfully converted to an EWS850-FIT and added to my local FitCon).That's great work @Dave Corder !
Been patiently waiting for your updates.
I am still riding a pair of ecw230's from the last DCP. (Dave Conversion Project)
When you get some more time would you mind sharing stats/performance values?
Do all the features work in so far as you can tell?
Exciting news..
Where is the ticket machine to get in line for the update
Lol
This has been a fun ride along.
Thats good news @bvd.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:
View attachment 34442
Annoyed that it took em this long to cave, but sincerely glad they finally agreed to enable it!
It has to have been within a recent release, as it wasn't there as little as a couple months ago, though of course they didn't include it within their release notes (it's fairly common to have 'undocumented' support from them, mostly for [stupid imo, but I get it] marketing reasons). I'd guess it came with the January 30th release.Thats good news @bvd.
Do you have to flash to a newer code to get that feature?
Curious, do you lose out on any features / capabilities by not using the FitCon or FitExpress Cloud and just opt for standalone mode? I just bought the EWS356-FIT but didn't know if I should buy the FitCon or just use them in standalone mode. I haven't been able to find out the feature differences beside being on-premise vs cloud.It's been a fun journey for me as well, with all the tinkering I've done (mainly on my EWS850-AP that I finally successfully converted to an EWS850-FIT and added to my local FitCon).
So far everything seems to be working as expected in the local Fit Controller with the converted devices - I can see clients and their info and application tracking seems to be working as well. Right now I have an actual EWS356-FIT, two ECW230 converted to EWS377-FIT, and one EWS850-AP converted to EWS850-FIT.
The ECW230 units were easiest to convert - same process as converting them to EWS377v3 (modify a couple bytes in the new firmware to match what the old firmware expects, flash, reset to defaults, ta-da!). The EWS850 was trickier due to some of the default configuration pieces necessary being missing, but I got it working last night. It's mainly due to the private certs needed to authenticate the AP with the controller - it looks like the ECW cloud, the Fit cloud, and the local Fit controller all use the same certs, so they were already present on the EWC230 units and got picked up and used when converted to EWS377-FIT, but they were entirely missing from the EWS850-AP since it was never meant to be used with any of those cloud controllers (just the legacy EZMaster controller, or in standalone mode).
The other trick was getting the local FitCon to accept the serial numbers of the ECW230 units as valid - this required an insert into the MongoDB under the hood in one of the the Docker containers for the local FitCon. Otherwise you'd need root or UART access to the ECW230 to change its serial number in the firmware to something valid (oh, and I also figured out how to do that and how to generate a valid serial number for any particular model since characters 5-7 of the serial number are a 3-character code identifying the specific model of AP/switch).
I'll get a write up done in a day or two and post it somewhere for the Internet to see.
find /var/lib/docker -name "mongodb.key" | grep merged
/var/lib/docker/overlay2/592c4fbc2863677de8549b5a52b9ff9541488ab06d39c08bb0addaebd1e643ff/merged/etc/mongodb.key
docker exec -it epc-db /usr/bin/mongo -u __system -p "$(tr -d '\011-\015\040' < /var/lib/docker/overlay2/592c4fbc2863677de8549b5a52b9ff9541488ab06d39c08bb0addaebd1e643ff/merged/etc/mongodb.key)" --authenticationDatabase local
rs0:PRIMARY>
rs0:PRIMARY> use main
rs0:PRIMARY> db.devices.find().pretty()
{
"_id" : ObjectId("658d3c81077bd0bab0c2ca1f"),
"type" : "switch",
"name" : "EWS2910P-FIT",
"model" : "EWS2910P-FIT",
"serial_number" : "2330GC11FMX9",
"mac" : "",
"registered_by" : "*********@gmail.com",
"org_id" : "60b83e13a783ad2a01cd85fb",
"images" : [ ],
"is_sync_config" : false,
"is_config_up_to_date" : false,
"created_time" : ISODate("2023-12-28T09:14:41.879Z"),
"modified_time" : ISODate("2023-12-28T09:14:41.879Z")
}
FitCon.crt
and FitCon.key
and came from my OPNSense's built-in certificate manager).docker cp /tmp/FitCon.crt epc-api:/app/nginx.crt
docker cp /tmp/FitCon.key epc-api:/app/nginx.key
docker restart epc-api
nginx.conf
file from the epc-api
container:docker cp epc-api:/nginx.conf nginx.conf
cp nginx.conf nginx.conf.orig
nano -w nginx.conf
server
block, you should find this: listen 80;
listen 443 ssl;
ssl_certificate /app/nginx.crt;
ssl_certificate_key /app/nginx.key;
server_name
line right after those using whatever your hostname is, so it looks like this: listen 80;
listen 443 ssl;
ssl_certificate /app/nginx.crt;
ssl_certificate_key /app/nginx.key;
server_name fitcon.example.com;
location /
block that looks like this: location / {
alias /app/web;
try_files /index.html =404;
}
if
block to redirect http to https, so that it looks like this: location / {
if ($scheme != "https") {
return 308 https://$host$request_uri;
}
alias /app/web;
try_files /index.html =404;
}
docker cp nginx.conf epc-api:/nginx.conf
docker restart epc-api
EU site to the rescue! Download Result | EnGenius Networks Europe B.V@bvd do you have and can share, or if not, how do I get the newer firmware for my ecw230 APs so I can flash them to new enough so I can then proceed to add them to my vm fit controller as you noted previous is a new feature they allow.
I had been running the dave hak firmware but am ready for the better gui of fit.
Thank you kindly in advance.