|
|
|
date: Tue, 31 Jan 2006 11:08:50 -0800,
group: microsoft.public.platformsdk.networking
back
MSRPC issue with IPv6 link local addresses.
I'm cross posting this from microsoft.public.win32.programmer.networks as
suggested.
-Scott
---------------------------------------------------------------------------------------
I believe that the Windows RPC layer has a bug in it regarding Link Local
IPv6 addresses. I have found the if I take the following steps, I don't
reliably get a good RPC binding handle. If I retry the operation, it almost
always succeeds.
1.) Create an IPv6 address string in the form fe80::xxxx:xxxx:xxxx:xxxx%n
where n is the scope_id associated with the IPv6 address.
2.) Call RpcStringBindingCompose using the string above.
3.) Call RpcBindingFromStringBinding to create a binding handle.
4.) Use the binding handle in an RPC call.
Sometimes the RPC call in step 4 fails. If I close the binding handle and
start again, the RPC call will succeed. I am a bit uncomfortable using this
scheme in production. I SHOULDN'T HAVE TO RETRY!
I found another problem as well. On the RPC server side, if I inspect the
client binding handle, I find that the string binding doesn't have a scope
id associated with it. Here is how to reproduce this behavior.
1.) On the RPC client side, construct a client side binding handle as
described above. Repeat the process until the RPC call successfully makes
it to the server.
2.) On the RPC server side, call RpcBindingServerFromClient to get a
partially bound server side binding handle.
3.) On the RPC server side, call RpcBindingToStringBinding using the binding
handle obtained in step 2.
4.) On the RPC server side, call RpcStringBindingParse to fetch the client's
IP address. If the client is using IPv6 Link Local addresses only, you'll
find that there is no scope id associated with the client's network address.
Comments would be most welcome.
-Scott
"Scott St.Clair" <Scott@nospam.nospam> wrote in message
news:%236fmTl2IGHA.3176@TK2MSFTNGP12.phx.gbl...
> I'm working on an existing application that makes heavy use of MS RPC.
> When I create a client binding handle I first call RpcStringBindingCompose
> with a string for the IP address. I'm using the "ncacn_ip_tcp" protocol.
> I then pass the string generated by RpcStringBindingCompose to
> RpcBindingFromStringBinding to get my binding handle.
>
> Generally, this scheme works except when I try to use an IPv6 Link Local
> Address. When I pass a link local address to RpcStringBindingCompose, I
> tack "%n" onto the end of the IPv6 address to specify the scope_id for the
> address. This leaves me with a string in the form
> fe80::xxxx:xxxx:xxxx:xxxx%4. This usually works but sometimes, it
> doesn't. Occasionally, when I try to use the binding handle the RPC
> runtime throws 1722 (RPC_S_SERVER_UNAVAILABLE). I know that my server is
> still running. Heck, it even responds to other RPC calls.
>
> As an aside, I usually end up trying to connect to every active scope. By
> this I mean that I call GetAdapterAddresses to get a list of adapters
> running IPv6 and save off the Ipv6IfIndex. I then use my list of
> Ipv6IfIndex's to keep trying to connect until one succeedes.
>
> Am I doing something wrong?
>
> -Scott
>
>
>
date: Tue, 31 Jan 2006 11:08:50 -0800
author: Scott St.Clair am
Re: MSRPC issue with IPv6 link local addresses.
Why not
microsoft.public.platformsdk.networking.ipv6 ?
Arkady
"Scott St.Clair" <Scott@nospam.nospam> wrote in message
news:uUgRGnpJGHA.1032@TK2MSFTNGP10.phx.gbl...
> I'm cross posting this from microsoft.public.win32.programmer.networks as
> suggested.
>
> -Scott
>
> ---------------------------------------------------------------------------------------
>
> I believe that the Windows RPC layer has a bug in it regarding Link Local
> IPv6 addresses. I have found the if I take the following steps, I don't
> reliably get a good RPC binding handle. If I retry the operation, it
> almost
> always succeeds.
>
> 1.) Create an IPv6 address string in the form fe80::xxxx:xxxx:xxxx:xxxx%n
> where n is the scope_id associated with the IPv6 address.
> 2.) Call RpcStringBindingCompose using the string above.
> 3.) Call RpcBindingFromStringBinding to create a binding handle.
> 4.) Use the binding handle in an RPC call.
>
> Sometimes the RPC call in step 4 fails. If I close the binding handle and
> start again, the RPC call will succeed. I am a bit uncomfortable using
> this
> scheme in production. I SHOULDN'T HAVE TO RETRY!
>
> I found another problem as well. On the RPC server side, if I inspect the
> client binding handle, I find that the string binding doesn't have a scope
> id associated with it. Here is how to reproduce this behavior.
>
> 1.) On the RPC client side, construct a client side binding handle as
> described above. Repeat the process until the RPC call successfully makes
> it to the server.
> 2.) On the RPC server side, call RpcBindingServerFromClient to get a
> partially bound server side binding handle.
> 3.) On the RPC server side, call RpcBindingToStringBinding using the
> binding
> handle obtained in step 2.
> 4.) On the RPC server side, call RpcStringBindingParse to fetch the
> client's
> IP address. If the client is using IPv6 Link Local addresses only, you'll
> find that there is no scope id associated with the client's network
> address.
>
> Comments would be most welcome.
>
> -Scott
>
> "Scott St.Clair" <Scott@nospam.nospam> wrote in message
> news:%236fmTl2IGHA.3176@TK2MSFTNGP12.phx.gbl...
>> I'm working on an existing application that makes heavy use of MS RPC.
>> When I create a client binding handle I first call
>> RpcStringBindingCompose
>> with a string for the IP address. I'm using the "ncacn_ip_tcp" protocol.
>> I then pass the string generated by RpcStringBindingCompose to
>> RpcBindingFromStringBinding to get my binding handle.
>>
>> Generally, this scheme works except when I try to use an IPv6 Link Local
>> Address. When I pass a link local address to RpcStringBindingCompose, I
>> tack "%n" onto the end of the IPv6 address to specify the scope_id for
>> the
>> address. This leaves me with a string in the form
>> fe80::xxxx:xxxx:xxxx:xxxx%4. This usually works but sometimes, it
>> doesn't. Occasionally, when I try to use the binding handle the RPC
>> runtime throws 1722 (RPC_S_SERVER_UNAVAILABLE). I know that my server is
>> still running. Heck, it even responds to other RPC calls.
>>
>> As an aside, I usually end up trying to connect to every active scope.
>> By
>> this I mean that I call GetAdapterAddresses to get a list of adapters
>> running IPv6 and save off the Ipv6IfIndex. I then use my list of
>> Ipv6IfIndex's to keep trying to connect until one succeedes.
>>
>> Am I doing something wrong?
>>
>> -Scott
>>
>>
>>
>
>
>
date: Wed, 1 Feb 2006 16:44:46 +0200
author: Arkady Frenkel
|
|