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

[Christopher R. Hertel]

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

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

> 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