On Wed, Mar 4, 2009 at 10:24 AM, Loren M. Lang <[email protected]> wrote: > On Wed, 2009-03-04 at 06:33 -0800, Loren M. Lang wrote: >> > >> > > This symlinks point to missing certificates that have nothing to do with >> > > the pki infrastructure I am using, but once I moved the symlinks out of >> > > the way, kinit continued and finally sent out an AS-REQ with the PK-INIT >> > > preauth data, but received no response. According to Wireshark, >> > > following the initial AS-REQ with no preauth, the server responds with a >> > > NEEDED_PREAUTH error listing six preauth types including PA-PK-AS-REQ >> > > and PA-PK-AS-REP. The client then sends a single IP fragment response. >> > > The fragment has a payload of 1480 bytes with flag more fragments, but >> > > no further fragments are sent. I have no firewall rules installed and >> > > am at a loss as to why there are no more fragments. >> > >> > I'm not sure what might be happening here. This would just be a >> > work-around, but is it possible for you to try using TCP rather than >> > UDP? >> >> I enabled TCP support on my KDCs and netstat confirms they are listening >> on them. I tried setting udp_preference_limit to 1480, 1000, and 50, >> but kinit never uses TCP. I put udp_preference_limit both at the very >> beginning and very end of my libdefaults section in krb5.conf and even >> tried using copy/paste to double check that I typed it correctly. > > Never mind, I only had UDP SRV records published, now it's using TCP. > The error I am getting now is KRB5KRB_ERR_GENERIC with e-data: > KDC_RETURN_PADATA. The kdc log shows this relevant error: > > Mar 04 07:04:13 server krb5kdc[18148](info): AS_REQ (7 etypes {18 17 16 > 23 1 3 2}) 192.168.1.237: KDC_RETURN_PADATA: [email protected] for > krbtgt/[email protected], Cannot allocate memory > > There is no memory crunch on the server.
After a quick glance at the code, I don't see where ENOMEM is returned in cases where it wasn't an allocation error. If you have output from -DDEBUG, that might give us a clue of the problem. K.C. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
