[jcifs] java.net.SocketException: Connection reset

Michael B.Allen mba2000 at ioplex.com
Thu Apr 17 03:54:30 EST 2003

On Wed, 16 Apr 2003 12:59:46 +0100
tom berger <tom at lshift.net> wrote:

> Hi,
> I am using jcifs to authenticate web users against a domain controller. 
> This functionality is wrapped in an Apache Tomcat Realm, and is 
> available free at http://www.sourceforge.net/projects/ntdcrealm/
> SmbSession.logon(machine, ntlm_auth) works fine for me when using an NT4 
> domain controller, but when I try to use a windows 2000 server, i get 
> the following exception :
> java.net.SocketException: Connection reset
> 	at java.net.SocketInputStream.read(SocketInputStream.java:168)
> 	at 
> jcifs.netbios.SessionServicePacket.readPacketType(SessionServicePacket.java:68)
> 	at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:73)
> 	at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:39)
> 	at java.io.FilterInputStream.read(FilterInputStream.java:66)
> 	at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
> 	at jcifs.smb.SmbTransport.run(SmbTransport.java:304)
> 	at java.lang.Thread.run(Thread.java:536)
> Any ideas?

Can you try one of the simple examples like List.java aganist thw W2K
server or a W2K server like it just to make sure there isn't a problem
with transport?

Otherwise I'm not familar with this particular problem. A packet trace
with Ethereal or NetMon would be necessary to determine precisely what's
happening. A -Dlog=ALL trace might help a little though.


A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived. 

More information about the jcifs mailing list