Bug 1468 - WS-Discovery fails to read response
Summary: WS-Discovery fails to read response
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System.Web.Services ()
Version: 2.10.x
Hardware: PC Linux
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-10-13 02:19 UTC by Andrew Buchanan
Modified: 2016-08-29 08:59 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
soap discovery request xml to optionally use with sample (1.10 KB, application/xml)
2011-10-13 02:25 UTC, Andrew Buchanan
Details
wireshark pcap of working discovery (22.95 KB, application/octet-stream)
2011-10-13 02:32 UTC, Andrew Buchanan
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 1468 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description Andrew Buchanan 2011-10-13 02:19:01 UTC
I'm sending a basic WS-Discovery message using the WSDiscoveryApril2005.  In .net 4/win7 it works as expected and I receive my responses. In mono 2.10.6/linux I receive the following exception.

Unhandled Exception: System.ServiceModel.EndpointNotFoundException: The discovery client could not receive Find operation response within the operation timeout.
  at System.ServiceModel.Discovery.VersionApril2005.DiscoveryTargetClientApril2005.Find (System.ServiceModel.Discovery.FindCriteria criteria)


I have confirmed with wireshark that the multicast find request is sent, I don't know why it fails to receive the responses.  I wrote some test code to do it manually using udp sockets. I can join the multicast group, send the request, and receive the responses.  The test code works on .net and mono so I don't think there is anything wrong with my network/systems/etc.  Obviously I could just use that code, but I'd like to help fix the issue. 

I can provide pcap captures, a sample app, ssh access, whatever.


This is the discovery code I'm using.

            UdpDiscoveryEndpoint ude = new UdpDiscoveryEndpoint(DiscoveryVersion.WSDiscoveryApril2005);
            DiscoveryClient discoveryClient = new DiscoveryClient(ude);
            FindCriteria findCriteria = new FindCriteria();
            findCriteria.ContractTypeNames.Add(new XmlQualifiedName("NetworkVideoTransmitter", @"http://www.onvif.org/ver10/network/wsdl"));
            findCriteria.MaxResults = 512;
            findCriteria.Duration = TimeSpan.FromSeconds(5);
            FindResponse findResponse = discoveryClient.Find(findCriteria);
            var eps = findResponse.Endpoints;


And again this is the exception:

Unhandled Exception: System.ServiceModel.EndpointNotFoundException: The discovery client could not receive Find operation response within the operation timeout.
  at System.ServiceModel.Discovery.VersionApril2005.DiscoveryTargetClientApril2005.Find (System.ServiceModel.Discovery.FindCriteria criteria)



I also tried using the FindAsync method with a callback (FindCompletedEventArgs e), but the e.Result is null.
Comment 1 Andrew Buchanan 2011-10-13 02:24:05 UTC
Simple code to do it manually

            Socket udpSock = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            var ip = System.Net.IPAddress.Parse("239.255.255.250");
            udpSock.Bind(new IPEndPoint(System.Net.IPAddress.Parse("192.168.1.115"), 0));//your machine ip address

            udpSock.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.AddMembership, new MulticastOption(ip));
            udpSock.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.MulticastTimeToLive, 2);
            IPEndPoint ipep = new IPEndPoint(ip, 3702);

            var bytes = Encoding.ASCII.GetBytes(File.ReadAllText("ws-request-net.xml"));
            udpSock.SendTo(bytes, ipep);
            byte[] data = new byte[8000];
            int len = 0;
            EndPoint iep = new IPEndPoint(System.Net.IPAddress.Any, 3702);
            while ((len = udpSock.ReceiveFrom(data, ref iep)) > 0)
            {
                Console.WriteLine("Received {0} bytes from {1}", len, iep.ToString());
            }
            Console.ReadLine();
Comment 2 Andrew Buchanan 2011-10-13 02:25:53 UTC
Created attachment 686 [details]
soap discovery request xml to optionally use with sample
Comment 3 Andrew Buchanan 2011-10-13 02:32:40 UTC
Created attachment 687 [details]
wireshark pcap of working discovery

my windows/.net4 machine is 192.168.1.115, the network cameras I'm 'discovering' are 192.168.1.63 and 192.168.1.67.  you can see both the working discover/responses

my linux/mono 2.10.6 machine is 192.168.1.1, you can see in the pcap it does send the discover message, the pcap doesn't show the responses because I ran wireshark from the windows machine but I'm sure they are there.  The simple udp socket code I posted works on the mono machine and I've tried sending exactly the same xml as mono as well as exactly the same xml as .net and both ways work.
Comment 4 Martin Sherburn 2016-02-01 10:18:38 UTC
I have just hit the same problem (5 years later :)). I noticed both from your wireshark capture and captures I've done myself that UDP data sent from the mono code contains 3 extra characters at the start of the XML data which I believe is causing the problem. Here is the data from one of the packets in your wireshark capture:

0000   ef bb bf 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e  ...<?xml version
0010   3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d  ="1.0" encoding=
0020   22 75 74 66 2d 38 22 3f 3e 3c 73 3a 45 6e 76 65  "utf-8"?><s:Enve
0030   6c 6f 70 65 20 78 6d 6c 6e 73 3a 61 3d 22 68 74  lope xmlns:a="ht
0040   74 70 3a 2f 2f 73 63 68 65 6d 61 73 2e 78 6d 6c  tp://schemas.xml
0050   73 6f 61 70 2e 6f 72 67 2f 77 73 2f 32 30 30 34  soap.org/ws/2004
0060   2f 30 38 2f 61 64 64 72 65 73 73 69 6e 67 22 20  /08/addressing" 
0070   78 6d 6c 6e 73 3a 73 3d 22 68 74 74 70 3a 2f 2f  xmlns:s="http://
0080   77 77 77 2e 77 33 2e 6f 72 67 2f 32 30 30 33 2f  www.w3.org/2003/
0090   30 35 2f 73 6f 61 70 2d 65 6e 76 65 6c 6f 70 65  05/soap-envelope
00a0   22 3e 3c 73 3a 48 65 61 64 65 72 3e 3c 61 3a 41  "><s:Header><a:A
00b0   63 74 69 6f 6e 20 73 3a 6d 75 73 74 55 6e 64 65  ction s:mustUnde
00c0   72 73 74 61 6e 64 3d 22 31 22 3e 68 74 74 70 3a  rstand="1">http:
00d0   2f 2f 73 63 68 65 6d 61 73 2e 78 6d 6c 73 6f 61  //schemas.xmlsoa
00e0   70 2e 6f 72 67 2f 77 73 2f 32 30 30 35 2f 30 34  p.org/ws/2005/04
00f0   2f 64 69 73 63 6f 76 65 72 79 2f 50 72 6f 62 65  /discovery/Probe
0100   3c 2f 61 3a 41 63 74 69 6f 6e 3e 3c 61 3a 4d 65  </a:Action><a:Me
0110   73 73 61 67 65 49 44 3e 75 72 6e 3a 75 75 69 64  ssageID>urn:uuid
0120   3a 36 38 38 36 62 61 63 34 2d 39 32 33 34 2d 34  :6886bac4-9234-4
0130   66 62 35 2d 39 61 39 63 2d 65 64 65 65 34 34 38  fb5-9a9c-edee448
0140   36 32 61 35 37 3c 2f 61 3a 4d 65 73 73 61 67 65  62a57</a:Message
0150   49 44 3e 3c 2f 73 3a 48 65 61 64 65 72 3e 3c 73  ID></s:Header><s
0160   3a 42 6f 64 79 3e 3c 50 72 6f 62 65 20 78 6d 6c  :Body><Probe xml
0170   6e 73 3a 69 3d 22 68 74 74 70 3a 2f 2f 77 77 77  ns:i="http://www
0180   2e 77 33 2e 6f 72 67 2f 32 30 30 31 2f 58 4d 4c  .w3.org/2001/XML
0190   53 63 68 65 6d 61 2d 69 6e 73 74 61 6e 63 65 22  Schema-instance"
01a0   20 78 6d 6c 6e 73 3d 22 68 74 74 70 3a 2f 2f 73   xmlns="http://s
01b0   63 68 65 6d 61 73 2e 78 6d 6c 73 6f 61 70 2e 6f  chemas.xmlsoap.o
01c0   72 67 2f 77 73 2f 32 30 30 35 2f 30 34 2f 64 69  rg/ws/2005/04/di
01d0   73 63 6f 76 65 72 79 22 3e 3c 64 3a 54 79 70 65  scovery"><d:Type
01e0   73 20 78 6d 6c 6e 73 3a 70 30 3d 22 68 74 74 70  s xmlns:p0="http
01f0   3a 2f 2f 77 77 77 2e 6f 6e 76 69 66 2e 6f 72 67  ://www.onvif.org
0200   2f 76 65 72 31 30 2f 6e 65 74 77 6f 72 6b 2f 77  /ver10/network/w
0210   73 64 6c 22 20 78 6d 6c 6e 73 3a 64 3d 22 68 74  sdl" xmlns:d="ht
0220   74 70 3a 2f 2f 73 63 68 65 6d 61 73 2e 78 6d 6c  tp://schemas.xml
0230   73 6f 61 70 2e 6f 72 67 2f 77 73 2f 32 30 30 35  soap.org/ws/2005
0240   2f 30 34 2f 64 69 73 63 6f 76 65 72 79 22 3e 70  /04/discovery">p
0250   30 3a 4e 65 74 77 6f 72 6b 56 69 64 65 6f 54 72  0:NetworkVideoTr
0260   61 6e 73 6d 69 74 74 65 72 3c 2f 64 3a 54 79 70  ansmitter</d:Typ
0270   65 73 3e 3c 4d 61 78 52 65 73 75 6c 74 73 20 78  es><MaxResults x
0280   6d 6c 6e 73 3d 22 68 74 74 70 3a 2f 2f 73 63 68  mlns="http://sch
0290   65 6d 61 73 2e 6d 69 63 72 6f 73 6f 66 74 2e 63  emas.microsoft.c
02a0   6f 6d 2f 77 73 2f 32 30 30 38 2f 30 36 2f 64 69  om/ws/2008/06/di
02b0   73 63 6f 76 65 72 79 22 3e 35 31 32 3c 2f 4d 61  scovery">512</Ma
02c0   78 52 65 73 75 6c 74 73 3e 3c 44 75 72 61 74 69  xResults><Durati
02d0   6f 6e 20 78 6d 6c 6e 73 3d 22 68 74 74 70 3a 2f  on xmlns="http:/
02e0   2f 73 63 68 65 6d 61 73 2e 6d 69 63 72 6f 73 6f  /schemas.microso
02f0   66 74 2e 63 6f 6d 2f 77 73 2f 32 30 30 38 2f 30  ft.com/ws/2008/0
0300   36 2f 64 69 73 63 6f 76 65 72 79 22 3e 50 54 35  6/discovery">PT5
0310   53 3c 2f 44 75 72 61 74 69 6f 6e 3e 3c 2f 50 72  S</Duration></Pr
0320   6f 62 65 3e 3c 2f 73 3a 42 6f 64 79 3e 3c 2f 73  obe></s:Body></s
0330   3a 45 6e 76 65 6c 6f 70 65 3e                    :Envelope>

Note the 3 first characters in hex are "ef bb bf" which are not valid ASCII characters (greater than 7F). Did you ever come to a resolution on this Andrew or did you just continue using your custom code?
Comment 5 Andrew Buchanan 2016-02-01 18:02:09 UTC
To be honest - I haven't done much with it since.  I really dislike doing anything to do with soap by hand so I was hoping at the time that somebody from xamarin would respond and look into the issue.  It looked like me like the fix was probably pretty straightforward for somebody who knew the codebase.

I haven't looked at whether it's been fixed since though.  I'm assuming you tried mono 4.2+?
Comment 6 Martin Sherburn 2016-02-02 09:23:43 UTC
Yes I tried the latest and it still doesn't work. I am also trying to use ONVIF, I skipped to the next step of trying to GetDeviceInformation but it failed to work in mono as well. It seems like mono doesn't really have enough WCF support to meet my requirements. I'm going to try an alternate solution.
Comment 7 Andrew Buchanan 2016-02-02 16:18:50 UTC
I know I've gotten the basic webservice stuff working in mono such as getDeviceInformation but if the camera is using authentication I was unable to get that working under mono.  I'm curious if .net core has wcf client support, it may as https://www.dotnetfoundation.org/blog/wcf-is-open-source suggests it could/should but I haven't tried that.  Looking at the status page for https://github.com/dotnet/wcf/ it look like System.ServiceModel.Security isn't fully operational so authentication may still be a problem depending on what's done and not done.  Otherwise I'm sure java has a working soap stack in linux.
Comment 8 Andoni Morales 2016-08-27 18:29:48 UTC
I am hitting the same issue, but after debugging it, the 3 bytes at the beginning of the message have nothing to do with the bug. These bits are the encoding preamble for UTF-8 ( https://msdn.microsoft.com/en-us/library/system.text.encoding.getpreamble(v=vs.110).aspx ) and removing them from the message leads to same error.
Comment 9 Andoni Morales 2016-08-27 18:30:32 UTC
By the way, I reproduce it in OS X too.
Comment 10 Andoni Morales 2016-08-29 08:59:09 UTC
I have made some good progress here: https://github.com/ylatuya/mono/tree/bug-1468

It now receives a reply but fails to deserialize it with this exception:

Exception There was an error deserializing the object of type System.ServiceModel.Discovery.VersionApril2005.MessageContractsApril2005+FindResponseApril2005. 'Element' is an invalid XmlNodeType. Line 1, position 724.   at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions (System.Runtime.Serialization.XmlReaderDelegator reader, System.Boolean verifyObjectName, System.Runtime.Serialization.DataContractResolver dataContractResolver) [0x000a6] in <20c7a2b3c4544ff38ee943768a8f0587>:0