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.
Engenius ECW230 (Wifi6 4x4 AP) - $125
- Thread starter bvd
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
So, the ECW160 conversion went pretty much the same as the ECW230 conversion - flash it with a slightly modified .bin file of the ENH1350EXT firmware, perform a factory reset, and then just add it to ezMaster.
Fortunately the EnGenius EU site had a version of the ECW160 firmware available for download, so I was able to get the necessary magic hex values from that instead of having to get root access to the unit.
I started by trying to copy the full Senao header from the ECW firmware to the latest ENH firmware, but that didn't take - the web UI would accept it, but it wouldn't flash anything.
After a bit more tinkering, I decided to decode the Senao firmware image for both variants and then walk over them with binwalk, just to see what I could see. To my surprise, the firmware images had different layouts.
Decoded ENH firmware (EDITED: pasted the wrong output originally, updated with what I was trying to show):
Decoded ECW firmware:
I surmised that the difference in firmware image layout was a likely explanation for why I couldn't cross-flash the firmware.
Luckily, if you go to the ENH1350EXT page on engeniustech.com, you may note that the firmware link is a link to https://www.engeniustech.com/wp_firmware/enh1350ext-all-v3.9.3.2_c1.9.51.bin - if you remove the filename portion of the URL and just go to Index of /wp_firmware, you can find quite an archive of current and previous firmware releases for a number of products (I stumbled upon this while researching the ECW230 conversion). So I grabbed all the ENH1350EXT images, ran them all through the decoder and binwalk, and noticed that at some point in the past they changed the layout of the images.
I picked the newest firmware that still matched the ECW160's layout and copied over the whole Senao header. That didn't work, so then I went to the oldest release and tried just the couple of magic bytes that differed at the beginning of the header (leaving version strings and stuff in the header alone, just in case). Success!
This is what I ended up with:
Original ECW:
Modified ENH1350EXT (v3.5.0.13_c1.9.04)
From there, a quick factory reset, and I was able to get the registration code from the web UI and add it to my ezMaster without a hitch. From there, I let ezMaster upgrade it to the latest firmware (v3.9.3_c1.9.51) and that also succeeded without any issue (this suggests, BTW, that the converted ECW230 units will be able to be upgraded to a newer version of the EWS377v3 firmware that comes out without a problem).
(Side note: has anyone else noticed that EnGenius is now using the
Fortunately the EnGenius EU site had a version of the ECW160 firmware available for download, so I was able to get the necessary magic hex values from that instead of having to get root access to the unit.
I started by trying to copy the full Senao header from the ECW firmware to the latest ENH firmware, but that didn't take - the web UI would accept it, but it wouldn't flash anything.
After a bit more tinkering, I decided to decode the Senao firmware image for both variants and then walk over them with binwalk, just to see what I could see. To my surprise, the firmware images had different layouts.
Decoded ENH firmware (EDITED: pasted the wrong output originally, updated with what I was trying to show):
Code:
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
Code:
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:21Luckily, if you go to the ENH1350EXT page on engeniustech.com, you may note that the firmware link is a link to https://www.engeniustech.com/wp_firmware/enh1350ext-all-v3.9.3.2_c1.9.51.bin - if you remove the filename portion of the URL and just go to Index of /wp_firmware, you can find quite an archive of current and previous firmware releases for a number of products (I stumbled upon this while researching the ECW230 conversion). So I grabbed all the ENH1350EXT images, ran them all through the decoder and binwalk, and noticed that at some point in the past they changed the layout of the images.
I picked the newest firmware that still matched the ECW160's layout and copied over the whole Senao header. That didn't work, so then I went to the oldest release and tried just the couple of magic bytes that differed at the beginning of the header (leaving version strings and stuff in the header alone, just in case). Success!
This is what I ended up with:
Original ECW:
Modified ENH1350EXT (v3.5.0.13_c1.9.04)
From there, a quick factory reset, and I was able to get the registration code from the web UI and add it to my ezMaster without a hitch. From there, I let ezMaster upgrade it to the latest firmware (v3.9.3_c1.9.51) and that also succeeded without any issue (this suggests, BTW, that the converted ECW230 units will be able to be upgraded to a newer version of the EWS377v3 firmware that comes out without a problem).
(Side note: has anyone else noticed that EnGenius is now using the
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?)
Last edited:
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:
EDIT: I don't know when the fw started getting posted to the EU site, but it wasn't there ~2-3 months ago - probably some EU regulation that got passed? Either way, super happy for that, and I just pulled copies of all of them down for safe keeping. Thanks for mentioning!!
Last edited:
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 : "0
EVCFG"[ 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"
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 : "0
[ 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"
- 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.
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.
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.
Thanks for passing on the info EnGenius has the new wifi 7 model on preorder sale @reznap. I 100% agree that $500 is steep for home but I just checked and it is no where near wifi 7 ruckus price territory.
My google-fu shows the
RUCKUS R770
at $1,500 and msrp 2,600
Only place I saw (3 min search) listing a for sale price
No doubt it will be best in class performance but the price matches.
My google-fu shows the
RUCKUS R770
at $1,500 and msrp 2,600
Only place I saw (3 min search) listing a for sale price
PROVANTAGE: Ruckus Wireless LLC 901-R770-US00 Ruckus R770 Wi-Fi 7 Tri-Band Concurrent Wireless Access Point with 2X2 (2.4GHZ) + 4X4
Get Fast Service & Low Prices on 901-R770-US00 Ruckus Wireless LLC Ruckus R770 Wi-Fi 7 Tri-Band Concurrent Wireless Access Point with 2X2 (2.4GHZ) + 4X4 and Much More at PROVANTAGE.
www.provantage.com
No doubt it will be best in class performance but the price matches.
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.
That's just my opinion though, and regardless, I don't really see myself paying anything over 400-500 bucks for an AP before I just bite the bullet and spend the time building my own damned AP. 6E has been pretty friggin amazing for me so far, meets all my needs, and then some, so I likely won't be upgrading until there's some compelling reason for me to do so ¯\_(ツ)_/¯
The other more interesting point here though, at least from a home user's perspective (and IMO), is the 6Ghz spatial streams - the engenius unit goes 4x4x4:4 (4 spatial streams for each of the 3 bands, inc. 6Ghz - same as with the ECW336), while ruckus's is 2x2:2 in both 6Ghz and 2.4... If you want to make the absolute most of your 6Ghz connectivity, seems like engenius will be the way to go anyway.
The ruckus though... It having zigbee and BLE built in is a far bigger deal (in my mind at least, and to me specifically) than it probably should be lol. Not having to both build, try to make look 'not like absolute crap' (for wife approval factor lol), and then scatter a bunch of ESP32 devices around the house in order to solidify the BLE mesh in the house/garage has me drooling a bit more than I'd like to admit.
... Idk if it has me drooling a thousand dollars worth... But still, drooling
And now one of my ECW230's is an EWS377-FIT and registered with my local FitController (EPC = EnGenius Private Cloud, I assume).
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.
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.
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.
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!
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!
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.
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.
For anyone running the FitController locally, here's how to get access to the backend MongoDB if you want to poke around.
This all needs to be done as root wherever you have the EnGenius FitCon docker images running.
To get into the MongoDB, you need to find the key file that the engenius stack uses:
Docker uses overlay filesystems, so you want to find the one on the "merged' directory.
In my case, the file is
Take that path and use it in this command:
You should get the MongoDB shell prompt:
Switch to the database named main:
Get all the stuff from the devices collection (the devices you have registered on your controller):
You see a bunch of JSON, like so:
This all needs to be done as root wherever you have the EnGenius FitCon docker images running.
To get into the MongoDB, you need to find the key file that the engenius stack uses:
find /var/lib/docker -name "mongodb.key" | grep mergedDocker uses overlay filesystems, so you want to find the one on the "merged' directory.
In my case, the file is
/var/lib/docker/overlay2/592c4fbc2863677de8549b5a52b9ff9541488ab06d39c08bb0addaebd1e643ff/merged/etc/mongodb.keyTake that path and use it in this command:
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 localYou should get the MongoDB shell prompt:
rs0:PRIMARY>Switch to the database named main:
rs0:PRIMARY> use mainGet all the stuff from the devices collection (the devices you have registered on your controller):
rs0:PRIMARY> db.devices.find().pretty()You see a bunch of JSON, like so:
Code:
{
"_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")
}
Last edited:
If anyone with a local FitController install wants to add their own SSL certs to the web UI, it's pretty easy.
First, get your certificate and key from wherever you get your certs and copy them to the host running the docker containers (my files are named
Then, as root, just copy them into the container running nginx in the expected location and restart the container:
First, get your certificate and key from wherever you get your certs and copy them to the host running the docker containers (my files are named
FitCon.crt and FitCon.key and came from my OPNSense's built-in certificate manager).Then, as root, just copy them into the container running nginx in the expected location and restart the container:
Code:
docker cp /tmp/FitCon.crt epc-api:/app/nginx.crt
docker cp /tmp/FitCon.key epc-api:/app/nginx.key
docker restart epc-apiFor my next trick, if you want to add an HTTP -> HTTPS redirect on the default http://hostname:8080/ URL for the web console, here's one way of doing it (that I think has minimal risk of breaking other things):
As root, grab the
Save a copy of the original and then edit the file:
Starting on or around line 119, in the
Add a
Now, around line 139, you should find the
Add an
Finally, copy the modified file back into the container and restart it:
As root, grab the
nginx.conf file from the epc-api container:
Code:
docker cp epc-api:/nginx.conf nginx.conf
Code:
cp nginx.conf nginx.conf.orig
nano -w nginx.confserver block, you should find this:
Code:
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:
Code:
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:
Code:
location / {
alias /app/web;
try_files /index.html =404;
}if block to redirect http to https, so that it looks like this:
Code:
location / {
if ($scheme != "https") {
return 308 https://$host$request_uri;
}
alias /app/web;
try_files /index.html =404;
}
Code:
docker cp nginx.conf epc-api:/nginx.conf
docker restart epc-api@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.
I had been running the dave hak firmware but am ready for the better gui of fit.
Thank you kindly in advance.
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