Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi Tony, Yes, they are definitely the same machine. :) ____________________________________ C:\WINDOWS>ping ransom Pinging ransom.eecs.berkeley.edu [128.32.43.208] with 32 bytes of data: Reply from 128.32.43.208: bytes=32 time<1ms TTL=128 ____________________________________ My network staff here tells me that the domain suffix is excluded from all local machines as per their Active Directory configuration. As for the firewall theory, it does not explain why on a domain authenticated laptop on the local network, asking for host.dns.suffix returns ok, as does asking for host (no suffix) (for the latter, I am unsure whether the suffix is appended automatically by my network settings). That is, unless the CVSNT client is smart enough to substitute "localhost" for "hostname" if it is the same. I tested this theory by trying these as hosts while remote desktopped: While remote desktopped to the terminal server: 128.32.43.208 (success) localhost (success) ransom (success) ransom.eecs.berkeley.edu (failure, as before) >From a domain-authenticated laptop on the same wired network: 128.32.43.208 (success) localhost (failure, since there is no CVSNT on the laptop) ransom (success) ransom.eecs.berkeley.edu (success) >From a domain-authenticated laptop on another network (to prevent file sharing and guard against virus attacks, our wireless network is separate from the wired network): 128.32.43.208 (success) localhost (failure, since there is no CVSNT on the laptop) ransom (success) ransom.eecs.berkeley.edu (success) Both laptops are configured (as part of our Active Directory) to append .domain.suffix, so I do not know whether this is done prior to contacting the server or not. Nevertheless, it is just more evidence that the .domain.suffix problem shows up only while logged into the same machine as the CVS server. Please let me know if there are other tests I can run to help in this. For now, I just have a caveat in the remote users configuration documentation. However, I am happy to serve as a beta tester (or remote debugger) for any theories as to why this is happening. :) I am relatively satisfied that it is not a configuration problem on my end (based on the results of the above tests, and use of a decently recent version of TortoiseCVS. Cheers, Jonathan > Jonathan Sprinkle wrote: > > > C:\Program Files\CVSNT>cvs -d :sspi:ransom.eecs.berkeley.edu:/work > > rlog CVSROOT/ cvswrappers cvs [rlog aborted]: unrecognized auth > > response from > > ransom.eecs.berkeley.edu: > > > > C:\Program Files\CVSNT>cvs -d :sspi:ransom:/work rlog > > CVSROOT/cvswrappers > > > Are they definately the same machine? > > The first result shows that the connection isn't being made - > no protocol negotiation is taking place at all. The second > is normal. I'd expect that result if a firewall or proxy was > trying to modify the data. > > Tony >