On Tue, Apr 01, 2003 at 06:01:54PM +0800, [EMAIL PROTECTED] 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/ -)----- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/ -)----- [EMAIL PROTECTED]