[Release] Asuswrt-Merlin 384.13 is now available

[bbunge]

No it simply means that the PC in question has SMBv1 enabled. They probably just opened Windows Explorer and browsed the network.

OK, but Windows Explorer open for 6-8 hours? Does not compute. I understand Windows can be aggressive with network traffic (I have a story about Windows 2000...) but banging the same request every 8 seconds all day long?

 

[ColinTaylor]

OK, but Windows Explorer open for 6-8 hours? Does not compute. I understand Windows can be aggressive with network traffic (I have a story about Windows 2000...) but banging the same request every 8 seconds all day long?

Well you never mentioned the frequency or volume of the messages so I assumed it was a "normal" amount. If the requests are continuous then that's not normal and would warrant further investigation of the PC.

 

[ironclad]

Dirty flashed a 68u from 384.12 to 384.13, works great. Thanks for fixing the performance issues, enabling QoS no longer slows down the router interface.

 

[Magnus33]

Oh please...

TM1900 is THE SAME ROUTER as AC68U so please... Do not get all philosophical and do not be a purist, just help the guy. I really do not understand you all, you are all behaving like Asus employees with 100.000/year...

C'mon...

Edit:

Do not worry, I do not have TM1900... Only Netgear R7000 with xvortex.

Two of them.

Bothered by that too? Sue me...

Self entitled much?

Your receiving something for free and some how think you have a right to complain about it?

As Eric already stated XVortex has been breaking licenses and ignoring GPL

Although you may not have anything to complain as from what i hear XVortex is in a lot of trouble.
Funny how they always think messing with others company's property in public isn't going to bite them in the butt.
2019 is likely to be a very bad year for him it seems but i doubt anyone going to be shocked by that.

 

[draxus]

Asuswrt-Merlin 384.13 is now available for all supported models.

My update to 384.13 went very smoothly (from 384.12), and seems to be all functioning well from network standpoint. Great job as always.

I did run into a peculiarity that I not sure if any one else has run into (I probably wouldn't have noticed if my Internet provider hadn't just had an outage)...

The "Reboot" button in the web UI seems to be shutting down my RT-AC86U router when clicked on instead of doing a reboot.

I've tried it a few times now and it has done so consistently. The web interface will show updating settings (I believe it was) as the router powers itself off. I then have to stab the physical power button off and then on again to remedy this. Once I do that the router does boot up without any issues afterwards. I know this used to work correctly for me, but I don't know for sure if it was working from the last firmware version or not.

Is anyone else able to replicate this problem, or is it just my luck?

Thanks in advance.

 

[Mine Ong]

Well said. For someone like me who is relatively new to this scene, I particularly appreciate the historical context you provided.

When you buy a product, you don't just buy the hardware, but also the software, and the licences that comes with it. The TM-AC1900 wasn't licensed for running the Trend Micro components (there are reasons why the TM-AC1900 was much cheaper than a regular RT-AC68U - that is one of them. I believe Tuxera's NTFS and HFS driver might be another component that wasn't licensed for use on the TM-AC1900).

The reason why I have a firm stance about all of this here is because if ultimately Trend Micro or any of the other partners licensing components to Asus (Broadcom, Tuxera, WTFast, Cloudcheck or any other ones involved) files a complain at Asus, Asus will be forced to shut down this project. And SNBForums (as a totally separate entity) also has their own legal reasons to have that stance.

As for XVortex, he is violating various commercial licences, including the GPL licence. That means that in addition to risking this entire firmware project of being terminated at any time, I'm also among those who are being effectively shown the middle finger when I asked him politely to respect the GPL licencing terms on more than one occasion - all the code that I have personally written for Asuswrt-Merlin is under a GPL licence. XVortex is one large reason why my work is so much more harder today, with an increasing amount of the code being closed source, and no longer under my control.

You probably aren't aware, but I mentioned it some time ago: this whole project got very close of being terminated following a formal complain Asus received from one of their partners. I exchanged a few emails then with Asus to figure out if there would be a way we could appease that partner without having to shut down the whole Asuswrt-Merlin project. Ultimately Asus succeeded in appeasing that partner, so I was able to keep going. So don't be selfish, and understand that things are done for a reason. Ultimately, this entire project relies on Asus being able to provide the required source code and components to be able to recompile the firmware. They have the technical means to shut down this project, and if their partners threaten legal actions against them, they won't have any choice but to comply.

The fact that people are able to use Asuswrt-Merlin is not a right, it's a privilege. And that can be taken away at any time.

 

[jsbeddow]

My update to 384.13 went very smoothly (from 384.12), and seems to be all functioning well from network standpoint. Great job as always.

I did run into a peculiarity that I not sure if any one else has run into (I probably wouldn't have noticed if my Internet provider hadn't just had an outage)...

The "Reboot" button in the web UI seems to be shutting down my RT-AC86U router when clicked on instead of doing a reboot.

I've tried it a few times now and it has done so consistently. The web interface will show updating settings (I believe it was) as the router powers itself off. I then have to stab the physical power button off and then on again to remedy this. Once I do that the router does boot up without any issues afterwards. I know this used to work correctly for me, but I don't know for sure if it was working from the last firmware version or not.

Is anyone else able to replicate this problem, or is it just my luck?

Thanks in advance.

Well known issue with the RT-AC86U, but pinning down the cause has proven to be elusive, see this thread on the subject:
https://www.snbforums.com/threads/ac86u-sometimes-powers-completely-off-during-reboot.48296/

 

[hancox]

When you buy a product, you don't just buy the hardware, but also the software, and the licences that comes with it. The TM-AC1900 wasn't licensed for running the Trend Micro components (there are reasons why the TM-AC1900 was much cheaper than a regular RT-AC68U - that is one of them. I believe Tuxera's NTFS and HFS driver might be another component that wasn't licensed for use on the TM-AC1900).

The reason why I have a firm stance about all of this here is because if ultimately Trend Micro or any of the other partners licensing components to Asus (Broadcom, Tuxera, WTFast, Cloudcheck or any other ones involved) files a complain at Asus, Asus will be forced to shut down this project. And SNBForums (as a totally separate entity) also has their own legal reasons to have that stance.

As for XVortex, he is violating various commercial licences, including the GPL licence. That means that in addition to risking this entire firmware project of being terminated at any time, I'm also among those who are being effectively shown the middle finger when I asked him politely to respect the GPL licencing terms on more than one occasion - all the code that I have personally written for Asuswrt-Merlin is under a GPL licence. XVortex is one large reason why my work is so much more harder today, with an increasing amount of the code being closed source, and no longer under my control.

You probably aren't aware, but I mentioned it some time ago: this whole project got very close of being terminated following a formal complain Asus received from one of their partners. I exchanged a few emails then with Asus to figure out if there would be a way we could appease that partner without having to shut down the whole Asuswrt-Merlin project. Ultimately Asus succeeded in appeasing that partner, so I was able to keep going. So don't be selfish, and understand that things are done for a reason. Ultimately, this entire project relies on Asus being able to provide the required source code and components to be able to recompile the firmware. They have the technical means to shut down this project, and if their partners threaten legal actions against them, they won't have any choice but to comply.

The fact that people are able to use Asuswrt-Merlin is not a right, it's a privilege. And that can be taken away at any time.

Very well said. If any of this context were provided when the decision was made to nuke all TM-AC1900 discussion (even something as simple as "We've removed this discussion due to a possible legal liability that we can't disclose") , it may have smoothed waters a bunch, at the time. Just a thought.

 

[Howard_inGA]

Funny thing? Found my AC-5300 with core 2 pegged at 100%. Core 1 was running 0-4%. Tried a warm reboot from the GUI with no help-that is, core 2 carrying the whole load. Had to hard reboot cable modem, router, and media access point to restore normal ops.
System logs showed no anomalies at all?
Weirdness!

 

[skeal]

Funny thing? Found my AC-5300 with core 2 pegged at 100%. Core 1 was running 0-4%. Tried a warm reboot from the GUI with no help-that is, core 2 carrying the whole load. Had to hard reboot cable modem, router, and media access point to restore normal ops.
System logs showed no anomalies at all?
Weirdness!

SSH into the router and run "top" or if you have "htop" installed use it next time and see what process is hogging the processor.

 

[Swistheater]

SSH into the router and run "top" or if you have "htop" installed use it next time and see what process is hogging the processor.

It is probably acsd.

 

[Pietervs]

Funny thing? Found my AC-5300 with core 2 pegged at 100%. Core 1 was running 0-4%. Tried a warm reboot from the GUI with no help-that is, core 2 carrying the whole load. Had to hard reboot cable modem, router, and media access point to restore normal ops.
System logs showed no anomalies at all?
Weirdness!

I noticed a similar issue with mine today. I couldn’t reach the webpage of my AC-5300, regardless of which browser I used. I could ping the IP address and ssh into the router. A soft reboot (from the command line) didn’t help, so a hard reset was also the only option. But unlike you, only hard rebooting the router was enough.
What makes it even weirder: the router is rebooted every Monday- and Friday morning at 3 AM. Checking the logs, sure enough: the router was rebooted this morning as well.

Dumb enough I forgot to check the process with top, as suggested. Then again: working with Linux-based firewalls on a daily basis hanging processes in kernel space won’t show in top.

 

[Magnus33]

I noticed a similar issue with mine today. I couldn’t reach the webpage of my AC-5300, regardless of which browser I used. I could ping the IP address and ssh into the router. A soft reboot (from the command line) didn’t help, so a hard reset was also the only option. But unlike you, only hard rebooting the router was enough.
What makes it even weirder: the router is rebooted every Monday- and Friday morning at 3 AM. Checking the logs, sure enough: the router was rebooted this morning as well.

Dumb enough I forgot to check the process with top, as suggested. Then again: working with Linux-based firewalls on a daily basis hanging processes in kernel space won’t show in top.

Its appears there may be a bug which causes the router to stop communicating with some hardware unless a hard reboot done.

It would stop communicating with one computer ,tablet and harmony hub but the other devices remain connected.

 

[ironclad]

Why that complicated?
If you have verified your settings 1200/800 working well in long time testing on 68U you can set them in cfe and no need for any scripts anymore!
SSH: nvram set asuscfeclkfreq=1200,800 && nvram set asuscfecommit=1 && reboot

You should put a warning somewhere. Overclocking the 68u with the CFE is dangerous because it can result in soft bricks if you're not careful. It's much easier to clear NVRAM than reflashing a CFE with correct values.

My 68u was quasi-stable with 1400,800 for one day. The next day the overclock magically became unstable and I couldn't boot the router anymore. I had a failsafe that would disable the overclock after each startup but the router was in a fail state so it never worked. Anyways that was easy to fix, all I had to do was clear the NVRAM. Now I use 1200,800 corresponding to 1200MHz CPU 800MHz memory. Here's how you do it.

a. Back up your configuration in case your overclock is unstable
b. In case you missed the past line you should back up your configuration
c. No really I mean it please back up your configuration right now
1. nano /jffs/scripts/services-stop
2. make the file look like this

#!/bin/sh
nvram set clkfreq=1200,800
nvram commit

3. chmod +x /jffs/scripts/services-stop
4. reboot

This step is completely optional but it makes the CPU frequency in the tools tab correct.
1. nano /jffs/scripts/init-start
2. make the file look like this

#!/bin/sh
nvram set clkfreq=1200,800

3. chmod +x /jffs/scripts/init-start
4. reboot

To verify the overclock works run

cat /proc/cpuinfo | grep BogoMIPS

BogoMIPS should be approximately twice the CPU frequency. This is the only reliable way to see what frequency your CPU is running at.

Note that the CPU frequency only adjusts in 200MHz increments from 600/800/1000/1200/1400/1600. 1300 would round to 1400. Unfortunately this means there's less room to adjust. Possible memory values are 333/389/400/533/666/775/800. You may need a minimum CFE version to set memory to 800.

Stock CPU frequencies are
800 all normal rt-ac68us
1000 all rt-ac68u v2s

and for the memory
533 rp-ac68u
666 most revisions (?)
800 rt-ac68u v2

To stability test run this with or without -multi 2. This loads both cores to 100%. The CPU's rated for something like 120C, don't worry if it gets crazy hot. Run it as long as you want, if you get a freeze your overclock is unstable. A higher overclock should result in higher thoroughput.

while true; do openssl speed aes-256-cbc -multi 2 ; done

Why would you overclock your router? Well I get a linear improvement scaling in OpenVPN performance. If you use OpenVPN on your router do a speedtest for a pleasant surprise.

 

[Makaveli]

Great post.

And to add to this its CFE version dependent.

Once you get to the newer cfe sending this command will change the clocks but the Bogomips won't go up so your not getting the extra performance.

 

[Magnus33]

I noticed a similar issue with mine today. I couldn’t reach the webpage of my AC-5300, regardless of which browser I used. I could ping the IP address and ssh into the router. A soft reboot (from the command line) didn’t help, so a hard reset was also the only option. But unlike you, only hard rebooting the router was enough.
What makes it even weirder: the router is rebooted every Monday- and Friday morning at 3 AM. Checking the logs, sure enough: the router was rebooted this morning as well.

Dumb enough I forgot to check the process with top, as suggested. Then again: working with Linux-based firewalls on a daily basis hanging processes in kernel space won’t show in top.

So i did check and here is the results.

ASUSWRT-Merlin RT-AC86U 384.13-0 Wed Jul 31 17:30:41 UTC 2019

Root@RT-AC86U:/tmp/home/root# top

Mem: 405208K used, 35212K free, 2516K shrd, 20K buff, 58184K cached

CPU: 9.0% usr 4.5% sys 0.0% nic 86.3% idle 0.0% io 0.0% irq 0.0% sirq

Load average: 2.94 3.04 3.06 1/154 26277

PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND

937 1 Root S 9856 2.2 1 9.0 cfg_server

952 1 Root S 51256 11.6 0 0.0 amas_lib

287 1 Root S 18504 4.1 1 0.0 /bin/swmdk

28181 1 Root S < 15960 3.6 1 0.0 dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/

815 1 Root S 12948 2.9 0 0.0 httpd -i br0

11243 1 Root S 11488 2.6 1 0.0 /usr/sbin/smbd -D -s /etc/smb.conf

921 1 Root S 11432 2.5 0 0.0 roamast

11241 1 Root S 11208 2.5 0 0.0 nmbd -D -s /etc/smb.conf

11242 11241 Root S 11184 2.5 1 0.0 nmbd -D -s /etc/smb.conf

762 1 Root S 11164 2.5 1 0.0 nt_monitor

857 819 Root S 10428 2.3 1 0.0 vis-dcon

764 1 Root S 10408 2.3 1 0.0 /sbin/netool

13299 1 Root S 9532 2.1 0 0.0 wred -B

1 0 Root S 9300 2.1 1 0.0 /sbin/init

777 1 Root S 9080 2.0 1 0.0 nt_center

883 1 Root S 8888 2.0 0 0.0 mastiff

878 1 Root S 8448 1.9 1 0.0 networkmap --bootwait

892 1 Root S 8364 1.9 0 0.0 pctime

825 1 Root S 8360 1.8 0 0.0 watchdog

757 1 Root S 8360 1.8 0 0.0 /sbin/wanduck

27998 1 Root S 8360 1.8 0 0.0 usbled

13343 1 Root S 8360 1.8 1 0.0 bwdpi_wred_alive

1585 1 Root S 8360 1.8 0 0.0 disk_monitor

625 1 Root S 8360 1.8 1 0.0 console

788 1 Root S 8360 1.8 0 0.0 wpsaide

790 787 Root S 8360 1.8 0 0.0 ATE Get_WanLanStatus

884 1 Root S 8360 1.8 0 0.0 bwdpi_check

1246 1 Root S 7536 1.7 1 0.0 u2ec

13050 1 Root S 6088 1.3 0 0.0 /usr/sbin/stubby -g -C /etc/stubby/stubby.yml

819 1 Root S 5308 1.2 1 0.0 vis-dcon

763 1 Root S 5296 1.2 1 0.0 protect_srv

13053 1 nobody S 5144 1.1 0 0.0 dnsmasq --log-async

13054 13053 Root S 4892 1.1 0 0.0 dnsmasq --log-async

821 1 Root S 4700 1.0 0 0.0 vis-datacollector

903 1 Root S 4636 1.0 1 0.0 nt_actMail

797 1 Root S 4532 1.0 0 0.0 /usr/sbin/wlceventd

785 1 Root S 4224 0.9 1 0.0 /bin/wps_monitor

789 1 Root S 4168 0.9 1 0.0 /usr/sbin/wlc_nt

832 1 Root S 4164 0.9 0 0.0 rstats

27985 1 Root S 3720 0.8 1 0.0 /usr/sbin/ntp -t -S /sbin/ntpd_synced -p pool.ntp.org -p time.nist.gov

786 1 Root S 3420 0.7 1 0.0 nas

26265 26257 Root S 3368 0.7 0 0.0 -sh

27991 1 Root S 3364 0.7 1 0.0 /sbin/klogd -c 5

12507 1 Root S 3364 0.7 0 0.0 /sbin/udhcpc -i eth1 -p /var/run/udhcpc1.pid -s /tmp/udhcpc -O33 -O249

27989 1 Root S 3364 0.7 1 0.0 /sbin/syslogd -m 0 -S -O /tmp/syslog.log -s 256 -l 6

814 1 Root S 3364 0.7 1 0.0 crond -l 9

787 815 Root S 3364 0.7 0 0.0 sh -c ATE Get_WanLanStatus

12780 1 Root S 3364 0.7 1 0.0 /sbin/zcip -p /var/run/zcip1.pid eth1 /tmp/zcip

17480 1 Root S 3364 0.7 1 0.0 /sbin/udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -O33 -O249

26274 26265 Root R 3364 0.7 0 0.0 top

936 932 nobody S 3316 0.7 1 0.0 lldpd -L /usr/sbin/lldpcli -I eth2,eth3,eth4,eth5,eth6,wds0.*.*,wds1.*.*,wds2.*.* -s RT-AC86U

Mem: 405500K used, 34920K free, 2516K shrd, 20K buff, 58184K cached

CPU: 0.2% usr 1.0% sys 0.0% nic 98.6% idle 0.0% io 0.0% irq 0.1% sirq

Load average: 3.02 3.06 3.06 1/154 26282

PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND

210 2 Root SW 0 0.0 0 0.4 [bcmsw_rx]

878 1 Root S 8448 1.9 1 0.2 networkmap --bootwait

825 1 Root S 8360 1.8 0 0.2 watchdog

785 1 Root S 4224 0.9 0 0.1 /bin/wps_monitor

832 1 Root S 4164 0.9 0 0.1 rstats

287 1 Root S 18504 4.1 1 0.0 /bin/swmdk

26274 26265 Root R 3368 0.7 0 0.0 top

211 2 Root SW 0 0.0 1 0.0 [bcmsw]

952 1 Root S 51256 11.6 0 0.0 amas_lib

28181 1 Root S < 15960 3.6 1 0.0 dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/

815 1 Root S 12948 2.9 0 0.0 httpd -i br0

11243 1 Root S 11488 2.6 1 0.0 /usr/sbin/smbd -D -s /etc/smb.conf

921 1 Root S 11432 2.5 0 0.0 roamast

11241 1 Root S 11208 2.5 0 0.0 nmbd -D -s /etc/smb.conf

11242 11241 Root S 11184 2.5 1 0.0 nmbd -D -s /etc/smb.conf

762 1 Root S 11164 2.5 1 0.0 nt_monitor

857 819 Root S 10428 2.3 0 0.0 vis-dcon

764 1 Root S 10408 2.3 1 0.0 /sbin/netool

937 1 Root S 9856 2.2 1 0.0 cfg_server

13299 1 Root S 9532 2.1 0 0.0 wred -B

1 0 Root S 9300 2.1 1 0.0 /sbin/init

777 1 Root S 9080 2.0 1 0.0 nt_center

883 1 Root S 8888 2.0 0 0.0 mastiff

892 1 Root S 8364 1.9 0 0.0 pctime

757 1 Root S 8360 1.8 0 0.0 /sbin/wanduck

27998 1 Root S 8360 1.8 0 0.0 usbled

13343 1 Root S 8360 1.8 1 0.0 bwdpi_wred_alive

1585 1 Root S 8360 1.8 0 0.0 disk_monitor

625 1 Root S 8360 1.8 1 0.0 console

788 1 Root S 8360 1.8 0 0.0 wpsaide

790 787 Root S 8360 1.8 0 0.0 ATE Get_WanLanStatus

884 1 Root S 8360 1.8 0 0.0 bwdpi_check

1246 1 Root S 7536 1.7 1 0.0 u2ec

13050 1 Root S 6088 1.3 0 0.0 /usr/sbin/stubby -g -C /etc/stubby/stubby.yml

819 1 Root S 5308 1.2 1 0.0 vis-dcon

763 1 Root S 5296 1.2 1 0.0 protect_srv

13053 1 nobody S 5144 1.1 0 0.0 dnsmasq --log-async

13054 13053 Root S 4892 1.1 0 0.0 dnsmasq --log-async

821 1 Root S 4700 1.0 1 0.0 vis-datacollector

903 1 Root S 4636 1.0 1 0.0 nt_actMail

797 1 Root S 4532 1.0 1 0.0 /usr/sbin/wlceventd

789 1 Root S 4168 0.9 1 0.0 /usr/sbin/wlc_nt

27985 1 Root S 3720 0.8 1 0.0 /usr/sbin/ntp -t -S /sbin/ntpd_synced -p pool.ntp.org -p time.nist.gov

786 1 Root S 3420 0.7 1 0.0 nas

26265 26257 Root S 3368 0.7 0 0.0 -sh

27991 1 Root S 3364 0.7 0 0.0 /sbin/klogd -c 5

12507 1 Root S 3364 0.7 0 0.0 /sbin/udhcpc -i eth1 -p /var/run/udhcpc1.pid -s /tmp/udhcpc -O33 -O249

27989 1 Root S 3364 0.7 0 0.0 /sbin/syslogd -m 0 -S -O /tmp/syslog.log -s 256 -l 6

814 1 Root S 3364 0.7 1 0.0 crond -l 9

787 815 Root S 3364 0.7 0 0.0 sh -c ATE Get_WanLanStatus

12780 1 Root S 3364 0.7 1 0.0 /sbin/zcip -p /var/run/zcip1.pid eth1 /tmp/zcip

Mem: 405772K used, 34648K free, 2516K shrd, 20K buff, 58184K cached

CPU: 0.8% usr 1.5% sys 0.0% nic 97.5% idle 0.0% io 0.0% irq 0.1% sirq

Load average: 3.02 3.05 3.06 2/154 26287

 

[Howard_inGA]

So i did check and here is the results.

ASUSWRT-Merlin RT-AC86U 384.13-0 Wed Jul 31 17:30:41 UTC 2019

I scanned this, but I don't see the process that might leave cpu 2 pegged. Did I miss it?

 

[Magnus33]

I scanned this, but I don't see the process that might leave cpu 2 pegged. Did I miss it?

Nope i didn't see anything either but the router becomes unreachable except through ssh or doing a hard reboot.

Did notice something quite odd though.
There a load of net_ratelimit: callbacks suppressed showing in the log and it appears the smart devices causing them (plugs and the like)

But if i switch from cable over to the backup dsl none show-up.

Switching over to the dsl shouldn't have any effect but it does so something odd going on here.

 

[PolarBear]

There a load of net_ratelimit: callbacks suppressed showing in the log and it appears the smart devices causing them (plugs and the like)

But if i switch from cable over to the backup dsl none show-up.

Switching over to the dsl shouldn't have any effect but it does so something odd going on here.

If you switch your ISP from cable to DSL you will get a different public IP address.

Might this be significant ?

 

[John Adams]

Upgraded 86U from beta --> 384.13 ... good.
Upgraded 87U from beta --> 384.13.1 ... not so good.

The upgrade appears to have shut off my 5Ghz radio, and I can't turn it on because the configuration screen doesn't seem to render or work anymore. I've tried it in firefox, safari, chrome from my mac and I can't seem to get in there.

Symptoms are
... when I navigate to the wireless section, the navigation bar on the left goes black, can't go anywhere. I need to use the browser back
... I can't select either the control or extension channels, it's an empty drop down dialog
... the apply button doesn't work.
... it seems to give me 2 5 GHz options ... a 5GHZ and a 5 GHZ-2 which I don't recall
... I can get into the other wireless options if I'm redirected in the UI. The guest network screen says the 5GHz wireless is off ... if I click on that it takes me to the professional screen

Went back to the beta release ...384.13_beta1-g73181bd3ae ... all is well again & radios back up.

Obligatory but never old ... these firmwares are awesome & thank you for all the work! Hopefully I'm not posting something someone else has, I went through a lot of the posts here (22 pages ?!) and didn't see anything.