On Fri, Jun 10, 2005 at 08:17:03AM -0600, Patrick Walsh wrote:
> 	I'm going to upgrade to this today.  I came in this morning and found
> two computers with hung coda clients.  This is the first time in a while
> this has happened.  Both of the clients had these log messages (sorry I
> can't give a backtrace -- these machines were don't have gdb):
> 
> [ W(30) : 0000 : 09:00:00 ] userent::Connect: Authenticated bind
> failure, uid = 0
> [ W(20) : 0000 : 09:00:00 ] userent::Connect: Authenticated bind
> failure, uid = 0

These should happen when the server rejects the token that was given
by the client. i.e. this should only happen when we try to use an
expired token.

> 09:00:00 Coda token for user 0 has been discarded
> Assertion failed: p->ai_family == PF_INET, file
> "/home/pwalsh/working/coda/BUILD/coda-6.0.10/coda-src/venus/realm.cc",
> line 182

This is interesting, it tells me that the resolver returned some
non-IPv4 address, venus and codasrv are internally still using 4 byte
ints to store ip addresses, and pass them back and forth, f.i. in the
result of the getvolinfo rpc2 call and as such can't yet handle the 16
byte IPv6 addresses.

But I thought we explictly request the resolver to only return IPv4
addresses. It is perfectly safe to change that assert into a continue
and skip any non-v4 results from getaddrinfo, but that doesn't explain
the fact that we somehow got a non-PF_INET response.

Jan