The problem isn't with OpenAFS, it is with the Windows 7 netbios name resolution. It breaks when the network adapter link drops which will happen when you suspend the machine.
On 12/21/2010 2:34 PM, Douglas E. Engert wrote: > I have a similar issue today. While testing what happens > if the the power settings are changed to put the machine > to sleep over lunch. > > Using Windows 7 64-bit > OpenAFS-1.5.7200 > NetIDMgr 2.0.0.304 > > After coming back after lunch, the machine was asleep, > and I logged back on. The AFS client lock icon was broken, > the AFS console said the services was running, but I could > not start it, or stop it. AFS access was not working. > > aklog -d showed what you are seeing. (I think it was the > same error.) But we use a principal of afs/[email protected] > > (My mail files are in AFS so I had to restart the system > before writing this e-mail, and I should have written down > more information.) > > The point being, I have had no problems at all with AFS on > W7 64, until I change the power option from never to 30 > minutes for the test. > > Could sleep mode have caused your problem? > > Is there some issue with the cache manager coming out of sleep mode? > > > On 12/20/2010 2:26 PM, Jeff Blaine wrote: >> Windows 7 64-bit (yeah, I know...) >> OpenAFS 1.5.78 64-bit >> KfW 3.2.2 with latest released Secure Endpoints NIM >> >> I can't figure out why >> >> aklog.exe -d -c rcf.our.org -k RCF.OUR.ORG >> Authenticating to cell rcf.our.org. >> Getting v5 tickets: afs/[email protected] >> Getting v5 tickets: [email protected] >> About to resolve name [email protected] to id >> Id 26560 >> Set username to [email protected] >> Getting tokens. >> aklog.exe: ktc 7 (11862791) while obtaining tokens for >> cell rcf.our.org >> >> ...regardless of the final error, ends up generating Kerberos >> packets toward our corporate AD server(s). >> >> C:\Windows\krb5.ini is as follows: >> >>> [libdefaults] >>> default_realm = RCF.OUR.ORG >>> forwardable = yes >>> ticket_lifetime = 7d >>> renew_lifetime = 14d >>> dns_lookup_realm = no >>> dns_lookup_kdc = no >>> >>> [appdefaults] >>> forwardable = yes >>> >>> [domain_realm] >>> .our.org = RCF.OUR.ORG >>> >>> [realms] >>> RCF.MITRE.ORG = { >>> kdc = rcf-kdc1.our.org >>> kdc = rcf-kdc2.our.org >>> kdc = rcf-kdc3.our.org >>> admin_server = rcf-kdc1.our.org >>> master_kdc = rcf-kdc1.our.org >>> } >> >> The aklog.exe Wireshark capture from above shows the following: >> >> DNS 'A' query for rcf-kdc1.our.org >> response >> >> DNS 'A' query for rcf-kdc2.our.org >> response >> >> DNS 'A' query for rcf-kdc3.our.org >> response >> >> TGS_REQ to rcf-kdc1.our.org for afs/rcf.mitre.org >> response: "principal unknown afs/rcf.our.org" as expected, >> because we use [email protected] and it works fine. >> >> DNS 'A' query for rcf-kdc1.our.org >> response >> >> DNS 'A' query for rcf-kdc2.our.org >> response >> >> DNS 'A' query for rcf-kdc3.our.org >> response >> >> TGS_REQ to rcf-kdc1.our.org for afs/rcf.our.org >> response : "principal unknown afs/rcf.our.org" (why again?) >> >> DNS 'A' query for rcf-kdc1.our.org >> response >> >> netbios-ssn packet to 10.254.254.253 (MSLA) >> >> microsoft-ds packet to 10.254.254.253 (MSLA) >> >> query to corporate AD server port 88 (Kerberos) SYN >> >> >> [ ... some more corporate Kerberos junk that is not relevant ] >> [ to what I want to do ] >> >> Does this make any sense? >> >> Note that I do not see anywhere in the packets where a TGS_REQ >> was made for '[email protected]' >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> >> >
signature.asc
Description: OpenPGP digital signature
