[CLOSED] Asuswrt-Merlin 378.50 Beta 1 is out

[Trexx]

At this point we have not much info on the Traffic Analyzer. It's something that's still a work-in-progress by Asus, so it's not fully functional, nor enabled yet in any available firmware. And currently, the "test code" in place only includes it in the RT-AC3200 FW. I have the impression that it should technically be possible to enable it for other routers that have the DPI engine, which would mean the RT-AC87U and RT-AC68U. But at this point, nobody but Asus knows what will be the final result. There's even a chance the feature might eventually be dropped if found out not to work as expected by their devs. So for now it's all just speculations.

OK .. now I am confused. So does the beta build have a "development" version of the Traffic Analyzer that can be enabled for the AC68U family?

 

[Gnoty]

RMerlin! Thanks for your amazing work!

I just have a small problem, when connecting with my LTE Huawei e398
i dont get the great 50mbps that i used to get, instead i get 13mbps up and down.

what to do to get back to my normal speeds?

cheers form sweden!

 

[Engineer]

I can't find RT-AC68U_3.0.0.4_376.49_6_cfeupd anywhere?

*edit, why in the misc folder?

Because it was a special BETA software to update the CFE and to place a 64M rootfs partition into the router. It was used as a stepping stone from Merlin to Asus latest software (which required the new CFE and 64M partition to function properly and fully).

 

[GoNz0]

my bootloaders gone from 1.0.1.8 to 1.0.1.6 after running both updates (resets between)

AC68U

???

*edit for merlin, I had to install the latest official to get the bootloader to update.
3.0.0.4.378.3873 (fyi)

 

[kaseyharris]

Try flushing your browser cache, and restart your browser. Or try a different browser.

Just a thought, I've been burned by cached pages from time to time.

I have fixed this by installing the latest official firmware from Asus site, factory reset then install. 50 beta 1. Finally took the cfe update after.

 

[L&LD]

RMerlin! Thanks for your amazing work!

I just have a small problem, when connecting with my LTE Huawei e398
i dont get the great 50mbps that i used to get, instead i get 13mbps up and down.

what to do to get back to my normal speeds?

cheers form sweden!

Have you reset to factory defaults and manually enter only the necessary settings to secure the router / wifi and connect to your ISP?

Have you used a new ssid?

 

[moebis]

• Wifi on the RT-AC56U. Make sure it still works properly despite reusing the AC68U driver. Please report any change in stability, speed, range, etc... If some of you have the time, please test both the regular and the _dpi versions of the AC56U firmware, and let me know if you notice any difference in terms of wireless.

I've been running the DPI version of BETA1 on my AC56U all day. Problems with HFS+ attached storage. Reformatted it as EXT4. Lots of "Jan 27 00:01:33 afpd[1206]: ad_valid_header_osx("/tmp/mnt/Storage/.__folder_list.txt"): not an adouble:OS X file" in logs while doing TM backups. But it still seems to work fine. Backup completed.

Regarding the actual wifi. Surprisingly, its a tad faster. I was getting ~4MB a sec before (using the latest stock ASUS provided firmware) with file copies to attached 1TB USB3 drive. I now get ~5MB-6MB sustained. I also noticed my MacBook is actually "sometimes" attaching to the 5Ghz. SSID, whereas before it ALWAYS defaulted to the 2.4Ghz. It sometimes still does. Not sure if that tidbit of info helps. But so far, so good. I'm really happy with all of the new features so-far. There are about 6 other devices attaching to it on the network and it's shuffling packets around on both bands very nicely. I have noticed high CPU usage on the dual core ARM processor during network file copies. I don't think I saw it like that before. Maybe the HFS+ drivers ASUS shipped were optimized, not sure. But you would think EXT4 would be a breeze for it.

 

[cailloux]

I experienced the same issue with the bootloader not upgrading on my AC68u (currently v1.0.1.1).

I think this is the relevant snippet from the syslog that shows the CFE upgrade attempt, to the extent it is helpful to figure out why it doesn't upgrade as expected.

Nov 30 19:00:21 kernel: Northstar brcmnand NAND Flash Controller driver, Version 0.1 (c) Broadcom Inc. 2012
Nov 30 19:00:21 kernel: NAND device: Manufacturer ID: 0x01, Chip ID: 0xf1 (AMD NAND 128MiB 3,3V 8-bit)
Nov 30 19:00:21 kernel: Spare area=64 eccbytes 56, ecc bytes located at:
Nov 30 19:00:21 kernel:  2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24 25 26 27 28 29 30 31 34 35 36 37 38 39 40 41 42 43 44 45 46 47 50 51 52 53 54 55 56 57 58 59 60 61 62 63
Nov 30 19:00:21 kernel: Available 7 bytes at (off,len):
Nov 30 19:00:22 kernel: (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0) 
Nov 30 19:00:22 kernel: Scanning device for bad blocks
Nov 30 19:00:22 kernel: Bad eraseblock 565 at 0x0000046a0000
Nov 30 19:00:22 kernel: Options: NO_AUTOINCR,NO_READRDY,BBT_SCAN2NDPAGE,
Nov 30 19:00:22 kernel: Creating 2 MTD partitions on "brcmnand":
Nov 30 19:00:22 kernel: 0x000004000000-0x000007ec0000 : "brcmnand"
Nov 30 19:00:22 kernel: 0x000007ec0000-0x000008000000 : "asus"
Nov 30 19:00:22 kernel: VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Nov 30 19:00:22 kernel: devtmpfs: mounted
Nov 30 19:00:22 kernel: Freeing init memory: 212K
Nov 30 19:00:22 kernel: !!! cfe_init !!!
Nov 30 19:00:22 kernel: cfe_init: CFE MTD 0 boot 0
Nov 30 19:00:22 kernel: cfe_init: block size 131072(00020000)
Nov 30 19:00:22 kernel: get_embedded_block:: mtd->size(00001000) erasesize(00080000) offset(00000000) emb_size(00020000)
Nov 30 19:00:22 kernel: cfe_init: cfe_nvram_header(cfba0400)
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_commit: done 0
Nov 30 19:00:22 kernel: ctf: module license 'Proprietary' taints kernel.
Nov 30 19:00:22 kernel: Disabling lock debugging due to kernel taint

 

[jay50n]

I'm thinking about going back to 49_5...IPv6 is not working right, and things seem to be taking longer on the internet with this release. I'm getting the IPv6 prefix stuff on my router like usual, but my computer keeps losing IPv6 not too long after rebooting. Can't really tell why, nothing in the log that seems to relate to that.

I'll try it without IPv6 first, and see if that speeds things up, then maybe reflash and reset again. And hope for the best.

Could be I'll just catch it again when it's no longer Beta.

The WAN/LAN Bandwidth Monitor thing looks cool, though *smile*.

Update: does seem much faster loading pages on the internet with IPv6 disabled. So I'll try reflashing and reset again. And see how that looks.

Update 2: Re-flashed and reset to defaults again...same result, bad IPv6. Back to 49_5.

I have the same problem on singapore M1 ipv6. However the problem disappears when i disable hardware acceleration.

 

[jegesq]

A lot was changed by Asus in the networkmap in the past few months. I know that they recently added a new feature were clients connected to an AP would be aggregated together (since it was impossible anyway to enumerate them, as from the router's point of view they all shared the AP/RP's MAC - this is a technical limitation of how a repeater works, nothing that can be done about it). That's all I know, I've never tested repeater or AP setups.

Thanks Merlin, but my experience with the 374.xx firmware is not consistent with what you describe. You note that "it was impossible to enumerate them, as from the router's point of view they all shared the AP/RP's MAC" my experience was that all devices connected to the repeater were in fact identified separately, not by MAC (which was always just the repeater's MAC), but by different IP addresses that were always correct (since the router is handling DHCP, it knows who and what is connected to it and which devices are assigned which IP's). It is true that when looking at the router's network map under the 374.XX versions, devices connected to the repeater would always have the repeater's MAC but you could still differentiate them by IP address.

But things are decidedly different under some of the later 376.XX iterations, and they remain different with this latest 378. beta in which, as you note, everything connected to the repeater is just aggregated under a single device in the router's network map. The problem (in addition to this aggregation) is that the device that is identified as the repeater is NOT the repeater itself, but contains both the MAC and IP address only of one of the connected devices. Very weird.

At this point we have not much info on the Traffic Analyzer. It's something that's still a work-in-progress by Asus, so it's not fully functional, nor enabled yet in any available firmware. And currently, the "test code" in place only includes it in the RT-AC3200 FW. I have the impression that it should technically be possible to enable it for other routers that have the DPI engine, which would mean the RT-AC87U and RT-AC68U. But at this point, nobody but Asus knows what will be the final result. There's even a chance the feature might eventually be dropped if found out not to work as expected by their devs. So for now it's all just speculations.

Understood. Still it would be nice if it was implemented on the AC66U's as well as the 68U and 87U. Oh well...

 

[ericbergan]

I apologize if this has already been asked - I did page through the thread, but 120+ postings in a day is clearly a sign of how much we like your version!

Anyway, you state that we should manually reenter everything for the configuration. Does this mean not to use the utility for saving/reinstalling values?

I have 30+ assigned DHCP addresses, and really would like to not have to reenter all of them.

Thanks for all your time on these versions!

eric

 

[Skirk]

Not sure if this is relevant, but I upgraded today, factory reset etc. Everything was running fine until I tried to install the Astrill router app. It seemed to break the menu as seen in the screenshot The icons disappear for the general settings and a lot of the sub-menus aren't accessable. Everything reverts to normal after unstalling the Astrill application. I tried disabling any Trend Micro and Qos settings and reinstalling to no avail.

In the meantime I've downgraded and will await any developments

 

[RMerlin]

Did you installed the RT-AC68U_3.0.0.4_376.49_6_cfeupd firmware first, that one updates the CFE in preparation for the .50

That build should not be required anymore. 378.50 is supposed to be doing the CFE upgrade.

 

[RMerlin]

I can't find RT-AC68U_3.0.0.4_376.49_6_cfeupd anywhere?

*edit, why in the misc folder?

Because it was not a formal release, it was just a test build meant as a temporary stop-gap until 378.50 got ready.

 

[RMerlin]

I experienced the same issue with the bootloader not upgrading on my AC68u (currently v1.0.1.1).

I think this is the relevant snippet from the syslog that shows the CFE upgrade attempt, to the extent it is helpful to figure out why it doesn't upgrade as expected.

Nov 30 19:00:21 kernel: Northstar brcmnand NAND Flash Controller driver, Version 0.1 (c) Broadcom Inc. 2012
Nov 30 19:00:21 kernel: NAND device: Manufacturer ID: 0x01, Chip ID: 0xf1 (AMD NAND 128MiB 3,3V 8-bit)
Nov 30 19:00:21 kernel: Spare area=64 eccbytes 56, ecc bytes located at:
Nov 30 19:00:21 kernel:  2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24 25 26 27 28 29 30 31 34 35 36 37 38 39 40 41 42 43 44 45 46 47 50 51 52 53 54 55 56 57 58 59 60 61 62 63
Nov 30 19:00:21 kernel: Available 7 bytes at (off,len):
Nov 30 19:00:22 kernel: (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0) 
Nov 30 19:00:22 kernel: Scanning device for bad blocks
Nov 30 19:00:22 kernel: Bad eraseblock 565 at 0x0000046a0000
Nov 30 19:00:22 kernel: Options: NO_AUTOINCR,NO_READRDY,BBT_SCAN2NDPAGE,
Nov 30 19:00:22 kernel: Creating 2 MTD partitions on "brcmnand":
Nov 30 19:00:22 kernel: 0x000004000000-0x000007ec0000 : "brcmnand"
Nov 30 19:00:22 kernel: 0x000007ec0000-0x000008000000 : "asus"
Nov 30 19:00:22 kernel: VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Nov 30 19:00:22 kernel: devtmpfs: mounted
Nov 30 19:00:22 kernel: Freeing init memory: 212K
Nov 30 19:00:22 kernel: !!! cfe_init !!!
Nov 30 19:00:22 kernel: cfe_init: CFE MTD 0 boot 0
Nov 30 19:00:22 kernel: cfe_init: block size 131072(00020000)
Nov 30 19:00:22 kernel: get_embedded_block:: mtd->size(00001000) erasesize(00080000) offset(00000000) emb_size(00020000)
Nov 30 19:00:22 kernel: cfe_init: cfe_nvram_header(cfba0400)
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_update: !!!! found !!!!
Nov 30 19:00:22 kernel: cfe_update: before fcc 79
Nov 30 19:00:22 kernel: cfe_commit: done 0
Nov 30 19:00:22 kernel: ctf: module license 'Proprietary' taints kernel.
Nov 30 19:00:22 kernel: Disabling lock debugging due to kernel taint

Try rebooting the router then check again. If it still shows an older CFE, then try doing a factory default reset and rebooting again (just save a backup of your settings so you can restore them after you are done doing this test).

I wish Broadcom hadn't made the frigging CFE updater closed source. This makes it impossible for me to debug anything, and I see zero reason for them to close source this - there's hardly any trade secret in such a process.

 

[RMerlin]

OK .. now I am confused. So does the beta build have a "development" version of the Traffic Analyzer that can be enabled for the AC68U family?

Again, for the 5th or 6th time: The Traffic Analyzer is NOT finalized. It's half working, and is not considered a feature of the firmware yet.

I'm going to remove any mention of it from the OP since people keep overlooking that paragraph.

 

[RMerlin]

my bootloaders gone from 1.0.1.8 to 1.0.1.6 after running both updates (resets between)

AC68U

???

*edit for merlin, I had to install the latest official to get the bootloader to update.
3.0.0.4.378.3873 (fyi)

It's impossible for the firmware to have downgraded your CFE since the only CFE image contained in it is 1.0.2.0.

 

[RMerlin]

I apologize if this has already been asked - I did page through the thread, but 120+ postings in a day is clearly a sign of how much we like your version!

Anyway, you state that we should manually reenter everything for the configuration. Does this mean not to use the utility for saving/reinstalling values?

I have 30+ assigned DHCP addresses, and really would like to not have to reenter all of them.

I haven't looked at John's code, but his method sound good. You should be fine, with one minor caveat: you must manually re-enable the OpenVPN servers if you previously had it enabled. Since Asus's changes were already making a factory default reset necessary, I took the opportunity to finally take care of this nvram change.

 

[RMerlin]

Not sure if this is relevant, but I upgraded today, factory reset etc. Everything was running fine until I tried to install the Astrill router app. It seemed to break the menu as seen in the screenshot The icons disappear for the general settings and a lot of the sub-menus aren't accessable. Everything reverts to normal after unstalling the Astrill application. I tried disabling any Trend Micro and Qos settings and reinstalling to no avail.

In the meantime I've downgraded and will await any developments

Asus did some changes to the menu layout in the past few weeks. You might want to contact Astrill about this, I can't do anything about it. They might need to adjust their plugin code to match Asus's recent changes.

 

[charlie2alpha]

One last thing to add about the ftp server, if I disable IPv6 completely then the ftp server will launch properly when turned on from the Web UI. Consistent with the error I reported earlier of course.