[cvsnt] Re: Terminal server errors with machine name with/out DNS

Jonathan Sprinkle sprinkle at EECS.Berkeley.Edu
Tue Sep 27 01:34:24 BST 2005


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
> 


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook