次の方法で共有

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:

https://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

  • Anonymous
    March 19, 2008
    The comment has been removed

  • Anonymous
    March 21, 2008
    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>

  • Anonymous
    April 23, 2008
    The comment has been removed

  • Anonymous
    April 25, 2008
    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.

  • Anonymous
    April 25, 2008
    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.

  • Anonymous
    May 01, 2008
    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.