??????: ???`: ??????: When the keep-alive packet sent out,rfc1002 says different things!!

Thu Apr 3 08:40:35 GMT 2003

-----Original Message-----
From: Christopher R. Hertel [mailto:crh at ubiqx.mn.org]
Sent: Wednesday, April 02, 2003 11:58 AM
To: Aladdin Cai(²ÌÈÕ»ù_ÈA½ÝÉÏº££©
Cc: abartlet at samba.org; samba-technical at lists.samba.org
Subject: Re: ??????: ???`: ??????: When the keep-alive packet sent out,rfc1002 says different things!!

On Tue, Apr 01, 2003 at 06:01:54PM +0800, Aladdin_Cai at asus.com.cn wrote:
:
> Ethereal is recommended, if only because the rest of us know how to read 
> it...
> 
> ^^^^^^^^^^ Thanks, I will download it and try.Is it more powerful than NAI
>            sniffer? NAI sniffer will treat a packet simply beginning with
>            0x85 as keep-alive, an obvious bug:)

I have no idea, since I know nothing about the NAI sniffer.  What I do 
know is that there are some very bright Samba folk committing code to the 
Ethereal project.

> When they receive an *NBT* packet.  The NBT keepalive timer is managed at
> the NBT layer.  The TCP stream won't reset the timer, but the initial READ
> RAW request *should* reset the timer.
> 
> ^^^^^^^^But I think raw data is also an NBT packet, which is passed
>         through to user layer.

Ah... No, it's not!  :)
These are layered protocols.  The entire READ RAW is considered one SMB
'message'.  Each SMB message is packed within a single NBT Session Service
wrapper (which is just the header).

	$$$En, you give a light on me. I had though that the raw data packet during a ReadRaw is 
	considered as a NBT message too. Now come to know this, can I draw a conclusion that during 
	a ReadRaw or WriteRaw, keep-alive will NOT be inserted into the middle, because layer protocol
	has to promise to send out an intact protocol message.Oh, I have tried many times and  the keep-alive
	always occured after all data in ReadRaw( or write) request have be received.What do you think of 
	my opinion.?

> 	So, server is responsible to reset the timer anyway. And the read raw
>       request, doesn't reset timer either, as I have seen, just between
>       two read request, keep-alive occurs.

The way it *should* work is that the initial request (the READ RAW request
or the WRITE RAW request) should reset the timer.  Even if that didn't
happen, the READ/WRITE RAW response *should* complete before the server
sends any keep-alives.  What I *think* you are saying is that neither of
those things happen.  Again, I have trouble imagining it, but I'm
certainly willing to look at a capture.

	$$$Yes, I try hard today and capture the picture, and I am glad ethereal can read the data format
	of NAI sniffer( I think NAI sniffer is more user-friendly than ethereal).So I will send directly the capture
	of a WriteRaw to you.You can use ethereal to open it.You can find that WriteRaw 
	 CAN'T reset keep-alive timer. Keep-alive would appear just soon after a request has finished.
	 The server is a linux platform. Its keepalive timeout I have set 
	to be 30 secs.( I let my code sleep somewhere so I don't have to capture so many packets.)

> I really can't imagine Samba making the mistake of sending the keep-alive 
> while it is in the middle of a READ RAW operation, but I would believe it 
> if I saw a capture that shows it (an Ethereal capture would be 
> best...www.ethereal.com...it's free).
> 
> ^^^^^^^ I really don't see this too. What I have seen is that keep-alive
>       appends to the head of response or a seperate keep-alive packet.
>       But I have no evidence that it will NOT be sent out during raw data
>       stream,especially in a mutithread environment.

Hmmm...  A keep-alive before or after the READ/WRITE RAW is perfectly 
okay.  The keep-alives are part of the NBT layer, not the SMB layer, and 
may show up asynchronously.  They *should*, however, show up before or 
after another NBT message...definitely not in the middle.  I understand 
your concern, but unless there is evidence of a keep-alive showing up 
inside another NBT message I wouldn't worry about it.

> ^^^^^^^  And I find a way,in windows, there is a registry key controlling
>       sessionkeepalive(it just name of it) So, I can switch it off then 
>       none of keep-alive can be sent out any more.If no other safer
> 	solution, I will do it this way.

That's not a safe solution, since you won't have control over the server 
once you release your client software.

Good luck!

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WR.cap
Type: application/octet-stream
Size: 3997 bytes
Desc: WR.cap
Url : http://lists.samba.org/archive/samba-technical/attachments/20030403/80d0eb6e/WR.obj