Long multicast ping times from device connected to AC-88U

[Ian Macdonald]

I have a Chromecast 2 associated over 5 Ghz with an AC-88U running 382.2_beta3, although the issue I am about to describe also occurred with 382.1.

The Chromecast streams perfectly. It literally never drops out. If I cast a live TV channel to it, it will still be playing 24 hours later.

What works much less well, however, is the discovery of the Chromecast unit itself by client apps. Very often, this particular unit will fail to appear in the list of available Chromecasts in the house.

Chromecast discovery works using mDNS, and packet dumps of the network reveal that there can be sizeable intervals (up to 3 minutes) between the afflicted unit sending these.

If I ping the multicast address for mDNS, I get immediate responses from all of the mDNS devices on the network, except for this particular Chromecast. Sometimes, this device also responds immediately, but most of the time the responses show absurd latency.

Here's an example:

$ ping 224.0.0.251 | grep --colour=never '\.252'
64 bytes from 192.168.1.252: icmp_seq=1 ttl=64 time=146488 ms (DUP!)
64 bytes from 192.168.1.252: icmp_seq=2 ttl=64 time=145915 ms (DUP!)
64 bytes from 192.168.1.252: icmp_seq=3 ttl=64 time=144914 ms (DUP!)
64 bytes from 192.168.1.252: icmp_seq=4 ttl=64 time=144097 ms (DUP!)
64 bytes from 192.168.1.252: icmp_seq=5 ttl=64 time=143404 ms (DUP!)
64 bytes from 192.168.1.252: icmp_seq=6 ttl=64 time=142403 ms (DUP!)
64 bytes from 192.168.1.252: icmp_seq=7 ttl=64 time=141710 ms (DUP!)

An ordinary ping sent directly to the Chromecast while the above multicast ping is showing extreme latency exhibits absolutely normal behaviour:

$ ping 192.168.1.252
PING 192.168.1.252 (192.168.1.252) 56(84) bytes of data.
64 bytes from 192.168.1.252: icmp_seq=1 ttl=64 time=1.95 ms
64 bytes from 192.168.1.252: icmp_seq=2 ttl=64 time=2.65 ms
64 bytes from 192.168.1.252: icmp_seq=3 ttl=64 time=1.51 ms
64 bytes from 192.168.1.252: icmp_seq=4 ttl=64 time=3.30 ms
64 bytes from 192.168.1.252: icmp_seq=5 ttl=64 time=2.82 ms
64 bytes from 192.168.1.252: icmp_seq=6 ttl=64 time=1.61 ms
64 bytes from 192.168.1.252: icmp_seq=7 ttl=64 time=2.49 ms

The Chromecast in question is the only multicast device associated with the AC-88U, which is why I'm posting this here.

This Chromecast previously worked flawlessly when associated with an AC-3200 in a different room. It also briefly worked well in its new location with an old Linksys E4200, until I replaced that with the AC-88U.

Where on Earth are those ICMP packets hanging out for the 2 to 3 minutes before the Chromecast replies? I'm baffled.

Note that this doesn't seem related to the recently revealed mDNS storm issue that affected Google devices. No other device on the network is affected, the wi-fi network remains up, and even the Chromecast itself exhibits rock solid streaming performance, even as its discovery is failing miserably.

What on Earth is going on here?

 

[JDB]

https://www.myce.com/news/confirmed...es-temporarily-wifi-drops-around-world-83428/


Sent from my iPhone using Tapatalk

 

[JDB]

Aside from that, how are you using the 88U, if it’s as a Media Bridge/AP, then as far as I can tell, multicast in that mode is just broken, has been for years. I’ve got a whole bunch of scripts monitoring availability every minute to solve it.


Sent from my iPhone using Tapatalk

 

[JDB]

This is a thread covering the issue with Media Bridge mode https://www.snbforums.com/threads/rt-ac5300-x2-wi-fi-bridging-issue.37553/



Sent from my iPhone using Tapatalk

 

[Ian Macdonald]

https://www.myce.com/news/confirmed...es-temporarily-wifi-drops-around-world-83428/

You evidently skipped the part of my posting where I anticipated this kind of response and wrote:

Note that this doesn't seem related to the recently revealed mDNS storm issue that affected Google devices. No other device on the network is affected, the wi-fi network remains up, and even the Chromecast itself exhibits rock solid streaming performance, even as its discovery is failing miserably.

The symptoms of this problem don't match those of that problem. And if Google is true to its word, Google Play Services have already been patched in an update rolled out during the last few days.

Aside from that, how are you using the 88U, if it’s as a Media Bridge/AP, then as far as I can tell, multicast in that mode is just broken, has been for years. I’ve got a whole bunch of scripts monitoring availability every minute to solve it.

It's functioning in AP mode.

This is a thread covering the issue with Media Bridge mode https://www.snbforums.com/threads/rt-ac5300-x2-wi-fi-bridging-issue.37553/

Yes, but that deals only with media bridge mode, and only even mentions the AC-88U in passing. That, too, seems unrelated to my specific problem.

Do you have any pointers to resources highlighting specific multicast problems with the AC-88U (or, failing that, with other models) in AP mode?

 

[JDB]

My searching shows ALL Asus routers suffer the problems described in that thread when used in Media Bridge or AP mode.


Sent from my iPhone using Tapatalk

 

[Ian Macdonald]

My searching shows ALL Asus routers suffer the problems described in that thread when used in Media Bridge or AP mode.

OK, but my problem isn't described in that thread. And I have a perfectly functioning AC-3200 in another room, also in AP mode, that proves that the issue I'm describing isn't common to all models.

I'm not even ruling out that the possibility that the problem isn't related to the AP at all, although logical deduction points in that direction. The behaviour displayed — high latency mDNS discovery, but no packet loss at all — is bizarre. I haven't witnessed this before.

 

[JDB]

I’ve given up looking into the nuances of it, as you say it is VERY bizarre.
The reason unicast works is you have a valid ARP entry, if you clear the ARP cache during a time when multicast is failing I’d bet unicast also stops working for some minutes (as the ARP request, being a broadcast packet, fails to reach the Chromecast).


It also seems to happen only with combination of 2 Asus routers (one in router mode and one in AP/MB mode). I believe it may be actually something wrong with the router as opposed to the AP/MB itself.
As you have found, a slight change in environment can fix it, but the reasons why still are unclear.


Sent from my iPhone using Tapatalk

 

[JDB]

Oh, and what I wrote, but apparently accidentally overwrote with the paste of the link to the Google storm issue, was I currently suspect the root cause may be a flood of broadcast/multicast traffic kills/hangs something on the Asus. So while Google were publicly outed as doing this, I suspect anyone with a significant number of devices doing multicast may be the ones that suffer the problem.


I guess that may also explain the change in environment ‘fixing it’ as moving the source of the traffic around the network may help.


Sent from my iPhone using Tapatalk

 

[Ian Macdonald]

I’ve given up looking into the nuances of it, as you say it is VERY bizarre.
The reason unicast works is you have a valid ARP entry, if you clear the ARP cache during a time when multicast is failing I’d bet unicast also stops working for some minutes (as the ARP request, being a broadcast packet, fails to reach the Chromecast).

Good point!

I've just tested this and, your suspicion that unicast would probably also fail if the Chromecast weren't in the pinger's ARP cache turns out to be correct:

$ sudo arp -d 192.168.1.252
No ARP entry for 192.168.1.252
$ ping 192.168.1.252
PING 192.168.1.252 (192.168.1.252) 56(84) bytes of data.
From 192.168.1.77 icmp_seq=1 Destination Host Unreachable
From 192.168.1.77 icmp_seq=2 Destination Host Unreachable
From 192.168.1.77 icmp_seq=3 Destination Host Unreachable
From 192.168.1.77 icmp_seq=4 Destination Host Unreachable
From 192.168.1.77 icmp_seq=5 Destination Host Unreachable
From 192.168.1.77 icmp_seq=6 Destination Host Unreachable
From 192.168.1.77 icmp_seq=7 Destination Host Unreachable
From 192.168.1.77 icmp_seq=8 Destination Host Unreachable
From 192.168.1.77 icmp_seq=9 Destination Host Unreachable
64 bytes from 192.168.1.252: icmp_seq=10 ttl=64 time=175 ms
64 bytes from 192.168.1.252: icmp_seq=11 ttl=64 time=2.33 ms
64 bytes from 192.168.1.252: icmp_seq=12 ttl=64 time=3.01 ms
64 bytes from 192.168.1.252: icmp_seq=13 ttl=64 time=3.88 ms
64 bytes from 192.168.1.252: icmp_seq=14 ttl=64 time=8.56 ms

The problem isn't anywhere near so pronounced as with multicast, because the situation remedies itself within 10 seconds, but it's obviously still far from the desired behaviour.