Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Discovery issue when VPN server is running
29-01-2016, 10:53 PM
Post: #1
Discovery issue when VPN server is running
Running a VPN server on the same Linux machine as an ohNet server application causes some control points to fail to discover the ohNet application. I have been aware of this for some time but I have only recently been able to identify what is causing the problem.

1) Running a VPN server creates an additional "virtual" network adapter with a different IP address. On my test server, the "real" address is 192.168.0.10 and the VPN "virtual" address is 10.8.0.1.

2) When a UPnP control point sends an M-SEARCH message, Linux delivers this message on the real network adapter and it also delivers a copy of this message on the VPN network adapter. This is caused by the Linux bug that is described in the comment at the start of CpiDeviceListUpnp::IsLocationReachable.

3) The ohNet device stack receives both M-SEARCH messages and sends HTTP 200 OK responses for them. Each response is sent via the "correct" network adapter (using Bind to ensure this) and contains a LOCATION: header for the server IP address for the adapter on which it is being sent. On my test server, the response sent via the real adapter has a LOCATION: header for 192.168.0.10 and the response sent via the VPN adapter has a LOCATION: header for 10.8.0.1.

4) This seems OK so far, but it isn't. The HTTP 200 OK response sent via the VPN network adapter is forwarded by Linux to the real network adapter and sent to the control point. This seems closely related to the Linux bug described in 2) above. The control point also receives the HTTP 200 OK response sent via the real network adapter.

5) The control point receives two HTTP 200 OK responses with different LOCATION: information for the server machine but otherwise identical content. One of these contains a valid reachable IP address for the server machine and the other contains the VPN address for the server machine, which isn't reachable by the control point.

6) If the HTTP 200 OK response with a valid IP address happens to arrive first, it is processed by the control point and discovery is successful. If the HTTP 200 OK response with the unreachable IP address arrives first, the control point attempts to process it but cannot reach the server. For some control points, this causes a discovery failure condition that persists even when the other HTTP 200 OK response with a valid IP address is received slightly later.

7) The fix is to add a reachability check in DviProtocolUpnp.cpp when an M-SEARCH message is received. This check is used to suppress the HTTP 200 OK response to any M-SEARCH message sent by a control point that isn't reachable via the adapter on which the M-SEARCH message was delivered. This is similar to the reachability check that is already applied in CpiDeviceListUpnp::IsLocationReachable when a control point receives an "alive" message from a server.

A patch is attached. I have tested this with Wireshark to confirm that the incorrect responses are not sent. This patch has also been tested by MinimServer users to confirm that it fixes the discovery problem and doesn't cause any other issues.


Attached File(s)
.zip  vpnbug.zip (Size: 1.28 KB / Downloads: 1)
Find all posts by this user
01-02-2016, 11:57 AM (This post was last modified: 01-02-2016 11:58 AM by simonc.)
Post: #2
RE: Discovery issue when VPN server is running
Thanks for tracking this down! I've applied the fix locally now.
Find all posts by this user
03-02-2016, 05:37 PM
Post: #3
RE: Discovery issue when VPN server is running
(01-02-2016 11:57 AM)simonc Wrote:  Thanks for tracking this down! I've applied the fix locally now.

Thanks for the quick response and fix. I have built and tested the current code and it is now released as part of the latest MinimServer update. Smile
Find all posts by this user


Forum Jump: