I have a Surf SOHO configured in the DMZ of a DSL gateway to provide WiFi Internet with open DHCP and NAT for two workhorse computers and a network printer on its (untagged) LAN. A second Surf SOHO is connected LAN to LAN to extend two additional isolated WiFi VLANs, to the far end of the home, one for guests and a second for IoT devices which include a DirecTV receiver, an AppleTV and a Chromecast ULTRA. The idea is to isolate IoT and guest devices on VLANs so that if one is compromised it cannot access the workhorse computers or the printer. The WAN port on the second SOHO isn’t connected and its DHCP services are disabled.
This has worked perfectly for months until the last two weeks, when both SurfSOHOs have twice lost both Ethernet and WiFi connectivity overnight over the span of two weeks. The Status and WiFi indicators appear normal. The admin pages are inaccessible, so the condition can only be cleared by power-off-on reset, although that restores everything to normal.
After recent press about Google Home and Chromecast devices locking up TP-Link and other consumer routers, I am suspecting the Chromecast streamer. Per the press stories:
TP-Link engineers explained that the Cast feature sends multicast DNS (MDNS) packets to discover and keep a live connection with Google products.
MDNS seems to be the issueMDNS resolves the hostnames or assigned network names of devices to IP addresses, and is widely used on local networks without a DNS server. According to XDA-Developers, packets are usually sent every 20 seconds or so.
The problem seems to be that the Google devices will broadcast a large amount of these packets at rapid speed in a short space of time. This happens when the Google device is awoken from its ‘sleep’ state and, the longer it is in sleep mode, the larger the quantity of MDNS packets sent will be once it ‘wakes up’.
MDNS uses User Datagram Protocol (UDG) to send information packets. UDP has no congestion control features, so a device sending multiple UDP packets in a short burst can grind things to a standstill pretty swiftly.
If this issue isn’t remedied, the router’s memory could be filled up completely by the MDNS packets, leaving users with no choice but to reboot in order to restore the internet connection.
Has anyone else experienced this? …or is there any reason to suspect that the SurfSOHO is vulnerable to large bursts of MDNS over UDP?