[fixed] Client : Connetion to server problem with multiple network interfaces (4 Viewers)

[MJGraf]

Hm, I don't want to bring you guys down, but for me it only solves part of the problem.

On the server side, I can now leave all vmware interfaces activated. That's the good thing.
On the client side, I still have to disable vmnet 1 and vmnet 8 in order for the client to find the server.

I've attached the server log for the whole process (doesn't show very much) and the client log for (a) trying to connect to the server with 3 network interfaces on client side enabled and (b) connecting to the server with only one interface on client side enabled. With one interface on client-side (wlan) it works immediately. With three interfaces it doesn't work (same as above).

The three interfaces on clientside are: Wlan (192.168.2.22 and fe80::949c:2771:a3e3:1a08%11), vmnet1 (192.168.80.1 and fe80::5d4d:68fa:5356:3e50%24) and vmnet8 (192.168.169.1 and fe80::598b:1502:fb53:99c7%25).

This was tested before Albert's commit only with Smeulf's patch, but as I understand it, Smeulfs changes do not affect SSDP, which is the problem here.

I'll try to do some testing with Wireshark today. Maybe that sheds some light on this...

Thanks for all your help!
Michael

 

[MJGraf]

This is really strange. It looks like MP2-Client doesn't "hear" the answer from MP2-Server although the client computer receives them.

What I did is:
3 interfaces activated on the server; wlan: 192.168.2.30
3 interfaces activated on the client; wlan: 192.168.2.22
Started MP2-Server on the server
Startet Wireshark on the server, listening to "port 1900 and host 192.168.2.22" (i.e. listening to all ssdp packets from and to the client)
Startet Wireshark on the client, listening to "port 1900 and host 192.168.2.30" (i.e. listening to all ssdp packets from and to the server)
Started MP2-Client on the client and tried to connect to the MP2-Server

Result: negative as described above.

Attached are the Wireshark logs of server and client taken at the same time.

What I can read from these logs is:
The client sends 4 M-Search multicast packets to 239.255.255.250
These are received by the server.
MP2-Server realized the M-Searches and answers with a lot of information contained in unicast packets to the client.
client receives all these unicast packets.
But MP2-Client doesn't seem to see these packets. There is no unicast answer from the client to the server.

What happens next are again 4 M-Search multicast packets from the client to 239.255.255.250
These are received by the server.
Then there are some "notify" multicast packets from the client to 239.255.255.250
These are also received by the server.
MP2-Server again realizes the multicasts from the client and answers with a lot of information contained in unicast packets to the client.
client receives all these unicast packets.
But MP2-Client doesn't seem to see these packets. There is no unicast answer from the client to the server.

So at no point in this communication, MP2-Client sends a unicast packet to the server.

Very strange, but maybe that helps a bit for you programmer guys. I'm completely lost in the code of the UPNP-subsystem...

Cheers,
Michael

 

[MJGraf]

ok, seems as if my observation doesn't have to do anything with the problem. When I disable vmnet1 and vmnet8 on the client, the client can connect to the server, but there are no unicast packtes from 192.168.2.22 to 192.168.2.30, either. Is that normal?

Edit:
Could it have something to do with the following: In SSDPClientController it says that for sending M-Search Multicasts and receiving the respective (unicast) answers, the unicast socket is used? Therefore your changes in BindAndConfigureSSDPMulticastSocket in NetworkHelper do not have an effect on the client side.
Just an idea...

 

[Albert]

AW: Client : Connetion to server problem with multiple network interfaces

Smeulf's fix only fixes the SSDP multicast, not the GENA multicast. But SSDP is the only protocol needed for advertisement - and thus for finding the device. The GENA part becomes important much later, when UPnP events should be sent.

My commit fixes both SSDP and GENA, Smeulf's patch from above only fixes SSDP. For the problem this thread is about, both fixes should work equally - good or bad

 

[Smeulf]

From what I can see, there is still a problem with IPv4 links.

I'm still in "debug mode" to make it work correctly.

Thanks Michael for your help

 

[MJGraf]

Hi Smeulf,

thanks for all your hard work. Just to let you know: my client and server both have IPv4 and IPv6 enabled. So the problem must be with both protocols (unless it tries IPv4 first and there is an error which prevents IPv6 to be used). When I disable the vmware interfaces and therefore a connection can be established, it always uses IPv6, which makes me think that IPv6 is used before IPv4.

What I tried in the meantime is: change the binding order of the network interfaces on my client to make sure the wlan adapter is the first adapter in the binding order (was behind vmware interfaces before). But this doesn't help either.

Michael

------------------------------

Sorry for being ot, but is there a way to debug MP2-Client with VS 2010 in a virtual machine on VMWare Server 2? It always ends with a Direct3D exception, which makes sense, because VMWare Server 2 doesn't support any directx afaik. I only have VS installed on a virtual machine and since the problem seems to be on the MP2-client side I would need to start the MP2-Client in the VS IDE on the virtual machine...

-------------------------------

Some more observations:

In SSDClientController, I've added the following logging in the HandleNotifyPacket method:

if (messageType == "upnp:rootdevice")
{
UPnPConfiguration.LOGGER.Debug("upnp:rootdevice found: {0}", deviceUUID);
rootEntry.GetOrCreateDeviceEntry(deviceUUID);
if (rootEntryAdded)
fireRootDeviceAdded = true;
}

Guess what: Starting MP2-Client on my client machine with 3 network interfaces logs that it found the MP2-Server with its UUID. However, MP2-Client still tells me "currently there is no mediaportal 2 server available on the network".
Yes, there is! And you know it

Maybe this whole thing is not related to the UPNP Subsystem anymore, but it only happens when you try to search a MP2-Server via MP2-Client Gui?!?

-------------------------------

Yep, we're getting closer:

What I did:

Started MP2-Client on a client machine with only wlan adapter enabled.
Go to: Settings -> General -> Home Server -> Search for Servers
MP2-Server is found -> attach to it.
Close MP2-Client

Start MP2-Client again
Connection to MP2-Server is found immediately (i.e. all the main menu etries like music in the main menu appear)
Close MP2-Client

enabled other adapters on the client machine
Start MP2-Client again
Connection to MP2-Server is found, but only after about 5 seconds.
Close MP2-Client

Start MP2-Client again
Connection to MP2-Server is NOT found anymore - however, MP2-Server shows that the client is connected!!!
Close MP2-Client

It seems like the UPNP subsystem is working correctly, but the rest of MP2-Client doesn't realize that there is a MP2-Server...

-------------------------------

Last observations for now:

Started MP2-Client on a client machine with 3 network adapter enabled.
Disable IPv6 protocol on wlan adapter
Go to: Settings -> General -> Home Server -> Search for Servers
Tada: MP2-Server is found on 192.168.2.30 -> attach to it.
Close MP2-Client

Start MP2-Client again
MP2-Server is not found - waiting a minute or so doesn't help
Go to: Settings -> General -> Home Server -> detach from the server
Go to: Settings -> General -> Home Server -> Search for Servers
Tada: MP2-Server is found again on 192.168.2.30

Really strange...

-------------------------------

ok: very last observation:

If I have all three adapters enabled on the client, but I disable IPv6 on all adapters but the WLAN adapter (WLAN adapter has IPv4 AND IPv6 enabled), I can attach to the MP2-Server via IPv6 and when I restard MP2-Client it immediately finds the MP2-Server. Just as it should...

 

[Smeulf]

Well, the same way we had to force the multicast request to a specific network adapter, it seems we have to force all HTTP Web Request also.

I tried to implement it partially : it remains some point I don't know how to force the request to use a specific adapter, because I don't have enought information in the code. This may have an impact on playing a media hosted by the server : the media may not be found.

Anyway, Michael, can you just try this patch and tell us if it improves the communication between the client and the server ?

If it does, it means I'm on the right way, if not, then I don't have more idea for now
I'm waiting for answers before trying to implement it for the 2 remaining requests.

Cheers.

Smeulf.

[Edit 1] Important note : if you enable or disable IPv4 or IPv6, please set the interface to disabled and then to enabled before trying MP2 again. Sometimes it don't work as expected if the interfaces are not reseted.[/Edit 1]

[Edit 2] Please note there is a bug now (before my patches) when a notification comes after a server is found in the network. Using the "Handle" button in the notification don't attach the client to the server. Please use "Search for servers" instead, until the bug is fixed [/Edit 2]

 

[Smeulf]

Additional note about Firewalls :

It's highly recommended, especially with Windows 7 firewall, to allow MP2-Client.exe and MP2-Server.exe in the firewall for all ports/protocols rather than disable the firewall.

I had issues in the past when I disabled Windows 7 firewall. Sometime for any reason, the firewall was blocking the traffic after a network interface was changed to disabled or enabled, even if the firewall was disabled.

Don't ask me why... And please do it when testing MP2.

Since the MP2 executables are allowed here, I have no problems

Cheers.

 

[MJGraf]

Hi Smeulf,

sorry, you were too fast with your patch while I was trying to nail this down But it seems like you are right. This fits my observations below. I'm just posting what I've found so far and will then try your patch.

Findings:

What I did is: Have all three network interfaces up and IPv4 and IPv6 enabled on all of them.
Start MP2-Client (not being attached to a server) and try to find a server to attach to.
It didn't work as described above. However, it put lots of (hopefully self-explaining) additional log messages into the code (see Client.log attached) and found out the following:

My Wlan has these endpoints:
fe80::949c:2771:a3e3:1a08%11
192.168.2.22

My MP2-Server has UUID:
46d5e8b7-345a-4ce0-88dc-af7a1f8283f9

My MP2-Client has UUID:
bcec7594-a30e-4dc6-bc69-9124b1afa6d0

What I can see with the additional log messages is:

A UPnPServerWatcher is started
This UPnPServerWatcher has a UPnPNetworkTracker, which is also started
UPnPNetworkTracker.OnSSDPRootDeviceAdded is called for my MP2-Server
UPnPNetworkTracker.OnSSDPRootDeviceAdded calls UPnPNetworkTracker.InitializeRootDescriptor, which starts a http-request
The http-request is executed and the SSDPClientController receives a lot of SSDP Unicast Messages

The problem seems to be that for my MP2-Server UPnPNetworkTracker.InvokeRootDeviceAdded is not called. This is only called for MP2-Client itself (don't know whether this is correct that the Client registers itself as RootDevice)
This should call UPnPNetworkTracker.RootDeviceAdded (which doesn't happen)
This should call UPnPServerWatcher.OnUPnPRootDeviceAdded (which doesn't happen)

UPnPNetworkTracker.InvokeRootDeviceAdded is only called in UPnPNetworkTracker.ContinueGetServiceDescription
However, this method is never called for my MP2-Server - only for the MP2-Client itself.

UPnPNetworkTracker.ContinueGetServiceDescription is called in (a) OnDeviceDescriptionReceived and (b) OnServiceDescriptionReceived
OnServiceDescriptionReceived is never called for my MP2-Server (only for the MP2-Client itself)
But OnDeviceDescriptionReceived was called for my MP2-Server.

So the question is: When OnDeviceDescriptionReceived was called for my MP2-Server, why was ContinueGetServiceDescription not called?

The answer as follows:
When in UPnPNetworkTracker.OnDeviceDescriptionReceived the following call is made:
WebResponse response = request.EndGetResponse(asyncResult);

An exception is raised saying:
System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. ---> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat fe80::8182:603b:c84d:e985:50799

That means either (a) the MP2-Server doesn't respond in time regarding its device description or (b) the MP2-Client doesn't receive the respective answer, when it was sent by MP2-Server.

 

[MJGraf]

Hi Smeulf,

you are on the right way!!! With your patch, the MP2-Server is found and I can attach to it. After starting MP2-Client, it takes about 5-6 seconds until the MP2-Server is found, but I think this is right. The test was done with three interfaces (wlan, vmnet1, vmnet8) enabled. Every interface had IPv4 and IPv6 enabled. And it worked!

BTW: I never had anything allowed in Win7-Firewall because this is one of the first things I disable when installing a Win7-machine for use at home. So indeed MP2-Client.exe and MP2-server.exe are not allowed on client or server, but on both the firewall is disabled. If you want, I can enable the firewall on both and allow those two exes. But anyway, it already worked in my configuration now.

However, as you pointed out, playing an MP3 from the server was no longer possible. logs attached.

Thanks a lot for your hard work!
Michael