Questions[ssdp](server)

I have the following scenario: Two sites, each with their own network (non-overlapping private subnet), connected with a site-to-site VPN (layer 3, Wireguard). Routes to the other sites are configured in the default gateways and also distributed to the clients over DHCP. IP traffic (v4 and v6) travels fine between the networks.

On both VPN gateways, avahi-daemon works as mDNS repeater (enable-reflector=yes) between the local network and the wireguard tunnel, and smcroute is set up to forward routable SSDP multicast packets (sent to 239.255.255.250, ff05::c, ff08::c) from the local network to the wireguard tunnel and vice versa. This works well, both MDNS and SSDP packets travel from one network to the other, I checked it with Wireshark.

On Windows 10 (21H2), mDNS name resolution of .local Domains works well across both networks, thanks to avahi-daemon reflection. In VLC on Windows, multimedia devices from both networks are found with mDNS as well as UPnP (SSDP) and can be accessed. However, the Windows Explorer only shows devices from the local network in its Network view.

I checked and tried the following things already:

• The Function Discovery Resource Publication service (FDResPub) is enabled and running.
• The Function Discovery Provider Host service (fdPHost) is enabled and running (although to my understanding this is not necessary for service discovery).
• Network discovery and file and printer sharing are both turned on for the active network profile (Private) in advanced sharing settings.
• I completely disabled Windows firefall for testing (no other firewall products installed).

When hitting Ctrl+F5 in the Network view in Windows Explorer, I can see SSDP M-SEARCH requests being sent to the multicast addresses 239.255.255.250 and ff02::c. The IPv6 address ff02::c is a link-local multicast address and is not routed to the other network, but the request sent to 239.255.255.250 does reach the other network and answers from devices there reach the local network. But these devices are not displayed in Windows Explorer.

I found the documentation of Windows UPnP APIs. There is a section about configuration settings that can be changed with registry keys. Most of the mentioned registry-paths exist, but none of the mentioned keys are set. The keys DownloadScope and ReceiveScope both default to 1, which allows discovery of hosts in private subnets. I also added both keys to the registry (as DWORD 32-bit), explicitly set them to 1 and rebooted the Windows machine, but Windows Explorer still only shows other computers from the same subnet.

The UPnPDeviceFinder can be used from a PowerShell to list UPnP devices (credits):

$ssdpFinder = New-Object -ComObject 'UPnP.UPnPDeviceFinder'
$ssdpFinder.FindByType('ssdp:all', 0)

This does find UPnP devices from both local and remote network, also with DownloadScope and ReceiveScope unspecified in the registry. However, the IPv6 SSDP M-SEARCH requests are sent to ff02::c even with DownloadScope and ReceiveScope both explicitly set to 1 and thus shall not be routed to other networks.

So two questions remain:

• How can Windows 10 be configured so that Windows Explorer shows devices from other networks discovered over WS-Discovery / UPnP / SSDP in the Network view?
• How can Windows 10 (UPnPDeviceFinder, Windows Explorer) be configured to broadcast IPv6 SSDP M-SEARCH requests to ff05::c or ff08::c instead of ff02::c, so that the multicast messages may be routed to other networks?

While reviewing firewall logs that were sent to me from a Windows 7 box (the box is not a server) on a tiny network, I saw thousands of incoming SSDP UDP entries. The SSDP entries were nearly constant, occurring every 3 seconds (approx 1200 log entries per hour). The last time I was asked to review the logs for that network, I don't recall seeing such traffic.

The firewall log shows the SSDP traffic as incoming. As expected, the protocol is UDP. It is almost all coming from ::1 (loopback) over a single dynamic port (49152 - 65535) with a destination address of ff02::c (IPv6 link-local), port 1900. The SSDPSRV service of Windows is the Windows service handling the requests.

Is this type of traffic normal for networks containing a Win7 box?

If not, what should be attempted to fix the issue?

As title states,

Ive detected some MDNS queries from a googlecast address, which is strange since i don't have any googlecast apps or similar installed.

Additionally My PC is sending SSDP packets to 239.255.255.250 (subnet?) regarding 'M-Search: HTTP/1.1' strings to Chrome OS machine.

MDNS Packet : 192.168.1.65 224.0.0.251 MDNS 119 Standard query 0x000b PTR _674A0243._sub._googlecast._tcp.local, "QM" question PTR _8E6C866D._sub._googlecast._tcp.local, "QM" question PTR _googlecast._tcp.local, "QM" question

SSDP Packet: 192.168.1.67 239.255.255.250 SSDP 216 M-SEARCH * HTTP/1.1

Perhaps its good to mention that i noticed the specified 'User-agent' for these SSDP packets are stated as either 'Google Chrome' or 'Chrome OS'. Is this just a default function of Google chrome to include their DIAL tech.