On Tue, Sep 16, 2003 at 10:38:42AM +0900, Jun-ichiro itojun Hagino wrote:
> > Getting back to the original problem I was talking about:
> > 
> > On Sat, Sep 13, 2003 at 05:04:01PM +1000, Simon Burge wrote:
> > 
> > > id 52018  last call for id at    465455, current call    465456 (diff     1)
> > > id 61704  last call for id at   3483418, current call   3483419 (diff     1)
> > 
> > Do we have any protocol problems when using this generator in its
> > current form?  One case I'm specifically wondering about is in
> > libc/net/res_mkquery.c.
> > 
> >   dns client sends request #1 with id N for host www.foo.com
> >   dns client sends request #2 with same id N for host www.bar.com
> >   server replies to request #2 with result 1.2.3.4
> >   server replies to request #1 with result 5.6.7.8
> > 
> > Is there anything in the dns client code that would detect that the
> > replies were sent in reverse order, or will the application assume that
> > because the ID matches that everything is ok?
> > 
> > Maybe we should #ifdef out the use of the current generator until this
> > problem is addressed?
> 
> 	with which revision did you perform the test?

My last test was performed against rev 1.7 of randomid.c (still up to
date as of now), and the problem still exists.

>	if possible put the
> 	test code to src/regress?

What should the regression test do?  Fail if detects a matched ID in
less then 30000 calls?  The current code just runs forever, so as is
it's not suitable for a regression test :-)

>	btw, by calling randomid() too frequently
> 	didn't you put arc4random() into entropy starvation?

Note that the problem happens _inbetween_ reseeding events.  The MSB
toggling during reseeding prevents this problem occuring across reseed
events.

I have tried running the test program while a "du /" was running and
checking with "rndctl -s" that there was always entropy available.
There was no change in behaviour.

> 	if dns clients are different process, they would use the different UDP
> 	source port for #1 and #2, so there's no problem.
> 	otherwise, res_send() checks if the question section of query matches
> 	the reply, so there's no big confusion (id check happens beforehand,
> 	so that could affect the end result).

This is good to know.  However, I'm still sceptical that there may be
other problems with the generator in it's current form.  Is this also
safe with the generators usage in RPC xid's and TCP ids?

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/