mythupnp broken with commit 52cb0b5679a5b20a55ba5cbe6b1064b72c66576f

[bib_aab@…]

The above commit assumes MythTV runs on private networks only.

I have news for you, I like many others run an public IP addresses.

This commit spews out packets from the non-existent IP address 192.168.0.1:1900.

It also logs the following:

SSDP Request from WAN IP address (0.0.0.0). Possible SSDP Reflection attempt. Ignoring as security risk.

It must only send these packets out from directly connected networks and should not under any circumstances make any bad assumptions about which network it is running on.

[stuartm]

UPnP (and MythTV) is not secure on a public network.

[ggjunker@…]

I don't run on a public network and I am spammed by this message anyway. I have all services from the WAN-connected router disabled, so nothing is being forwarded to my private network. The router confirms that nothing I don't know about is connected to the network either, whether wired or wireless. The only devices on the network that are involved in UPnP are the mythtv backend (ubuntu on a Corei7 box), the frontend (running mythbuntu on a NUC) and the HRHomeRun device.

If the message is harmless in this environment that's fine, but it would be great if it would go away if it's not saying anything useful.

This is after the update to fixes/0.27-4 (for the SchedulesDirect? issue).

[ggjunker@…]

(I should add that I am spammed only by the "SSDP Request from WAN IP address (0.0.0.0)." message)

[ggjunker@…]

(I should add that I am spammed only by the "SSDP Request from WAN IP address (0.0.0.0)." message)

[ryan15309470@…]

Getting the same messages. Loaded up wireshark. Seems to be caused by any UPNP SSDP discover message on the local network sent to the 239.255.255.250 SSDP broadcast address . Possibly because the local subnet address is different from the standard 192.168.1.1? Haven't tried changing my networks subnet but only other solution seems to be disabling UPNP. Seems to be a harmless warning but annoying because it fills up the logs fast... any other possible solutions?

[stuartm]

I'll suppress the warning if the source IP address is missing (0.0.0.0).

[matt.r.parrish@…]

I am seeing these same errors and upnp is no longer working for me after upgrading to 0.27.4 (on Mac / Yosemite). I'm not sure what the issue is as it was working fine with 0.27.1. Is it related to these SSDP error messages I'm seeing in the logs that is mentioned in this thread? My entire home network is on 192.168.1.* network, so I'm not sure why these messages are showing up, indicating that the IP address is from the WAN. Any ideas?

[Stuart Morgan <smorgan@…>]

In d20c163ee82c38f9d8fe4652b7a811af61925de7/mythtv:

SSDP: Check that the peer address is available before doing the local network check.

Refs #12305

[Stuart Morgan <smorgan@…>]

In 65d92fd36ecf796d8e8a18b3196286d31b28501e/mythtv:

SSDP: Check that the peer address is available before doing the local network check.

Refs #12305

(cherry picked from commit d20c163ee82c38f9d8fe4652b7a811af61925de7)

[dave@…]

Could this be related to multiple network interfaces being available on the host?

I've tried blocking the IPv4 traffic to port 1900 on the INPUT rule in my firewall for all interfaces and I'm still getting the SSDP request error and the firewall is not logging any SSDP packets inbound on any connections either through tcp or udp protocols. Could mythtv somehow be looping back into itself?

These messages propagate in blocks of 8 every couple of seconds - myth somehow has started 8 IPv6 connections correlating to each of my active NICs on the device. This is a little too coincidental.

[stuartm]

The code in question has been completely reverted, so you can't still be getting the same error unless you haven't yet upgraded.

[dave@…]

Once I disabled IPv6 in the kernel, all the SSDP messages went away. If you are having this issue and waiting for a fix to mythtv to accomodate IPv6, you should disable IPv6 in your kernel to eliminate these messages.

[dave@…]

I've been running mythtv for 10 years and started using stock distributions about 5 years back - I don't download and compile apps unless absolutely necessary. The Fedora Core 19 package has not picked up the updates yet - so anyone who is not into compiling the code should just turn off IPv6 until the new version is repackaged and distributed.

[brian@…]

Replying to dave@…:

anyone who is not into compiling the code should just turn off IPv6 until the new version is repackaged and distributed.

That doesn't seem to be a viable solution for networks which are built with IPv6. It is the 21st century now. IPv4 should be getting turned off and IPv6 should be getting turned on.

Any software not properly supporting IPv6 needs to catch up, really quickly.