>> >	does it have any negative sideeffects?  i mean, is there any code that
>> >	relies on xid being generated from timestamp?
>> 
>> clnt_vc.c:      call_msg.rm_xid = ((u_int32_t)++disrupt) ^ __RPC_GETXID(&now);
>> 
>> 	how important "disrupt" is?
>
>Does it even matter if RPC xids are predictable?
>IIRC They are only used to tie responses to commands in the client.
>So what is really, really important is that there aren't two outstanding
>requests with the same xid - and I'm not even sure the code above does that!

	if possibility of reuse is the issue, the original code (uses
	time.tv_{u,}sec) is busted already.
	i'll need to bring in something like sys/netinet6/ip6_id.c then.

>The only possible use of a predecicted xid is to send an early response
>from an alien system.  Now the xid isn't encrypted, so if you can see the
>outbound packet then you can generate a correct response anyway.
>If you can't see the outbound packet then you will need a lot of luck on
>getting the timing of the response right!

	possible "use"?  possible "security issue", i would say.

itojun