[jcifs] patch for exposing transports

[Michael B Allen]

On Tue, Aug 5, 2008 at 6:57 PM, Matt Parker <parkerman at gmail.com> wrote:
>>> - I know that it would be more scalable and efficient to re-use
>>> transports, but I haven't been able to successfully do so without
>>> having sporadic StatusAccessDenied errors, even when using smb
>>
>> That sounds like the "hiccup bug" which was diagnosed a few weeks ago.
>> I also posted a message regarding fixing the issue:
>>
>> http://www.nabble.com/Re%3A-NTLM-usrname-password-failure-after-each-5-mins-p18096894.html
>>
>> And someone posted a refcount based patch (that I can't speak for).
>
> Yes, that's another valid approach. Are you considering including that
> patch instead? Or are you not accepting patches?  i really am not
> partial to my patch, i'd just like something in the main line of jcifs
> to fix this so that i don't have to maintain a locally modified
> version.

This message describes my plans for the JCIFS NTLM HTTP Filter:

http://www.nabble.com/RE%3A-JCIFS-Pops-up-dialog-box-for-Authenticating-certain-users-p18374786.html

>>> signing. This solution is scalable enough for my needs, and allows me
>>> to choose between whether it's okay to fail occasionally with better
>>> performance, or to never fail but with a heavier network/server load.
>>> - using ssnLimit doesn't work well for me
>>
>> That should work so if it doesn't you might try to figure out why.
>
> i know why--without some kind of patch to jcifs, servicing multiple
> clients over the same transport causes what appears to be the "hiccup
> bug" as you describe, which means that the transport may disconnect
> before all auths have been serviced. why would anyone want
> non-deterministic auth failures in their system when there are simple
> solutions available?

No, I mean you might want to figure out why setting ssnLimit = 1
"doesn't work well".

>>> - setting soTimeout to something like 1000 prevents lingering
>>
>> Actually increasing soTimeout should increase "lingering" connections.
>
> i don't disagree. but since the default is 35000, setting it to 1000
> is indeed a decrease.

Ah yes - it's in milliseconds. I forgot.

So are you setting soTimeout to 1000 ms? If yes, that's your problem
right there.

The frequency of the "hiccup bug" is inversely and logarithmically
proportional to the soTimeout value. The higher the soTimeout value,
the less frequently the "huccup bug" will occur. If you reduce
soTimeout, the "huccup bug" will occur more frequently. With an
soTimeout value of 1000 ms, you're virtually guaranteed to trigger the
bug - possibly even with only one client.

The "hiccup" occurs when the soTimeout expires and the transports are
closed while the NTLM negotiation is ongoing thereby invalidating the
corresponding client challenge. By increasing the soTimeout value you
reduce the chances of that happening.

Unfortunately as you increase the soTimeout value you leave the socket
open to the DC. But for the HTTP Filter that really shouldn't be much
of a concern (In the NT domain days, Windows workstations would leave
a NETLOGON pipe open for the user's entire session!).

We should probably just increase the soTimeout in the filter to 60
minutes and see if people still complain.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/