-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin@intergrafix.net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Sun, 19 Sep 1999, Fuzzy Fox wrote:
> Matthew Vanecek <mev0003@unt.edu> wrote:
> >
> > On a more constructive note, what in NT/samba combination would cause
> > the connection to drop, if everything is working normally?
>
> Even SAMBA has a parameter called "dead time." This is the time that a
> connection that is idle will be considered "dead," and the connection
> quietly dropped by the server. That means that, if there is no activity
> after a certain amount of time, a SAMBA server configured this way will
> exhibit the same behavior that NT does, i.e. dropping the connection
> after a period of inactivity.
>
> This seems to be an occurrence that all of the various OS's (Win9x, NT,
> SAMBA) understand very well: If they find that their connection has
> been dropped, the next time they try to use it, they will simply
> re-establish the connection, and proceed. However, this requires the
> password information to be re-exchanged, and this is the key to SMBFS's
> failure.
>
> The MS OS's have their own particular ways of maintaining password
> caches, and so re-establishing these connections is just a matter of
> course. For SMBFS, this is not so simple, since we desire to have good
> separation between kernel and user space tools, something Microsoft can
> only wish that they had...
>
> >From what I've seen posted on this problem before, it really does seem
> to be a breakdown in the kernel-user interface between the smbmount
> utility and the kernel itself.
>
> When the kernel goes to access an SMB share, and finds that the
> connection has died, it sends a signal to the smbmount process, which
> should be waiting around for exactly such a signal. When it catches it,
> the smbmount utility is supposed to re-establish the connection, and
> then pass that new connection info back to the kernel so that the
> operation can be retried.
>
> When people have reported this problem before, the answer returned by
> the developers seems to be "Well, we don't see that here. We can't
> reproduce the problem. Why don't you attach a debugger to your smbmount
> process, and when the problem happens, try to examine some variables and
> maybe give us a clue what might be going wrong?"
>
> And the answer from the community seems to be a collective "HUH??" and
> so, nothing happens that might fix the problem.
>
> Anyway, that's the way I see it.
>
> --
> fox@dallas.net (Fuzzy Fox) || "Just about every computer on the market
> sometimes known as David DeSimone || today runs Unix, except the Mac (and
> http://www.dallas.net/~fox/ || nobody cares about it). -- Bill Joy '85
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/