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

Aladdin_Cai at asus.com.cn Aladdin_Cai at asus.com.cn
Tue Apr 1 10:01:54 GMT 2003



-----原始邮件-----
发件人: Christopher R. Hertel [mailto:crh at ubiqx.mn.org]
发送时间: 2003年4月1日 15:29
收件人: Aladdin Cai(絆價_豎奻漆ㄘ
抄送: abartlet at samba.org; samba-technical at lists.samba.org
主题: Re: ???`: ??????: When the keep-alive packet sent out,rfc1002 says different things!!


On Tue, Apr 01, 2003 at 01:33:14PM +0800, Aladdin_Cai at asus.com.cn wrote:
:
> ...but they will be in sequence, not mixed.  The WriteRaw OK message will 
> be a complete SMB message, so you will not have any trouble parsing them.
> Just read the number of bytes specified in the NBT header's length field.
> 
> ~~~~~~~~~~~ Here  I'd ask a quite stupid question:) :If  server sends
>             client two packets, one by one.
> 	      Until both are in socket buffer,client calls recv( ) to get
>             the all in buffer, will client get a mixture 
> 	      or only the first packet?

That's a very good question, actually...
TCP provides a stream.  The packets will be made available in the order in 
which they were sent, but *not* as discreet packets.  You might call 
recv() and get the end of the last packet, all of the current packet, and 
the first part of the next packet.  You have to collect and parse the 
input.

The nature of the SMB protocol hides that fact.  In general, the client 
will only get a message from the server if the client asked for it.  You 
send a request, wait for the entire reply, then send another request.

The keep-alive is one situation in which the messages can get interleaved.  
It can also happen if there are multiple processes using the same SMB 
connection.

>             If it is the first situation,Then,I have to suppose that it 
>             is possible
> 	      that keep-alive is in front of WriteRaw OK,then I have to
>             remove first 4Bytes and get 
> 	      WriteRaw OK.It is more troublesome.

Could be ahead, could be behind.  Fortunately, the NBT Session Service 
headers all provide a message length field.  Yes, you do have to watch for 
and handle this situation.

:
> ~~~~~~~~~~ I 'd like to show you the read raw packet format, which I 
>            have got using NAI sniffer4.6.

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 make a picture,pls
>            see the attached file. You can see that in read raw,the first
>            packet has a netbios header,yet the others haven't.

Okay.  I wasn't sure about that.  Thanks for letting me know.

>               As I have seen in rfc1002, server or client should reset
>               timer when they receive a packet.

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.
	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.

>               If so, we won't have to worry about keep-alive packet.
>               I don't know why they ignore this rule, introducing 
> 		so much complexity.

What I can't tell from the graphic you sent is whether the keep-alive 
message is interleaved with the raw read messages.  It shouldn't be 
because, as I've said, the initial READ RAW request from the client should 
reset the timer and the READ RAW itself should be finished before the 
timer expires.

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.

^^^^^^^  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.

Windows... well, I suppose it would be easier to imagine, but I'd still 
want to see the capture.

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


More information about the samba-technical mailing list