MP2 2.1.3 client network broadcast crippling other systems on network (2 Viewers)

[HTPCSourcer]

@JSchuricht , do you still observe these issues with the most recent version 2.2.2?

 

[JSchuricht]

It's too early to tell. Sometimes it goes for a few months, other times a few hours between issues. It's probably been a month since 2.2.1 had the issue, 2.2.2 has only been on my systems for a few days.

 

[JSchuricht]

It just happened with 2.2.2.

 

[Trigg3r]

There is a lot of network topology here it seems, seeing as you are able to report on the issue while it happens, would it be possible for you to run a tool such as Fiddler to record the network traffic? That may at least reveal what is trying to talk to what...

 

[JSchuricht]

The network has changed a bunch since this issue started. I moved most of the systems other than MP2 to different subnets on their own vlan's. I have one more vlan planned for the media portal systems just because of this issue. Also the topology has changed, MP2 server has a single 10Gb link to a Brocade ICX 6610, hopefully with SR-IOV soon. One MP2 client has 1Gb to the ICX 6610, the 2nd MP2 client is now wireless to a Dlink DAP 2660 which connects by 1Gb to a Dell Powerconnect 5524P then 2x 10Gb LAG back to the Brocade ICX 6610.

I'll take a look at Fiddler, I was planning some port mirroring going to an IDS but Fiddler may be quicker to setup till I get around to deploying the big guns.

 

[JSchuricht]

WIP 135 x64 client has this issue too. I didn't see anything in fiddler, looks like it was monitoring http traffic but wireshark is pointing to MP2 UPnPServer. I disabled the network cards through windows several days ago after I detected the network issue hoping that the client would still be doing it's thing when I had time to look at it. When I checked the client today, it was still using a huge amount of CPU even with the network disabled. Enabling the network card resumed the 3,000-11,000 packets per second broadcast to SSDP 239.255.255.250.

Grabbed a bunch of screenshots from wireshark, process explorer and a few other places plus wireshark captures and client logs.

 

[Trigg3r]

That's an impressive amount of information provided

Had a quick look over and a couple of bits stick out, but I need to digest things a bit more and time is not on my side right now, please keep us updated and I will try to come back to this when I have some more time, unless you resolve before then

Leon

 

[JSchuricht]

One thing I have noticed is the issue seems to happen when a MP2 client is left running without any interaction for a long period. I have a MP2 client only install on my main desktop for testing. I had MP2 minimized for a few days without using it and randomly while using the computer for other stuff all of my RDP sessions loose connection and I find the system broadcasing a bunch of traffic. That might give some clue on how to duplicate this. Leave a MP2 client open for a few weeks without using it and cross your fingers. I haven't found a specific trigger which makes this vary difficult to find.

 

[morpheus_xx]

I recently fixed a small bug when handling SSDP Notify messages. The "CONFIGID" value was once defined as "signed" and then later parsed as "unsigned". I now have seen negative CONFIGIDs that then failed to be parsed as unsigned. The message then was no longer handled.

But I have no idea if this has anything to do with this issue here, just wanted to mention it.

 

[JSchuricht]

@morpheus_xx If the bug you fixed was pushed to WIP 157 then it wasn't this issue. I just had another broadcast storm from a WIP 157 client.