Nabble - Samba - jcifs

Ntlm challenge fails with connection reset on WebSphere6.1

2009-11-24T21:32:27Z

Issue:

I have successfully gotten the 3-step NTLM challenge/response working using nothing but the JCIFS NtlmHttpFilter deployed to WebSphere 6.1 if I use Firefox as the browser. Similarly, the same filter & servlet work when deployed on Tomcat 6.x from either Firefox or IE. But when I try IE6 against WebSphere 6.1, IE sends request #1 and request #2 but WebSphere appears to close the connection after the response to request #2 is sent. I can step through it in a debugger and see that request #1 and #2 are both sent and processed without any kind of error, but after request #2 leaves the filter, the next thing you know, IE is saying "This page can not be displayed".

Everything I've been able to "sniff" shows that the app server is closing the connect after the 2nd request.

Has anyone been able to get NTLM working with IE6/WebSphere 6.1 using nothing but the JCIFS HtlmHttpFilter?

Solution:

Just to give an update - I upgraded to the latest fix pack of WAS 6.1 (6.1.0.27) and everything is now working.

So for anyone trying to do NTLM-based SSO using nothing but the JCIFS filter, you're going to want to get the latest fix pack of WAS before you try it.

2009-11-25

--
Asran Deng
APJ Software Technology Co. Ltd.
Tel: (+86) 756 - 3392032/3392038
Fax: (+86)756 - 3392161
Web: www.apjsoft.com

[Asran Deng.vcf]

BEGIN:VCARD VERSION:2.1 N:Asran Deng; FN:Asran Deng NOTE;ENCODING=QUOTED-PRINTABLE:-- Asran Deng APJ Software Technology Co. Ltd. Tel: (+86) 756 - 3392032/3392038 Fax: (+86)756 - 3392161 Web: www.apjsoft.com EMAIL;PREF;INTERNET:asran@... REV:20091125T133213Z END:VCARD

Re: Calling NetServerEnum2 with no domain parameter

2009-11-21T00:58:21Z

Hi

I am brand new to jcifs too. For what it is worth - I was also having problems with getting listing from smb://. I just applied Chris's suggested patch - and works fine now.

Thanks
Andrew

Re: Version of JCIFS?

2009-11-20T14:49:24Z

Melinda,

Again, it sounds like you are simply not using fully qualified DNS
hostnames. No one should be using short NetBIOS names really anymore.
The VPN issue could also be related to this but it would be impossible
to make any judgement about a VPN problem as there are a large variety
of VPNs all of which are usually fairly mysterious things.

Mike

On Fri, Nov 20, 2009 at 4:05 PM, Savoy, Melinda
<MelindaSavoy@...> wrote:

> Michael,
>
> I've been working again with one of our server engineers and she enabled this setting on the server: "enable netbios over tcpip". Once she did that I was able to get in without issue and without making changes to JCIFS within our app. What is weird is that I cannot get in over a wireless connection using VPN but I can get in over a wired connection using VPN.
>
> Any insight here? Thanks.
>
> -----Original Message-----
> From: Michael B Allen [mailto:ioplex@...]
> Sent: Friday, November 20, 2009 10:39 AM
> To: Savoy, Melinda
> Cc: jcifs@...
> Subject: Re: [jcifs] Version of JCIFS?
>
> Hi Melinda,
>
> Old versions of JCIFS are available under the 'old' subdirectory like:
>
> http://jcifs.samba.org/old/jcifs-<version>.zip
>
> See also:
>
> http://jcifs.samba.org/src/docs/resolver.html
>
> My guess is that you're trying to use short netbios names but WINS is
> gone. Always use fully qualified DNS hostnames in your SMB URLs like
> smb://server.domain.com/ and not NetBIOS short names like
> smb://server/.
>
> Mike
>
> PS: Responses not sent to the mailing list will be ignored.
>
> On Fri, Nov 20, 2009 at 9:46 AM, Melinda <melindasavoy@...> wrote:
>> Melinda <melindasavoy <at> texashealth.org> writes:
>>
>>>
>>> I just inherited a java application that has a JCIFS jar file
>>> but I cannot see where I can find what version of JCIFS.
>>> Can someone help me determine what that is?
>>> We're having problems where there have
>>> been changes done to the network
>>> environment and now we cannot resolve DNS
>>> names but have no problem resolving
>>> IP addresses now. Any help
>>> would be GREATLY appreciated.
>>>
>>> Regards.
>>>
>> We are on version 1.3.6.
>> Cannot resolve DNS names.
>> Can resolve IP addresses.
>> Any help is appreciated.
>>
>>
>>
>>
>
>
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
>
> The information contained in this message and any attachments is intended only for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law. If you are not the intended recipient, you are prohibited from copying, distributing, or using the information. Please contact the sender immediately by return e-mail and delete the original message from your system.
>

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Re: Version of JCIFS?

2009-11-20T13:05:35Z

Michael,

I've been working again with one of our server engineers and she enabled this setting on the server: "enable netbios over tcpip". Once she did that I was able to get in without issue and without making changes to JCIFS within our app. What is weird is that I cannot get in over a wireless connection using VPN but I can get in over a wired connection using VPN.

Any insight here? Thanks.

-----Original Message-----
From: Michael B Allen [mailto:ioplex@...]
Sent: Friday, November 20, 2009 10:39 AM
To: Savoy, Melinda
Cc: jcifs@...
Subject: Re: [jcifs] Version of JCIFS?

Hi Melinda,

Old versions of JCIFS are available under the 'old' subdirectory like:

http://jcifs.samba.org/old/jcifs-<version>.zip

See also:

http://jcifs.samba.org/src/docs/resolver.html

My guess is that you're trying to use short netbios names but WINS is
gone. Always use fully qualified DNS hostnames in your SMB URLs like
smb://server.domain.com/ and not NetBIOS short names like
smb://server/.

Mike

PS: Responses not sent to the mailing list will be ignored.

On Fri, Nov 20, 2009 at 9:46 AM, Melinda <melindasavoy@...> wrote:

> Melinda <melindasavoy <at> texashealth.org> writes:
>
>>
>> I just inherited a java application that has a JCIFS jar file
>> but I cannot see where I can find what version of JCIFS.
>> Can someone help me determine what that is?
>> We're having problems where there have
>> been changes done to the network
>> environment and now we cannot resolve DNS
>> names but have no problem resolving
>> IP addresses now. Any help
>> would be GREATLY appreciated.
>>
>> Regards.
>>
> We are on version 1.3.6.
> Cannot resolve DNS names.
> Can resolve IP addresses.
> Any help is appreciated.
>
>
>
>

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

The information contained in this message and any attachments is intended only for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law. If you are not the intended recipient, you are prohibited from copying, distributing, or using the information. Please contact the sender immediately by return e-mail and delete the original message from your system.

Re: Version of JCIFS?

2009-11-20T08:39:18Z

Hi Melinda,

Old versions of JCIFS are available under the 'old' subdirectory like:

http://jcifs.samba.org/old/jcifs-<version>.zip

See also:

http://jcifs.samba.org/src/docs/resolver.html

My guess is that you're trying to use short netbios names but WINS is
gone. Always use fully qualified DNS hostnames in your SMB URLs like
smb://server.domain.com/ and not NetBIOS short names like
smb://server/.

Mike

PS: Responses not sent to the mailing list will be ignored.

On Fri, Nov 20, 2009 at 9:46 AM, Melinda <melindasavoy@...> wrote:

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Re: Version of JCIFS?

2009-11-20T08:12:54Z

André Warnier <aw <at> ice-sa.com> writes:

>
> Melinda wrote:
> > Melinda <melindasavoy <at> texashealth.org> writes:
> >
> >> I just inherited a java application that has a JCIFS jar file
> ...
> >> We're having problems where there have
> >> been changes done to the network
> >> environment and now we cannot resolve DNS
> >> names but have no problem resolving
> >> IP addresses now.
> ...
> Maybe the first part to establish, is whether you are having problems
> resolving names in general, or just with jCIFS.
> (IP addresses don't need to be resolved, they already are).
> can you give an example of a "name" that you cannot resolve ?
> And how does this manifest itself ?
> Also, under what platform are you ?
> And, supposing "this.name.com" is a "name" (replace by a real one),
> - if you enter, in a command window, the command
> ping this.name.com
> what does it say ?
> - if you enter
> nslookup this.name.com
> what does it say ?
>
>

Thanks for the reply. Sorry don't understand much about networking.
When I ping "resolve.epic.ldap" which is the DNS
I was given I get back in the command promp
the following:
C:\>ping resolve.epic.ldap
Pinging epic.ldap [10.202.10.19] with 32 bytes of data:

Reply from 10.202.10.19: bytes=32 time=201ms TTL=122
Reply from 10.202.10.19: bytes=32 time=42ms TTL=122
Reply from 10.202.10.19: bytes=32 time=41ms TTL=122
Reply from 10.202.10.19: bytes=32 time=42ms TTL=122

Ping statistics for 10.202.10.19:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 41ms, Maximum = 201ms, Average = 81ms
I'm on a Windows XP box.
I'm running over VPN and when I do an nslookup it gives
back my network name.
Hope this info help.

Re: Version of JCIFS?

2009-11-20T07:42:46Z

Melinda wrote:
> Melinda <melindasavoy <at> texashealth.org> writes:
>
>> I just inherited a java application that has a JCIFS jar file
...
>> We're having problems where there have
>> been changes done to the network
>> environment and now we cannot resolve DNS
>> names but have no problem resolving
>> IP addresses now.
...
Maybe the first part to establish, is whether you are having problems
resolving names in general, or just with jCIFS.
(IP addresses don't need to be resolved, they already are).
can you give an example of a "name" that you cannot resolve ?
And how does this manifest itself ?
Also, under what platform are you ?
And, supposing "this.name.com" is a "name" (replace by a real one),
- if you enter, in a command window, the command
ping this.name.com
what does it say ?
- if you enter
nslookup this.name.com
what does it say ?

Can't resolve DNS name

2009-11-20T07:41:16Z

We're having problems where there have
been changes done to the network environment
and now we cannot resolved DNS names but
have no problem resolving IP addresses
which is what we're using right now.
Any help on this front as well would be appreciated.
We're on version 1.3.6. Thank you.

Re: Version of JCIFS?

2009-11-20T06:46:41Z

Melinda <melindasavoy <at> texashealth.org> writes:

>
> I just inherited a java application that has a JCIFS jar file
> but I cannot see where I can find what version of JCIFS.
> Can someone help me determine what that is?
> We're having problems where there have
> been changes done to the network
> environment and now we cannot resolve DNS
> names but have no problem resolving
> IP addresses now. Any help
> would be GREATLY appreciated.
>
> Regards.
>

We are on version 1.3.6.
Cannot resolve DNS names.
Can resolve IP addresses.
Any help is appreciated.

Version of JCIFS?

2009-11-20T06:06:44Z

I just inherited a java application that has a JCIFS jar file but I cannot see
where I can find what version of JCIFS this is when I decompiled the jar. Can
someone help me determine what that is? We're having problems where there have
been changes done to the network environment and now we cannot resolved DNS
names but have no problem resolving IP addresses which is what we're using right
now. Any help on this front as well would be GREATLY appreciated.

Regards.

Re: lookupnames/setsecdesc in jcifs

2009-11-13T15:30:35Z

On Fri, Nov 13, 2009 at 10:42 AM, Volker Lendecke
<Volker.Lendecke@...> wrote:
> On Fri, Nov 13, 2009 at 04:06:59PM +0100, Volker Lendecke wrote:
>> As a little task I would like to implement
>> SetSecurityDescriptor in jcifs. That call itself seems
>> pretty simple to do, the more difficult question is to get
>> the LsaLookupNames right.
>>
>> Question: How did you generate lsarpc.java from lsarpc.idl?
>
> Ignore me, found midlc.

Hi Volker,

Yeah, I just run midlc manually whenever a stub changes or if I add an RPC.

Regarding LsarLookupNames, I think the IDL from the new MS docs should
work as long as you adjust the type names to match the rest of the idl
and remove all the excessive typedeffing. Midlc syntax and behavior is
identical to midl for the subset of functionality that it implements.
Although midlc does implement *one* extension - the "op" attribute.

So I think LsarLookupNames would be something like this:

[op(0x0e)]
int LsarLookupNames([in] policy_handle *policy_handle,
[in] uint32_t count,
[in,size_is(count)] unicode_string *names,
[out,unique] LsarRefDomainList *referenced_domains,
[in,out] LsarTransSidArray *translated_sids,
[in] uint32_t lookup_level,
[in,out] uint32_t *mapped_count);

Note that all of the referenced types are already in lsarpc.idl so
this should be all you need to update in the idl.

For a good example of how to fire an RPC in JCIFS, look at
jcifs/smb/SID.getServerSid(). That's a nice little self-contained
call. Also you'll want to create an Msrpc* class that maps caller
friendly parameters and sets up the RPC properly. See
jcifs/dcerpc/msrpc/MsrpcLookupSids.java for an example that will
probably be like what you'll need.

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Re: lookupnames/setsecdesc in jcifs

2009-11-13T07:42:34Z

On Fri, Nov 13, 2009 at 04:06:59PM +0100, Volker Lendecke wrote:
> As a little task I would like to implement
> SetSecurityDescriptor in jcifs. That call itself seems
> pretty simple to do, the more difficult question is to get
> the LsaLookupNames right.
>
> Question: How did you generate lsarpc.java from lsarpc.idl?

Ignore me, found midlc.

Sorry for the noise,

Volker

signature.asc (204 bytes) Download Attachment

lookupnames/setsecdesc in jcifs

2009-11-13T07:06:59Z

Hi!

As a little task I would like to implement
SetSecurityDescriptor in jcifs. That call itself seems
pretty simple to do, the more difficult question is to get
the LsaLookupNames right.

Question: How did you generate lsarpc.java from lsarpc.idl?

Volker

signature.asc (204 bytes) Download Attachment

Re: Calling NetServerEnum2 with no domain parameter

2009-11-13T01:31:37Z

Hi Mike,

Thanks for the quick response. I've attached a patch which corrects the problem I was seeing. Essentially, if we are making a NetServerEnum2 request and the domain is absent (null or zero length) the alternate parameter descriptor is used.

Thanks,
Chris

-----Original Message-----
From: Michael B Allen [mailto:ioplex@...]
Sent: 12 November 2009 17:33
To: Chris Bearchell
Cc: jcifs@...
Subject: Re: [jcifs] Calling NetServerEnum2 with no domain parameter

On Thu, Nov 12, 2009 at 8:26 AM, Chris Bearchell
<chris-bearchell@...> wrote:

> Hi,
>
> I have an application, running on a phone, from which I would like to enumerate
> available domains/workgroups. I've been trying the following:
>
> SmbFile root = new SmbFile("smb://", NtlmPasswordAuthentication.ANONYMOUS);
> SmbFile[] domains = root.listFiles();
>
> The problem I was seeing was that the server responds with error 2320 (The
> computer is not active in this domain). Digging deeper with Wireshark I noticed
> that when calling the Windows API NetServerEnum() I see the following
> NetServerEnum2 request:
>
> Microsoft Windows Lanman Remote API Protocol
> Function Code: NetServerEnum2 (104)
> Parameter Descriptor: WrLehDO
> Return Descriptor: B16BBDz
> Detail Level: 1
> Receive Buffer Length: 4200
> Server Type: 0x80000000
> Enumeration Domain (Null pointer)
>
> However, from the phone I see the following request
>
> Microsoft Windows Lanman Remote API Protocol
> Function Code: NetServerEnum2 (104)
> Parameter Descriptor: WrLehDz
> Return Descriptor: B16BBDz
> Detail Level: 1
> Receive Buffer Length: 16384
> Server Type: 0x80000000
> Enumeration Domain (Null pointer)
>
> The obvious difference was the parameter descriptor, which put me on to the
> following from the Microsoft Open Specifications Developer Center:
>
> http://msdn.microsoft.com/en-us/library/cc240217%28PROT.10%29.aspx
> 'ParamDesc (variable): MUST be set to "WrLehDO" if the Domain parameter is not
> specified, or set to "WrLehDz".'
>
>
> Looking at NetServerEnum2.java, "WrLehDz" is always specified for a
> NetServerEnum2 request regardless of the domain parameter. I would like to
> contribute a fix for this issue. I am new to jCIFS and this list and am not sure
> on how I can proceed. Could someone on the list advise?

Hi Chris,

Nice diagnosis and very complete. That certainly sounds like a bug.

However, one problem is that I don't think I have a very good NetBIOS
setup anymore so if you can test the fix and post a patch or just
explain what you did to get it to work I will apply it anyway provided
that it does not obviously break anything at my end.

Otherwise I have also added it to the TODO for further investigation.

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

-----------------------------------------------------------------------------------
Software Imaging: At the Forefront of Innovation in Printing and Imaging Software.
Providing Solutions for the Printer Industry and Mobile Phone Market.

Software Imaging Limited is a limited company registered in England and Wales.
Registered Office: 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN, UK.
Registered No: 01755090

This message is strictly private and contains confidential information intended
only for the use of the person named above. If you have received this e-mail in
error and are not the intended recipient you must not disclose, copy or distribute
it to anyone else. Please immediately advise the sender and delete this email and
all attachments.

-----------------------------------------------------------------------------------

NetServerEnum2.patch (2K) Download Attachment

Re: Calling NetServerEnum2 with no domain parameter

2009-11-12T09:32:39Z

On Thu, Nov 12, 2009 at 8:26 AM, Chris Bearchell
<chris-bearchell@...> wrote:

Calling NetServerEnum2 with no domain parameter

2009-11-12T05:26:25Z

Hi,

I have an application, running on a phone, from which I would like to enumerate
available domains/workgroups. I've been trying the following:

SmbFile root = new SmbFile("smb://", NtlmPasswordAuthentication.ANONYMOUS);
SmbFile[] domains = root.listFiles();

The problem I was seeing was that the server responds with error 2320 (The
computer is not active in this domain). Digging deeper with Wireshark I noticed
that when calling the Windows API NetServerEnum() I see the following
NetServerEnum2 request:

Microsoft Windows Lanman Remote API Protocol
Function Code: NetServerEnum2 (104)
Parameter Descriptor: WrLehDO
Return Descriptor: B16BBDz
Detail Level: 1
Receive Buffer Length: 4200
Server Type: 0x80000000
Enumeration Domain (Null pointer)

However, from the phone I see the following request

Microsoft Windows Lanman Remote API Protocol
Function Code: NetServerEnum2 (104)
Parameter Descriptor: WrLehDz
Return Descriptor: B16BBDz
Detail Level: 1
Receive Buffer Length: 16384
Server Type: 0x80000000
Enumeration Domain (Null pointer)

The obvious difference was the parameter descriptor, which put me on to the
following from the Microsoft Open Specifications Developer Center:

http://msdn.microsoft.com/en-us/library/cc240217%28PROT.10%29.aspx
'ParamDesc (variable): MUST be set to "WrLehDO" if the Domain parameter is not
specified, or set to "WrLehDz".'

Looking at NetServerEnum2.java, "WrLehDz" is always specified for a
NetServerEnum2 request regardless of the domain parameter. I would like to
contribute a fix for this issue. I am new to jCIFS and this list and am not sure
on how I can proceed. Could someone on the list advise?

Thanks,
Chris

Re: Patch to add setting access time -- used by snaplock-like file-systems

2009-11-10T09:21:35Z

Hi Andy,

Thanks. I put it in the patches directory.

Mike

On Mon, Nov 9, 2009 at 7:12 PM, Andy Thomson <a10008051@...> wrote:

> Mike,
>
> Attached is zip file with two diff's, one for SmbFile, and the other for
> Trans2SetFileInformation. These are minor changes that expose the
> lower level access time setting.
>
> This is useful for people wanting to set retention on file systems that
> support the snaplock-like interface. Instead of using external or
> command line tools, they can do everything from Jcifs.
>
> An example of it's use:
>
> // set the retention time in milliseconds, this
> // is a future date for when the retention will expire
> smbfile.setAccessTime( retention );
>
> // set the file to read-only
> smbfile.setReadOnly();
>
> The patch is against the jcifs 1.3.12 source tree.
>
> Andy
>

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Patch to add setting access time -- used by snaplock-like file-systems

2009-11-09T16:12:46Z

Mike,

Attached is zip file with two diff's, one for SmbFile, and the other for
Trans2SetFileInformation. These are minor changes that expose the
lower level access time setting.

This is useful for people wanting to set retention on file systems that
support the snaplock-like interface. Instead of using external or
command line tools, they can do everything from Jcifs.

An example of it's use:

// set the retention time in milliseconds, this
// is a future date for when the retention will expire
smbfile.setAccessTime( retention );

// set the file to read-only
smbfile.setReadOnly();

The patch is against the jcifs 1.3.12 source tree.

Andy

setaccesstime.zip (2K) Download Attachment

Re: Transport timeout during transfer of large files

2009-11-09T08:07:59Z

On Mon, Nov 9, 2009 at 4:30 AM, Thomas Fromm <tf@...> wrote:

> Used jcifs version: 1.3.10
>
> Hi,
>
> I receive an error when transfering files with size of ~50MB:
>
> jcifs.smb.SmbException: Transport1 timedout waiting for response to
> SmbComWriteAndX[command=SMB_COM_WRITE_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC803,signSeq=0,tid=2055,pid=1230,uid=4099,mid=18048,wordCount=14,byteCount=2049,andxCommand=0xFF,andxOffset=0,fid=16384,offset=17602560,writeMode=0,remaining=0,dataLength=2048,dataOffset=64]
> jcifs.util.transport.TransportException: Transport1 timedout waiting for
> response to
> SmbComWriteAndX[command=SMB_COM_WRITE_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC803,signSeq=0,tid=2055,pid=1230,uid=4099,mid=18048,wordCount=14,byteCount=2049,andxCommand=0xFF,andxOffset=0,fid=16384,offset=17602560,writeMode=0,remaining=0,dataLength=2048,dataOffset=64]
> at jcifs.util.transport.Transport.sendrecv(Transport.java:76)
> at jcifs.smb.SmbTransport.send(SmbTransport.java:631)
> at jcifs.smb.SmbSession.send(SmbSession.java:224)
> at jcifs.smb.SmbTree.send(SmbTree.java:111)
> at jcifs.smb.SmbFile.send(SmbFile.java:770)
> at jcifs.smb.SmbFileOutputStream.writeDirect(SmbFileOutputStream.java:245)
> at jcifs.smb.SmbFileOutputStream.write(SmbFileOutputStream.java:216)
> ...
>
> This error does not appear always.
>
> What are the circuumstances to get this error and how to resolv it?
> Just increase timeout values?

Hi Thomas,

If we are to believe the error message it seems the server simply did
not respond within the jcifs.smb.client.responseTimeout which by
default is 30000 milliseconds. Try 120000 (2 minutes).

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

Transport timeout during transfer of large files

2009-11-09T01:30:05Z

Used jcifs version: 1.3.10

Hi,

I receive an error when transfering files with size of ~50MB:

jcifs.smb.SmbException: Transport1 timedout waiting for response to
SmbComWriteAndX[command=SMB_COM_WRITE_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC803,signSeq=0,tid=2055,pid=1230,uid=4099,mid=18048,wordCount=14,byteCount=2049,andxCommand=0xFF,andxOffset=0,fid=16384,offset=17602560,writeMode=0,remaining=0,dataLength=2048,dataOffset=64]
jcifs.util.transport.TransportException: Transport1 timedout waiting for
response to
SmbComWriteAndX[command=SMB_COM_WRITE_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC803,signSeq=0,tid=2055,pid=1230,uid=4099,mid=18048,wordCount=14,byteCount=2049,andxCommand=0xFF,andxOffset=0,fid=16384,offset=17602560,writeMode=0,remaining=0,dataLength=2048,dataOffset=64]
at jcifs.util.transport.Transport.sendrecv(Transport.java:76)
at jcifs.smb.SmbTransport.send(SmbTransport.java:631)
at jcifs.smb.SmbSession.send(SmbSession.java:224)
at jcifs.smb.SmbTree.send(SmbTree.java:111)
at jcifs.smb.SmbFile.send(SmbFile.java:770)
at jcifs.smb.SmbFileOutputStream.writeDirect(SmbFileOutputStream.java:245)
at jcifs.smb.SmbFileOutputStream.write(SmbFileOutputStream.java:216)
...

This error does not appear always.

What are the circuumstances to get this error and how to resolv it?
Just increase timeout values?

Thanks in advance,
tf

Re: NTLM not working on Tomcat 6.0 with IE 7

2009-11-06T07:04:51Z

I am using jcifs-1.2.25a version.

On Fri, Nov 6, 2009 at 5:55 PM, subhash hake <subhash.hake@...> wrote:

Hi,
I am testing ntlm authentication on tomcat 6.0 with IE 7 .it is not working on some machine .
I can get in from Firefox, but still cannot get in from IE 7. After messing around a little, I got this error (we saw this before)Anybody knows about this?

jcifs.smb.SmbException:

java.lang.ArrayIndexOutOfBoundsException

                at java.lang.System.arraycopy(Native Method)

                at jcifs.smb.SigningDigest.<init>(SigningDigest.java:40)

                at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:281)

                at jcifs.smb.SmbSession.send(SmbSession.java:233)

                at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)

                at jcifs.smb.SmbSession.logon(SmbSession.java:169)

                at jcifs.smb.SmbSession.logon(SmbSession.java:162)

                at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:191)

                at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:119)

                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)

                at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)

                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

                at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)

                at java.lang.Thread.run(Thread.java:619)

                at jcifs.smb.SigningDigest.<init>(SigningDigest.java:57)

                at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:281)

                at jcifs.smb.SmbSession.send(SmbSession.java:233)

                at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)

                at jcifs.smb.SmbSession.logon(SmbSession.java:169)

                at jcifs.smb.SmbSession.logon(SmbSession.java:162)

                at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:191)

                at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:119)

                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)

                at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)

                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

                at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)

                at java.lang.Thread.run(Thread.java:619)

Regards
Subhash

NTLM not working on Tomcat 6.0 with IE 7

2009-11-06T04:25:19Z

Hi,
I am testing ntlm authentication on tomcat 6.0 with IE 7 .it is not working on some machine .

I can get in from Firefox, but still cannot get in from IE 7. After messing around a little, I got this error (we saw this before)Anybody knows about this?

jcifs.smb.SmbException:

java.lang.ArrayIndexOutOfBoundsException

at java.lang.System.arraycopy(Native Method)

at jcifs.smb.SigningDigest.<init>(SigningDigest.java:40)

at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:281)

at jcifs.smb.SmbSession.send(SmbSession.java:233)

at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)

at jcifs.smb.SmbSession.logon(SmbSession.java:169)

at jcifs.smb.SmbSession.logon(SmbSession.java:162)

at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:191)

at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:119)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)

at java.lang.Thread.run(Thread.java:619)

at jcifs.smb.SigningDigest.<init>(SigningDigest.java:57)