locked
Problem with UDP broadcast on ARM

    Question

  • My application is implementing its own DNS discovery in order to find hosts that are implementing a certain service on the local network. The code I'm using work fines on an x86 system but when I try to run it on my Surface RT I get an error from the result of GetOutputStreamAsync. Below is an example of what I'm trying to do. Here I'm using raw API calls to break out the step I'm taking in a more explicit way. My actual code is using the task template library, but the end failure is the same. Inside of the Completed function I check for the returned error code and which is 0x80072af9, which from my searching is a "host not found" error. I'm wondering if I'm up against some networking restriction on the ARM platform.

    	task<void>(socket->BindServiceNameAsync("5353")).then([this, _protocol] (task<void> previousTask)
    	{
    		try 
    		{
    			previousTask.get();
    			socket->JoinMulticastGroup(ref new HostName("224.0.0.251"));
    
    			IAsyncOperation<IOutputStream^> ^op = socket->GetOutputStreamAsync(ref new HostName("224.0.0.251"), "5353");
    
    			op->Completed = ref new AsyncOperationCompletedHandler<IOutputStream^>
    				([this, _protocol](IAsyncOperation<IOutputStream^> ^op, Windows::Foundation::AsyncStatus status)
    			{
    				
    				auto ec = op->ErrorCode;  // returns 0x80072af9
    				IOutputStream ^ostream = op->GetResults();
    
    				DataWriter	^writer = ref new DataWriter(ostream);
    
    				std::wstring p = _protocol->Data();
    				this->WriteQueryMessage(p, writer);
    				writer->StoreAsync();
    			});
    		}
    		catch(Exception^ ex)
    		{
    			std::wstring error = ex->Message->Data();
    			OutputDebugString(error.c_str());
    		}
    	});

    Sunday, September 29, 2013 9:30 PM

Answers

  • Hi Jim,

    You could possibly try to use the following 'Display' filters in Netmon to see if they help:

    - protocol.UDP

    - ContainsBin(FrameData, ASCII, "<your search string>")

    Hopefully that should give you some additional information.

    If you cannot get to the problem on your own, I would recommend opening a support case so that you can share your network trace with us.

    You may already have support cases associated with your developer account so you can use your developer account to open a support case.  

    1.)    Visit the URL: http://aka.ms/storesupport with your developer account. 
    2.)    Towards the bottom of the page, there is a link that says “…contact us immediately.” 
    3.)    Click that link and then it will ask you to choose the support type. To reach the correct support team choose the following: 
    a. Problem Type: “Technical support for Windows Store and Windows Phone app development” 
    b. Category: “appropriate category" 
    c. Once you do that, there should be an option that lets you “Request a call”/ “Start Email”

     

    Thanks,

    Prashant


    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Thursday, October 03, 2013 11:50 PM
    Moderator

All replies

  • Does that HOST '224.0.0.251' support any other protocols?  Can you verify you can hit it from the ARM tablet outside your code?

    Finally you can use netsh to trace traffic.  I don't have my surface handy at the moment but the show scenarios and show providers will give you a bunch of options: http://msdn.microsoft.com/en-us/library/windows/desktop/dd569142(v=vs.85).aspx


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Monday, September 30, 2013 12:34 PM
    Moderator
  • 224.0.0.251 is the multicast address for mDNS, not a distinct host. I'm using it to enumerate devices on the network that support the apple_midi protocol.
    Monday, September 30, 2013 3:05 PM
  • And what was the result of the netsh tracing?  I found an early bug for connectAsync but that was fixed and is says that GetOutputStreamAsync works fine.


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Monday, September 30, 2013 6:34 PM
    Moderator
  • Well for some reason my mDNS discovery started working when I took my Surface RT to another network for test. The 0x80072af9 error is not fatal. After the error the program can continue and still receive announcements from system that support the service I'm querying for. I got back to my development network and made sure that all the devices that I needed to communicate were seeing each other on the network. I then ran a test and things appear to be working. I'm glad that it turned out not to be a problem with the ARM platform after all.

    I never ran a netsh script, but I'll try that sometime if and when I run into any other show stoppers with network connectivity.

    Tuesday, October 01, 2013 2:17 AM
  • OK Jim,

    Glad it was some transient network issue!  Zap us if you see this again and we can troubleshoot with the netsh method!

    Jeff


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, October 01, 2013 2:46 PM
    Moderator
  • Well, I'm still having issues multicast and the Surface RT. From what I can tell the initial mDNS broadcast to query for services is not leaving the tablet. I monitored traffic with Wire Shark on a Mac Book Pro and I'm seeing nothing when running my application on my Surface RT. When I run my application on a desktop or other x86 machine then I'm seeing the mDNS query hitting the MBP.

    The reason that I thought that things might of been working was because if my application is running it is still listening for query responses, even through the initial query was never sent. Then when I startup something like Garage Band on the MBP then it does a broadcast of the services it supports. My application receives the query and then lists the MBP as a system that it is ready to communicate with.

    I guess I'll have to get familiar with netsh, since it is the only tool available on the Surface RT for monitoring network traffic.

    Wednesday, October 02, 2013 2:39 AM
  • Hi Jim,

    Can you collect a trace on your Surface RT using the following commands?

    1. Open an elevated command prompt and type: netsh trace start scenario=InternetClient capture=yes

    2. Repro issue

    3. Stop the trace using the command: netsh trace stop

    4. When you stop the trace, you should get a ETL file. The location of the ETL file should be seen in (1) and (3)

    5. Copy this ETL trace on a x86/x64 machine and use Microsoft Network Monitor 3.4 to open it. Then you can analyze traffic by either looking for DNS activity or regular network traffic.

    Thanks,

    Prashant.


    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Wednesday, October 02, 2013 5:08 PM
    Moderator
  • I performed a capture on the Surface RT and loaded the capture file in Netmon 3.4. I'm not seeing anything outgoing from the tablet related to my initial mDNS query.

    Netmon is rugged beast for me to tackle right now. Obviously it is deep and with lots of features but I'm not seeing anything in it that resembles any of the network traffic I'm expecting from the Surface. It will probably take me a weekend of studying to get familiar with Netmon before I can be productive with it.

    From my diagnosis using Wireshark I'm seeing an initial IGMP packet from the Surface to the Mac, which correlates to the initial JoinMulticastGroup(ref new HostName("224.0.0.251) call. After that then nothing. The next thing I should see coming from the Surface is  the mDNS query. This is the block of code with the GetOutputStreamAsync that is generating the "no such host is known" error.

    So at this point I'm kind of stuck. I don't think diving into Netmon is going to tell me anything more that I already know - That the network stack is generating an unexpected error an refusing to send my data.

    Thursday, October 03, 2013 3:08 AM
  • Hi Jim,

    You could possibly try to use the following 'Display' filters in Netmon to see if they help:

    - protocol.UDP

    - ContainsBin(FrameData, ASCII, "<your search string>")

    Hopefully that should give you some additional information.

    If you cannot get to the problem on your own, I would recommend opening a support case so that you can share your network trace with us.

    You may already have support cases associated with your developer account so you can use your developer account to open a support case.  

    1.)    Visit the URL: http://aka.ms/storesupport with your developer account. 
    2.)    Towards the bottom of the page, there is a link that says “…contact us immediately.” 
    3.)    Click that link and then it will ask you to choose the support type. To reach the correct support team choose the following: 
    a. Problem Type: “Technical support for Windows Store and Windows Phone app development” 
    b. Category: “appropriate category" 
    c. Once you do that, there should be an option that lets you “Request a call”/ “Start Email”

     

    Thanks,

    Prashant


    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Thursday, October 03, 2013 11:50 PM
    Moderator