Linux-kernel mailing list archive 1997-47,: Re: 2.1.66 smbfs oops

# Re: 2.1.66 smbfs oops

Bill Hawes (whawes@star.net)
Thu, 27 Nov 1997 08:42:12 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Rik van Riel: "Re: fork: out of memory"
- Previous message: Rik van Riel: "Re: pageable page tables"
- Maybe in reply to: Chris Wedgwood: "2.1.66 smbfs oops"
- Next in thread: Bill Hawes: "Re: 2.1.66 smbfs oops"

Chris Wedgwood wrote:
>
> OK... I did this but I put the box behind a firewall and let it timeout on
> TCP to try and expedite the test.
>
> I traced it and nothing happened. Just sat their in pause. I got the
> following messages the first time I tried to access the volume (doing 'df'):
>
> smb_get_length: recv error = 110
> smb_request: result -110, setting invalid
> smb_retry: timed out, try again later
>
> and from that point onwards I would get just
>
> smb_retry: timed out, try again later
>
> netstat would report the connection was open still... which in theory it
> probably was except the firewall didn't know about it any more.

Hi Chris,

When a connection drops, you should see the "result xxx, setting
invalid", and then smbfs sends a signal to the smbclient process. Smbfs
then waits for a new connection. The smbclient process is supposed to
wake up, get a new socket, and call some ioctls to install it. If you
get a "timed out, try again later", it means smbfs didn't get its new
connection.

So what I would like to see is what happens on the smbclient side after
smbfs sends the signal asking for a new connection.

Regards,
Bill

- Next message: Rik van Riel: "Re: fork: out of memory"
- Previous message: Rik van Riel: "Re: pageable page tables"
- Maybe in reply to: Chris Wedgwood: "2.1.66 smbfs oops"
- Next in thread: Bill Hawes: "Re: 2.1.66 smbfs oops"