??????: ???`: ??????: When the keep-alive packet sent
out,rfc1002 says different things!!
Christopher R. Hertel
crh at ubiqx.mn.org
Wed Apr 2 03:58:00 GMT 2003
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
More information about the samba-technical
mailing list