MP2 2.1.3 client network broadcast crippling other systems on network (1 Viewer)

[JSchuricht]

Its broadcast traffic to 239.255.255.250. It ends up flooding every active port on my network.

I'm going to move the MP2 clients to their own private vlan soon unless someone has a better idea.

 

[BlueMax1916]

Hi,

it's only one of your clients? Could it be a trojan there?

Cheers

Blue Max

 

[JSchuricht]

They both do it. It had been a monthly issue now its more frequent.
The traffic is also specific to MP2. If I terminate the process the issue goes away. SSDP is associated with 239.255.255.250. The first google hit shows its used by MP2 so I don't think its a trojan.

 

[Mr Whippy]

Did you figure this out?

New DDoS Attack Method Leverages UPnP


But if that isn't the case...

If you close the firewall on a client/server machine, MP2 client and MP server do have a lot of blocked traffic on UDP 1900 to 239.255.255.250 (UPnP / SSDP)

Within about 1 minute of closing the firewall, I have about 300 connection attempts each from the client and server for the UPnP connection.



In your case it sounds like the server/client connections fail for some reason, and then MP just starts using UPnP to find/connect to machines, but it now can't... so it just keeps flooding the network with UPnP traffic.
With multiple clients/servers I can see how the traffic volume could get pretty high.
In the time I've written this post MP2 programs have generated over 4000 connection attempts through my firewall to UPnP, and that's just loopback on a local machine setup.

I'm not sure what the specific issue in MP might be, if there are any at all. I'm somewhat surprised if UPnP best practice is to just flood a network perpetually looking for machines to connect together.



Personally I think MP2 is handling UPnP a bit wrong somewhere. At my end I run a closed outbound firewall with rules, and no matter what I specify (except 'open' outbound globally) MP2 will fail to get it's UPnP traffic past the firewall (even with explicit rules, generalised rules etc)

All it's other traffic however is fine with explicit rules. It's *just* the UPnP traffic that keeps getting blocked.

I'm doing more testing to see what it might be.

 

[JSchuricht]

It has been less frequent with MP 2.2.1 but the issue is still there.

 

[Mr Whippy]

I've just been doing more looking at what MP2 is doing on the network.

I had virtual box installed, and it created a virtual adaptor. 192.168.56.1 iirc, which is a default address.

Even that address was sending UDP traffic via the server service from what I can see.

As you're running a lot of VMs I assume they're all sending lots of traffic via virtual network adapters?

Do any of those adapters drop out occasionally?





Also the service monitor is using ipv6 (loopback alongside ipv4 loopback), despite the client being set to not use ipv6.

Once I start up the server, that also uses ipv6 addresses (loopback again), alongside ipv4 loopbacks.

Only the client appears to use ipv4 or ipv6 when asked to do so.


When I open up my outbound firewall (not blocking with rules), all these ipv6 addresses get connected on 55555 (UPnP)

So the monitor seems to think the server and client are connected, but the client won't connect (as it's set to ipv4)

Setting the client back to ipv6 (if it wants to) means MP2 is connecting locally using ipv6 loopback on 55555 for UDP, and then using ipv4 for external connections (for 80/443 for web-graphics and all that stuff)


It seems MP2 is hard-set on using ipv6 for UPnP at my end.


I'm a bit baffled about how MP2 is dealing with UPnP in this context.


As Lehmden said earlier, if your client is struggling to connect to the server over UPnP, then it may be struggling because it can't use ipv6, and is set to ipv4?!

To get my client/server happy to connect via UPnP, I also had to provide a rule (UDP on local subnet to port 1900, blanket rule). There was no way to attach this rule to any program or service (ie, the mp exes or mp service) and it work.


I'm a bit baffled here.

The documentation about exactly what connections are needed is lacking.

I think the behavior is confusing in itself which makes trying to bug-fix your issue a bit harder too.


What kind of firewalling/router/switching do you use at your end?

I know UPnP is blocked sensibly at most WAN interfaces, but is allowed across LAN. Is all your kit connecting on LAN and not some across a WAN?


Cheers

Dave

 

[JSchuricht]

I run around 65 VM's and there is a lot of traffic. However, they are spread over ~8 subnets which do not all have routes to each other.
The adapters do not drop out.

The MP clients and server do not have a software firewall enabled. Routers are PFsense.
Switches are mostly Dell Powerconnect
1x 2808 8 port gigabit
1x 3348 48 port 100mb + 2 port gigabit
2x 5324 24 port gigabit
1x 5524p 24 port gigabit POE + 2 port 10gb
1x Quanta LBM6 24 port 10gb + 4 port 1gb with Brocade firmware

I do have several site to site VPN's routed to the same network as the MP 2 clients and server. The UPnP traffic is not routed across the VPN and no remote systems are affected when MP2 starts eating up traffic on the LAN.

 

[Mr Whippy]

A lot of whoosh over my head there haha.

In any case it looks like MP2 programs are UPnP heavy while on the lookout for connections.

I can only assume that something at your end occasionally drops out (local software issue, ie, MP2) and UPnP gets itself messed up trying to reconnect and just flooding UPnP discovery traffic?


It’s interesting as iirc Kodi has a setting for turning UPnP/DLNA off, and also some timeout settings if connections aren’t found.
Obviously it can rely on hard set configs and also just stop being a pest with perpetual network traffic, looking for something that may never turn up.

 

[JSchuricht]

I'll sum it up with a picture, my network is more like what you would find in a small corporation than a home.




UPnP is flooded, its something with the physical MP2 clients. Once I figure out which one is causing the issue, terminating MP2 on that client fixes it.

 

[spachti]

All that for a one family home?
Sorry, couldn't resist, LOL.