PNRP Debugging Guide Part 1


In this installment we’ll talk about failing resolutions, registrations and communication problems between Windows XP and Windows Vista.


Name Resolution Fails


You published a name on one machine, and you can’t resolve it from another


 Check cloud status


Working with an unhealthy cloud can make your registrations and resolves fail.


netsh p2p pnrp cloud show list


This command will print out the clouds available on your machine, producing output like the following:


Scope  Id     Addr   State             Name


—–  —–  —–  —————-  —–


    3      8      1  Active            LinkLocal_2001:4898:28:2::/64


    1      0      2  Active            Global_


 


Global_ cloud does not exist


When the PNRP service starts up, it creates a cloud only if you have a Global IPv6 address.  If the Global_ cloud isn’t present, IPv6 isn’t working on your machine.  You may need to debug Teredo/6to4/ISATAP.  Refer to some of our earlier blog posts.


Global_ cloud is in the No Net state


Your network cable may have fallen out, your wireless connection went down or your interface was disabled.


Global_ cloud is in the Virtual state


The cloud hasn’t finished initializing.  If the Global_ cloud sits in this state, try running netsh p2p pnrp cloud start Global_


Global_ cloud is in the Alone state


Your PNRP instance doesn’t know about any peers.  It can’t publish or resolve names in this state.  You might have had trouble communicating with the PNRP seed server when bootstrapping.


-Make sure you have a firewall exception for PNRP.  By default, PNRP uses UDP port 3540.


-Check your seed server setting using  netsh p2p pnrp cloud show seed Global_.   By default, Windows Vista is configured to use pnrpv2.ipv6.microsoft.com and pnrpv21.ipv6.microsoft.com.


-Try sending a PNRP ping to the seed server using netsh p2p pnrp diag ping seed Global_


-Try sending an ICMP ping to the seed server using ping-6 pnrpv2.ipv6.microsoft.com


-Test your internet connectivity and make sure you have a usable ipv6 address.


 


Link Local cloud is in the Alone state


If you’re using PNRP to resolve names published on the same link, you can use the Link Local cloud.  If you have only one PNRP node on a link, you can expect your link local cloud to sit in the alone state.  If you know that you have neighboring PNRP nodes on your link, there are some things you can do to get your link local cloud working:


          Check the Firewall setting for PNRP port which is UDP 3540.


          Check the Firewall setting for SSDP port which is UDP 1900.


          Check whether the corporate policy allow multicast IPv4 or IPv6 traffic.


          Check whether there is other PNRP nodes in the same Link.


          Check the status of SSDP Service using services.msc.


 


Test connectivity between the two machines


The last step in a name resolution involves a direct connection between the resolver and the publisher (unlike DNS).  If this connection can’t be established, the name resolution will fail.  Direct connectivity can fail for a number of reasons.  Both peers might be behind symmetric NATs (Teredo won’t work in this case), a firewall might be misconfigured, etc.


You can test connectivity between PNRP nodes with this command:


Netsh p2p pnrp diag ping host [host=]{<ip address> | <host name>}  [cloud=]<cloud name>


The output of the command can be a little confusing.  Ping host does more than an echo request.  When one node PNRP pings another, it actually asks for cache entries.


If the command succeeds, you’ll see the following message:


SOLICIT sent to address: [IP address]:3540.


ADVERTISE returned 5 ID(s) in 0 milliseconds.


… followed by the IDs.


If the command fails, you’ll see the following


Destination did not respond (error 0x80980800).


Make sure the name is really registered


A PNRP name only lasts as long as the process that registered it.  This includes registrations made with NetSH.  The command netsh p2p pnrp peer add registration registers a name.  If you call this from the command line, NetSH starts up, registers a name and immediately exits, tearing down the publication.  If you want to publish a name that lasts, call add registration from the p2p peer netsh context and leave the console window open.


Netsh p2p pnrp cloud show names will print out a list of all the names registered on the machine. 


You can’t register a name with NetSH, then resolve it with the same NetSH context


The NetSH commands assume that this isn’t an interesting diagnostic.  I realize that this is likely your first test when you start playing with PNRP.  You open a command prompt, start NetSH, register a name then try and resolve it in the same window.  If you want to use a single machine to test PNRP publication and resolution, use two separate consoles and two separate NetSH contexts.


 


My XP and Vista Machines don’t interact


Your XP machine might be running PNRP v1.0, which is not compatible with PNRP v2.0 on Windows Vista.  You can upgrade your XP machine to PNRP v2.0 by installing KB 920342.  You can find information about the update and a download link here:


http://support.microsoft.com/default.aspx/kb/920342


The PNRP component may not be enabled on your XP machine.  To enable the component:


          Select Add / Remove programs


          Select Add / Remove Windows components


          Select Networking Services and click on details


          ensure that the Peer to peer check box is ticked and then select Okay followed by Next


          The Windows installer will do its thing then you should select Next  followed by Finish


Test the install by running netsh p2p pnrp cloud show list from a command prompt.  You should see at least a link local and a global PNRP cloud.  If you’re missing the Global_ cloud, you’ll need to take some extra steps to get IPv6 working.


 


My Registration Failed


To register a name, you need to have all the same capabilities needed to resolve a name.  Make sure that you’re publishing into an existing, active cloud.


PNRP can be set to resolve only mode using netsh p2p pnrp cloud set pnrpmode RO Global_


A system administrator might set the computers he manages to resolve only.  You can check the pnrp mode of each of your clouds using the netsh p2p pnrp cloud show stat command.  Look for the Cloud Operational Mode field.  It will read “Full Participant” if you’re able to publish names, or  “Resolve Only.”  You switch between resolve only and full participation with the netsh p2p pnrp cloud set pnrpmode command.  You’ll need administrative access.


If you use NetSH to register a name in a resolve only cloud, you’ll get the following error message:


C:\>netsh p2p pnrp peer add registration 0.myName Global_


Cloud is in Search Only mode (error 0x80072cf1).


 


 Thanks!


-Tyler and Pritam


Comments (6)

  1. adityayadav76 says:

    Hi,

    I try to start P2P channel inside a C# inproc COM component loaded in IE as an add in.

    It says default resolver not available.

    Can you add how to resolve that, information on the p2p debugging section on your blog?

  2. DJDrEvil says:

    adityayadav76: Did you verify you have PNRP enabled like the article says?  If so make sure you set the resolver to PNRP. And make sure your security settings match.

    For instance in the example chat app (converted from the horrible app.config to an imperative configuration):

    <snip>

    InstanceContext instanceContext = new InstanceContext(new ChatApp(member));

    NetPeerTcpBinding chatBinding = new NetPeerTcpBinding();

    chatBinding.Security.Mode = SecurityMode.None;

    chatBinding.Resolver.Mode = PeerResolverMode.Pnrp;

    DuplexChannelFactory<IChatChannel> factory =

       new DuplexChannelFactory<IChatChannel>

           (instanceContext,

            chatBinding,

            "net.p2p://chatMesh/ServiceModelSamples/Chat");

    IChatChannel participant = factory.CreateChannel();

    <snip>

  3. JohnSpence says:

    Hello, and thanks for the excellent blog.  Great information.  I am experimenting with IPv6, p2p, and PNRP myself, and am having some difficulty, which I heop you can help me with, if I may ask.

    I cannot resolve a WICN name – which I think should use peer-to-peer – across the Internet between 2 Vista machines.

    Machine 1 is the resolver.  It has an insecure name:

    C:Windowssystem32>netsh p2p pnrp peer show machine

    Machine Name: 0.johnspencecommand

    Use this format DNS name in other applications to refer to this machine: johnspencecommand.pnrp.net

    The machine name is being published.

    The machine name is configured to be published automatically.

    It appears healthy, IPv6-wise and peer-to-peer-wise:

    C:Windowssystem32>ping -6 pnrpv2.ipv6.microsoft.com

    Pinging pnrpv2.ipv6.microsoft.com [2002:4136:e383::4136:e383] from 2001:0:4137:9e50:10e0:a53c:bc49:7236 with 32 bytes of data:

    Reply from 2002:4136:e383::4136:e383: time=99ms

    Reply from 2002:4136:e383::4136:e383: time=39ms

    Reply from 2002:4136:e383::4136:e383: time=37ms

    Reply from 2002:4136:e383::4136:e383: time=38ms

    Ping statistics for 2002:4136:e383::4136:e383:

       Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

       Minimum = 37ms, Maximum = 99ms, Average = 53ms

    C:Windowssystem32>netsh p2p pnrp cloud show list

    Scope  Id     Addr   State             Name

    —–  —–  —–  —————-  —–

       3      7      0  Alone             LinkLocal_ff00::%7/8

       1      0      1  Active            Global_

       3      8      1  Alone             LinkLocal_ff00::%8/8

    C:Windowssystem32>netsh p2p pnrp diag ping seed Global_

    SOLICIT sent to address: [2002:4136:e383:0000:0000:0000:4136:e383]:3540.

    ADVERTISE returned 5 ID(s) in 31 milliseconds.

           43426ed07784caf6419afa2f3151070e.7700660055004400db83fb20d5b7f063

           ebe5fb41d500284b100b52cd9618b245.770066005500440084df496e190f8050

           9e486c7978a1145b20a2ee92070be60c.27b05c1726601f9741ccc39c9040d919

           dd1f6e0abfc116e5bb0cf701af6d3211.77006600550044000a698795bd09b505

           1f183b562327e9b71f3a7a0d6b522417.4a082a03175c52061d8d901fee15d14a

    Machine 2 is the target.  It has a secure name.

    C:Windowssystem32>netsh p2p pnrp peer show machine

    Machine Name: 54ffc35aa154438b885004fb541e88f64576c8ef.

    Use this format DNS name in other applications to refer to this machine: p.p54ffc35aa154438b8850

    541e88f64576c8ef.pnrp.net

    The machine name is being published.

    The machine name is configured to be published automatically.

    It appears healthy, IPv6-wise and peer-to-peer-wise:

    C:Windowssystem32>ping -6 pnrpv2.ipv6.microsoft.com

    Pinging pnrpv2.ipv6.microsoft.com [2002:4136:e383::4136:e383] from 2002:ccf5:c614::ccf5:c614 with 32 bytes of data:

    Reply from 2002:4136:e383::4136:e383: time=24ms

    Reply from 2002:4136:e383::4136:e383: time=23ms

    Reply from 2002:4136:e383::4136:e383: time=23ms

    Reply from 2002:4136:e383::4136:e383: time=22ms

    Ping statistics for 2002:4136:e383::4136:e383:

       Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

       Minimum = 22ms, Maximum = 24ms, Average = 23ms

    C:Windowssystem32>netsh p2p pnrp cloud show list

    Scope  Id     Addr   State             Name

    —–  —–  —–  —————-  —–

       1      0      1  Active            Global_

       3      9      1  Alone             LinkLocal_ff00::%9/8

    C:Windowssystem32>netsh p2p pnrp diag ping seed Global_

    SOLICIT sent to address: [2002:4136:e383:0000:0000:0000:4136:e383]:3540.

    ADVERTISE returned 5 ID(s) in 16 milliseconds.

           b6d0794c499046c5cadfc01536db002d.77006600550044005b393e190cfdde63

           28ff4dad424be37881574c5b7cafed48.3868793538aeb1a0fb4e7965a50220ad

           935ed522a39e19bc1b986791b3193827.7700660055004400d18a27218748a023

           43b45bbf33a3556fa6a667d8d11fa220.ee05d8cf78b9301148377b37d87bd7b3

           08cfe1ec25d6f7d9906fa11831c176ba.7700660055004400b13ac1b417ca9d59

    But, from Machine1, I cannot resolve the address from the name:

    C:Windowssystem32>ping p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net

    Ping request could not find host p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net. Please check the name and try again.

    C:Windowssystem32>ping -4 p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net

    Ping request could not find host p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net. Please check the name and try again.

    C:Windowssystem32>ping -6 p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net

    Ping request could not find host p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net. Please check the name and try again.

    And I may not know how to use the “diag ping host” command.

    C:Windowssystem32>Netsh p2p pnrp diag ping host p.p54ffc35aa154438b541e88f64576c8ef.pnrp.net Global_

    Error: Host name not found in cache.

    C:Windowssystem32>Netsh p2p pnrp diag ping host 204.245.198.20 Global_

    Error: Host name not found in cache.

    But I can use “diag ping host” and reach the IPv6 address, so that connectivity works.

    C:Windowssystem32>Netsh p2p pnrp diag ping host 2002:ccf5:c614::ccf5:c614 Global_

    SOLICIT sent to address: [2002:ccf5:c614:0000:0000:0000:ccf5:c614]:3540.

    ADVERTISE returned 5 ID(s) in 452 milliseconds.

           2cceee486e2d1b846f7c3a6411f727dc.77006600550044008e2e4080b15f7392

           3605f2f5ec64b905f8fda7a03a8961f6.c3c62c0bce2f436480cd530348235ed2

           4234f486e9d838c110dcb9abb006c84c.34cc78e3b55c052a25f332c0bffebaf2

           63735cc68b9b5164ee13d3a7535d600e.76b3007632cf3e8aad072a01a3d1c6a1

           7ce78401dbf30c927a445fb59cd2d250.7700660055004400583e793cc1bcb258

    Why can I not ping the target by name and resolve the name using PNRP?  Thanks for any insight.

  4. JohnSpence says:

    I’m back.  Another question – more of a confirmation this time.

    I have MachineC.  It is at a global IPv4 address, and has a 2002::/16 IPv6 address – 6to4.

    I have given it a WICN, secured.

    When I resolve the name on MachineD (RFC1918 address, and using Teredo), I believe the PNRP resolution is done over IPv6, because of the "traceroute" output.  Is this process only and always done over IPv6 – never IPv4?

    When the traceroute finishes, I see the resolution has been to the IPv4 address.  Then if I ping the node by WICN I do an IPv4 ping.  Is this just the stack being smart and saying "IPv4 to a global address is better than IPv6 via Teredo?"

    When I open a remote desktop connection from MachineC to MachineD using MachineD’s WICN it also appears to run over IPv4.  Also correct?

    Next, immediately after getting the traceroute working and seeing the resolve, I run the command "netsh p2p pnrp diag host <MachineD-WICN> Global_"  and I get an error, specifically "Error: Host name not found in cache.".  Why is the name not in my cache – I’m using it for ping and Remote Desktop.

    Thanks for any insight.

  5. JohnSpence says:

    Sorry for the confusion. I see I transposed MachineC and MachineD in the last two paragraphs above.  In my question and example, the "client" machine is always MachineD (Teredo), and the target is always MachineC (routable IPv4).  Jeez.

  6. JohnSpence says:

    Hello again.  I’m not sure how I fixed my problems, but I did, and so no need for anyone to reply to the posts above.  If the activity on this thread picks up I will post some debug information that helped me.  Thanks.

Skip to main content