[Asus RT-AX88U] Experiences & Discussion

[Jayce Ooi]

So RT-AC86U can have 160 MHz support in future?

 

[doc octopus]

My guess is the RT-AC86U didn't have it enabled because at the time it didn't support DFS channels.

European models support DFS channels

 

[RMerlin]

So RT-AC86U can have 160 MHz support in future?

Only if Asus went through the regulatory validation for it, and if the hardware supports it (i.e. amps and filters on the router pc board, not just the wifi SoC). I don't know if that's the case.

They seem to intend in adding US DFS channel support as they enabled it in the build profile, yet they still don't show on the webui. Unsure if it was by mistake, or just unfinished work.

European models support DFS channels

But to advertise 160 MHz support, the router would most likely have to support it everywhere, not just in one market.

 

[ColinTaylor]

Only if Asus went through the regulatory validation for it, and if the hardware supports it (i.e. amps and filters on the router pc board, not just the wifi SoC). I don't know if that's the case.

There was an application to the FCC for a Class II Permissive Change in February 2019 that included:

7. Add 80MHz+80MHz function (for 5G band 1/2) and add 160MHz function (for 5G band 3).

 

[RMerlin]

There was an application to the FCC for a Class II Permissive Change in February 2019 that included:

7. Add 80MHz+80MHz function (for 5G band 1/2) and add 160MHz function (for 5G band 3).

Then it will be up to them. It could amount to a marketing decision whether or not to enable that feature in the RT-AC86U.

 

[Embattle]

I guess it could still be a technical problem as well, I mean it just may result in the router having issues elsewhere thus they've not enabled it?

 

[RMerlin]

I guess it could still be a technical problem as well, I mean it just may result in the router having issues elsewhere thus they've not enabled it?

Could be, like limitations at the amp/filter levels that I mentioned.

In any case, only Asus would know.

 

[RMerlin]

What would cuase this to disconnect.

Lots of reasons: unstable connection, device going onto sleep mode / low power, interference, DFS scan bumping it off its channel, etc...

Is there a way to find out what the disconnection was for?

No.

 

[RMerlin]

At what point should I be concerned?

If you notice any issue while actively using the device.

 

[lilstone87]

Well I added a AX88U as my main router saturday, and I have a SB8200 with the new firmware that supports LAG. I also have gigabit internet via my ISP as well. After enabling LAG on the modem, and "WAN Aggregation" on the router. It seems to work, as the router main dashboard showed WAN Aggregation 2 Gbps. However I ran into an issue, and it's very annoying to say the least.

The router system log is being spammed with "kernel: net_ratelimit: *** callbacks suppressed" errors. I checked many different things, tried enabling/disabling LAG modem side, which every time you change it on the modem, the modem reboots. I checked the connection rates of both cable's from the router to modem, both had gigabit connection rates. The reason I know it's related to the "WAN Aggregation" feature, I decided to disconnect one of the cable's, with the feature still being enabled both modem, and router side. The router log shows one of the cable's being disconnected, after that, the spam of this error stops.

However as we all know, this feature requires two cables being connected for the feature to work. Currently I will likely have to disable this feature, until ASUS fixes this problem. Because there's no way I can handle seeing the router system log spammed filled with these errors. I will attach a screenshot I took of the system log last night, includes a 5-8 minute time period. Starting off with both cables being connected, you will see the error repeating itself often. When the rate of the callbacks were higher, I was actually running a speedtest. So the more data I push, the more callbacks being suppressed. You will see a log message when I disconnected one of the cables. I actually waited 3-4 minutes after disconnecting one of the cables, before I took the screenshot. As you will see, the errors completely stopped.

So there's zero doubt the cause of the issue. Now it's trying to figure out how to make ASUS aware of this issue, and get it fixed in a future firmware release. Because currently this is to annoying to keep enabled, because of it flooding the system log. Well I decided to make the router system log, log everything, and I plugged LAN port 4 back into the modem, to re-enable this feature.
This is what I found besides the "kernel: net_ratelimit: *** callbacks suppressed" error.

May 5 12:18:37 kernel: eth1 (Ext switch port: 0) (Logical Port: 8) (phyId: 8) Link UP at 1000 mbps full duplex
May 5 12:19:35 syslogd started: BusyBox v1.25.1
May 5 12:19:35 kernel: klogd started: BusyBox v1.25.1 (2019-05-02 16:02:57 EDT)
May 5 12:19:39 kernel: net_ratelimit: 481 callbacks suppressed
May 5 12:19:39 kernel: protocol 0800 is buggy, dev eth1 <-- 10 times, every time the callbacks error is logged.

 

[L&LD]

Well I added a AX88U as my main router saturday, and I have a SB8200 with the new firmware that supports LAG. I also have gigabit internet via my ISP as well. After enabling LAG on the modem, and "WAN Aggregation" on the router. It seems to work, as the router main dashboard showed WAN Aggregation 2 Gbps. However I ran into an issue, and it's very annoying to say the least.

The router system log is being spammed with "kernel: net_ratelimit: *** callbacks suppressed" errors. I checked many different things, tried enabling/disabling LAG modem side, which every time you change it on the modem, the modem reboots. I checked the connection rates of both cable's from the router to modem, both had gigabit connection rates. The reason I know it's related to the "WAN Aggregation" feature, I decided to disconnect one of the cable's, with the feature still being enabled both modem, and router side. The router log shows one of the cable's being disconnected, after that, the spam of this error stops.

However as we all know, this feature requires two cables being connected for the feature to work. Currently I will likely have to disable this feature, until ASUS fixes this problem. Because there's no way I can handle seeing the router system log spammed filled with these errors. I will attach a screenshot I took of the system log last night, includes a 5-8 minute time period. Starting off with both cables being connected, you will see the error repeating itself often. When the rate of the callbacks were higher, I was actually running a speedtest. So the more data I push, the more callbacks being suppressed. You will see a log message when I disconnected one of the cables. I actually waited 3-4 minutes after disconnecting one of the cables, before I took the screenshot. As you will see, the errors completely stopped.

So there's zero doubt the cause of the issue. Now it's trying to figure out how to make ASUS aware of this issue, and get it fixed in a future firmware release. Because currently this is to annoying to keep enabled, because of it flooding the system log. Well I decided to make the router system log, log everything, and I plugged LAN port 4 back into the modem, to re-enable this feature.
This is what I found besides the "kernel: net_ratelimit: *** callbacks suppressed" error.

May 5 12:18:37 kernel: eth1 (Ext switch port: 0) (Logical Port: 8) (phyId: 8) Link UP at 1000 mbps full duplex
May 5 12:19:35 syslogd started: BusyBox v1.25.1
May 5 12:19:35 kernel: klogd started: BusyBox v1.25.1 (2019-05-02 16:02:57 EDT)
May 5 12:19:39 kernel: net_ratelimit: 481 callbacks suppressed
May 5 12:19:39 kernel: protocol 0800 is buggy, dev eth1 <-- 10 times, every time the callbacks error is logged.

I'm not convinced about the 'zero doubt' of the cause here. That sequence you describe may just be coincidental, not causal?

https://www.snbforums.com/threads/net_ratelimit-issue-on-ac87-and-384-9.55222/

 

[lilstone87]

I'm not convinced about the 'zero doubt' of the cause here. That sequence you describe may just be coincidental, not causal?

https://www.snbforums.com/threads/net_ratelimit-issue-on-ac87-and-384-9.55222/

What exactly are your concerns? If I may ask. I honestly don't have the time right now to read that whole thread. So I just wanted to ask you directly, what you think might be the issue? The only thing I don't think I tried.. was disconnecting the WAN cable instead of the LAN port 4 cable. However when both cables are connected, with both router, and modem having LAG enabled. This issue repeatedly happens, until one cable is disconnected.

As I mentioned before, which i'm not 100% I did in the post above, but I did in merlin's build thread. I do use one switch in my network, however I removed that switch, and tested without it for a period of time. That didn't matter at all. The reason I mention this... I know upon googling the callbacks error, there was a mention of a looping issue within the network being the cause. But that isn't the case for me.

As I said in my above post, and I stick by it. When both the WAN port, and LAN port 4 cables are connected to the modem, this error happens often, and the number of callbacks seem to increase, depending on the amount of traffic being passed over the WAN port. Before I even mentioned this here, I tested for a little while, to be sure of the cause. It relates to using this feature. I mean ASUS did just add this feature with their latest firmware for this router. So bugs are likely to happen, is it possible a modem side issue? Yes, still the issue is happening when using this feature on the router. It's something for them to further test, and work with the modem companies if needed.

 

[L&LD]

What exactly are your concerns? If I may ask. I honestly don't have the time right now to read that whole thread. So I just wanted to ask you directly, what you think might be the issue? The only thing I don't think I tried.. was disconnecting the WAN cable instead of the LAN port 4 cable. However when both cables are connected, with both router, and modem having LAG enabled. This issue repeatedly happens, until one cable is disconnected.

As I mentioned before, which i'm not 100% I did in the post above, but I did in merlin's build thread. I do use one switch in my network, however I removed that switch, and tested without it for a period of time. That didn't matter at all. The reason I mention this... I know upon googling the callbacks error, there was a mention of a looping issue within the network being the cause. But that isn't the case for me.

As I said in my above post, and I stick by it. When both the WAN port, and LAN port 4 cables are connected to the modem, this error happens often, and the number of callbacks seem to increase, depending on the amount of traffic being passed over the WAN port. Before I even mentioned this here, I tested for a little while, to be sure of the cause. It relates to using this feature. I mean ASUS did just add this feature with their latest firmware for this router. So bugs are likely to happen, is it possible a modem side issue? Yes, still the issue is happening when using this feature on the router. It's something for them to further test, and work with the modem companies if needed.

I have no concerns.

Just trying to steer you onto a reasonable path. Below is a quick search of what I found.

'net_ratelimit()' is used to limit syslog messages from kernel.
This "callbacks suppressed" message implies it suppressed a bulk of 44 syslog messages.
This is an attempt to avoid loading your syslog logging path.

I don't see the above as being a paramount issue for Asus to fix?

I don't doubt that the steps you take introduce this error in your network setup, but these messages are not the issue, they are possibly a symptom of a problem.

What error is shown just before these appear? That is what you should try to fix, from what I have researched.

 

[lilstone87]

What error is shown just before these appear? That is what you should try to fix, from what I have researched.

Later today/tonight. I will re-enable this feature, have the system log to log everything, which I did already. I posted what the log showed, which was this...

May 5 12:18:37 kernel: eth1 (Ext switch port: 0) (Logical Port: 8) (phyId: 8) Link UP at 1000 mbps full duplex
May 5 12:19:35 syslogd started: BusyBox v1.25.1
May 5 12:19:35 kernel: klogd started: BusyBox v1.25.1 (2019-05-02 16:02:57 EDT)
May 5 12:19:39 kernel: net_ratelimit: 481 callbacks suppressed
May 5 12:19:39 kernel: protocol 0800 is buggy, dev eth1 <-- 10 times, every time the callbacks error is logged.

So I dunno what to tell you... It logs the callback error repeatedly, with the "kernel: protocol 0800 is buggy, dev eth1" being logged ten times, every time the callback error is logged. So overall the router isn't logging anything before the error, that could point to an actual cause. However the error doesn't happen when one of the cables running to the modem, is disconnected. Which as I said before, and you know already.. for the feature to work, both cables being connected is needed.

EDIT: I will check for you though.... As I could be wrong, and something else is the cause. However I just know when this is enabled, with both cables attached, the error floods the log. I hope I'm wrong, and there's a simpler fix for the issue.

 

[lilstone87]

Hey @L&LD

You might be onto something... I just noticed this in the log, haven't seen it before... until now. Currently that feature is disabled on both, modem, and router side. Only connecting one cable from the wan to wan port. Still I'm curious why would this error go insane when LAG is enabled on the WAN side. Overall why is this happening?

May  6 13:35:55 kernel: net_ratelimit: 9 callbacks suppressed
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: net_ratelimit: 17 callbacks suppressed
May  6 13:36:14 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: nf_conntrack: expectation table full

 

[Boogieman]

Apparently the BCM4366 (and thus BCM4366E) always had 160 MHz support...

https://www.pcmag.com/news/330885/broadcom-rolls-out-new-5g-wi-fi-chips

If only BCM stopped being so frigging paranoid and started publishing some USEFUL specs on their own website, we wouldn't have to chase around digging up such basic information.

My guess is the RT-AC86U didn't have it enabled because at the time it didn't support DFS channels.

Not even the RT-AC2900 (same as AC86 basically - except red stuff on chassis) supports 160 MHz.
My guess, to make people buy the GT for more Not that 160MHz is very useful in a flat complex like where i live but, would be nice to have.

Specs dont differ much - same amount of antennas, MIMO and clocks. So I guess DFS channels could be added via FW?
https://www.asus.com/Networking/RT-AC2900/specifications/
https://www.asus.com/Networking/ROG-Rapture-GT-AC2900/specifications/

Edit: Just noted that GT says 64bit processor - RT does not. Typo?

 

[RMerlin]

Edit: Just noted that GT says 64bit processor - RT does not. Typo?

RT is 64-bit as well. In the firmware the kernel is 64-bit, but userspace stuff is 32-bit.

 

[lilstone87]

Hey @L&LD

You might be onto something... I just noticed this in the log, haven't seen it before... until now. Currently that feature is disabled on both, modem, and router side. Only connecting one cable from the wan to wan port. Still I'm curious why would this error go insane when LAG is enabled on the WAN side. Overall why is this happening?

May  6 13:35:55 kernel: net_ratelimit: 9 callbacks suppressed
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:35:55 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: net_ratelimit: 17 callbacks suppressed
May  6 13:36:14 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: nf_conntrack: expectation table full
May  6 13:36:14 kernel: nf_conntrack: expectation table full

Well it seems I found what's the cause, and how to silence it. What I find odd... Is I used a RT-AC3100 as my main router, before swapping out to the AX88U last week. With everything the same on my network. So it seems Asus decided to lower a number regarding a setting on the AX88U. To me it doesn't make much sense as the AX88U is overall just a better router, then the AC3100.

So why wouldn't they make this setting higher? "/proc/sys/net/netfilter/nf_conntrack_expect_max"

I am lucky to have found this thread on here... https://www.snbforums.com/threads/nf_conntrack-expectation-table-full-and-other-log-oddities.55415/
As it seems others with this router, are also seeing the errors I listed above spamming their log as well. On one of the last post in this thread currently @RamGuy appears to have posted code he used to make himself a script, to run, and keep this issue contained. I'm interested in doing the same, however I don't know much about scripts overall. So there's no way I could make a script myself to run. So if anyone know how to make one, and would be willing to, I would greatly appreciate it. As no one knows if/when Asus will adjust this setting, and get these two errors to stop spamming the router log.

Oh btw I did use putty to login to the router, and run the code @RamGuy posted in that thread, and I haven't seen these two errors since then. So I have zero doubt this is now the cause of this problem. Now I just want a script to be able to use, as I'm pretty sure any router restart will clear the changes I made right? I'm just trying to not have to use putty all the time, to change this setting manually.

EDIT: Here's my router log after almost 12 hours since I used @RamGuy code. As you will see changing this setting has gotten rid of this issue for me. Also no signs of an issue with the router either, after changing this setting.

May  9 23:40:50 dropbear[5625]: Exit (***): Exited normally
May 10 02:45:02 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.22 
May 10 02:45:02 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.22 
May 10 03:20:27 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.157 
May 10 03:20:27 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.157
May 10 03:30:00 adaptive QOS: Scheduled Persistence Check -> No modifications necessary
May 10 03:54:16 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.89 
May 10 03:54:16 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.89 
May 10 04:12:04 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.94 
May 10 04:12:04 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.94 
May 10 04:13:07 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.46 
May 10 04:13:07 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.46 
May 10 04:22:13 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.213 
May 10 04:22:13 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.213 
May 10 04:22:20 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.219 
May 10 04:22:20 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.219 
May 10 04:38:58 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.201 
May 10 04:38:58 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.201 
May 10 04:39:59 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.74 
May 10 04:39:59 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.74 
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPDISCOVER(br0) 
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPOFFER(br0) 192.168.1.67
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.67 
May 10 06:56:25 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.67 
May 10 07:29:01 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.153 
May 10 07:29:01 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.153 
May 10 08:20:02 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.103 
May 10 08:20:02 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.103 
May 10 11:06:48 dnsmasq-dhcp[1085]: DHCPREQUEST(br0) 192.168.1.199 
May 10 11:06:48 dnsmasq-dhcp[1085]: DHCPACK(br0) 192.168.1.199

 

[lilstone87]

Well after 12 hours of the router log staying clean. I decided to give "WAN Aggregation" another try. Well that didn't turn out well, even with this setting changed. Here's what my router log showed in a short period of time. Asus needs to figure this out... as there's something wrong within their software.

May 10 12:28:23 kernel: net_ratelimit: 91 callbacks suppressed
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:23 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: net_ratelimit: 83 callbacks suppressed
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:29 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: net_ratelimit: 100 callbacks suppressed
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:35 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: net_ratelimit: 96 callbacks suppressed
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:41 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: net_ratelimit: 82 callbacks suppressed
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1
May 10 12:28:47 kernel: protocol 0800 is buggy, dev eth1

 

[Deleted member 22229]

LOL Don't you know it's all a marketing game. There are features they just put on the box to make you buy the product don't matter if it actually works. It's not just Asus they are all guilty of this.