Oplock question

Bruce Tenison btenison at dibbs.net
Fri Jan 15 22:50:03 GMT 1999


Hi!  Been having the same problem with oplocks for a while and have been
trying to figure out what's going wrong.  The FAQ says that we may have a
networking (hardware?) problem, but according to the Linux box's ifconfig
results, we have had no errors and no dropped packets on the internal
network.  I am able to reproduce the error pretty much at will on our
network, and it is not isolated to any machine (or any set of machines,
except for all of the computers ;)  I was able to get one computer
constantly oplocking a file, then get another computer to request the
oplock_break, which the first computer would (according to the samba logs)
not respond.  During this time, I used tcpdump-smp to monitor the traffic
between the first computer and the server (both the tcpdump and the
samba-log portion are attached below)

First, I have a question.  Is it the responsibility of Windows to flush
the data and respond to the oplock_break request, or does Windows pass the
request on to the program that's running and request that IT flush and/or
close the file?

Here's what I'm running into.  We have two computers
(tenison and iee2) both with F-Prot antivirus software running on them and
a communication directory on the server for administration purposes.  In
the communication directory, there is a file called COMM.INF that the
administering F-Prot uses to pass tasks, bulletins, etc back and forth to
the non-admin F-Prots.  OK...  F-Prot on Tenison (admin) locks COMM.INF.
Iee2 now needs to use COMM.INF, so it requests an oplock from the server.
The server sends an oplock_break to tenison.  This is where I have
problems.  Can the F-Prot program block the oplock_break from happening,
or is it the sole responsibility of Windows on whether the oplock_break
succeeds or fails.  (Just wondering where to place the emphasis.  Windows
or F-Prot???)

>From the tcpdump, it looks like (if I'm reading the correct portion of the
file) tenison is receiving the oplock_break (SMBlockX in tcpdump lingo???)
and is ack-ing in response.  Then Gate (our server) resends the
oplock_break.  WHY?   HELP!

Does this information make any sense?  Is there anything else we can do to
figure out what is the culprit here (short of oplocks=no as I have it now
so that all will work!)

Any input is sincerely appreciated!

Bruce

>From the tcpdump-smb -s 110 host tenison.irstc.cc.al.us command:

 (DF)
14:10:49.318846 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: P 4136:4187(51) ack 3005 win 8760
>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=47

SMB PACKET: SMBunlink (REQUEST)
SMB Command   =  0x6
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  1
Proc ID       =  13421
UID           =  100
MID           =  8322
Word Count    =  1
smbvwv[]=
Attrib=HIDDEN SYSTEM
smbbuf[]=
Path=\tmp.~nf


 (DF)
14:10:49.318846 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: P 3005:3044(39) ack 4187 win 32736
>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=35

SMB PACKET: SMBunlink (REPLY)
SMB Command   =  0x6
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  1
Proc ID       =  13421
UID           =  100
MID           =  8322
Word Count    =  0
smb_bcc=0


 (DF)
14:10:49.488846 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: . ack 3044 win 8721 (DF)
14:11:16.379305 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: P 3044:3099(55) ack 4187 win 32736
>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=51

SMB PACKET: SMBlockingX (REQUEST)
SMB Command   =  0x24
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  1
Proc ID       =  65535
UID           =  0
MID           =  65535
Word Count    =  8
smbvwv[]=
Com2=0xFF
Off2=0
Handle=4167
LockType=0x2
TimeOut=0
UnlockCount=0
LockCount=0
smbbuf[]=
Process=

 (DF)
14:11:16.499305 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: . ack 3099 win 8666 (DF)
14:11:26.385772 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: P 3099:3154(55) ack 4187 win 32736
>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=51

SMB PACKET: SMBlockingX (REQUEST)
SMB Command   =  0x24
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  1
Proc ID       =  65535
UID           =  0
MID           =  65535
Word Count    =  8
smbvwv[]=
Com2=0xFF
Off2=0
Handle=4167
LockType=0x2
TimeOut=0
UnlockCount=0
LockCount=0
smbbuf[]=
Process=

 (DF)
14:11:26.505772 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: . ack 3154 win 8611 (DF)
14:11:36.392238 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: P 3154:3209(55) ack 4187 win 32736
>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=51

SMB PACKET: SMBlockingX (REQUEST)
SMB Command   =  0x24
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  1
Proc ID       =  65535
UID           =  0
MID           =  65535
Word Count    =  8
smbvwv[]=
Com2=0xFF
Off2=0
Handle=4167
LockType=0x2
TimeOut=0
UnlockCount=0
LockCount=0
smbbuf[]=
Process=

 (DF)
14:11:36.532238 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: . ack 3209 win 8556 (DF)
14:11:46.398705 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: P 3209:3264(55) ack 4187 win 32736
>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=51

SMB PACKET: SMBlockingX (REQUEST)
SMB Command   =  0x24
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  1
Proc ID       =  65535
UID           =  0
MID           =  65535
Word Count    =  8
smbvwv[]=
Com2=0xFF
Off2=0
Handle=4167
LockType=0x2
TimeOut=0
UnlockCount=0
LockCount=0
smbbuf[]=
Process=

 (DF)
14:11:46.568695 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: . ack 3264 win 8501 (DF)
14:11:56.405171 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: F 3264:3264(0) ack 4187 win 32736
14:11:56.405171 tenison.irstc.cc.al.us.1293 >
gate.irstc.cc.al.us.netbios-ssn: F 4187:4187(0) ack 3265 win 8501 (DF)
14:11:56.405171 gate.irstc.cc.al.us.netbios-ssn >
tenison.irstc.cc.al.us.1293: . ack 4188 win 32735 (DF)
14:12:02.333051 gate.irstc.cc.al.us.telnet > tenison.irstc.cc.al.us.1172:
. ack 474079 win 32736
14:12:02.333051 tenison.irstc.cc.al.us.1172 > gate.irstc.cc.al.us.telnet:
. ack 1 win 7973 (DF)


And from the corresponding time stamp in the samba-log (debug level=1):

Jan 15 14:11:48 gate smbd[19557]: [1999/01/15 14:11:48, 0]
smbd/oplock.c:request_oplock_break(943)
Jan 15 14:11:48 gate smbd[19557]:   request_oplock_break: no response
received to oplock break request to pid 19246 on port 1457 for dev = 301
, inode = 620605
Jan 15 14:11:56 gate smbd[19246]: [1999/01/15 14:11:56, 0]
smbd/oplock.c:oplock_break(742)
Jan 15 14:11:56 gate smbd[19246]:   oplock_break: receive_smb timed out
after 30 seconds.
Jan 15 14:11:56 gate smbd[19246]:   oplock_break failed for file comm.inf
(dev = 301, inode = 620605).
Jan 15 14:11:56 gate smbd[19246]: [1999/01/15 14:11:56, 0]
smbd/oplock.c:oplock_break(812)
Jan 15 14:11:56 gate smbd[19246]:   oplock_break: client failure in break
- shutting down this smbd.
Jan 15 14:11:56 gate smbd[19246]: [1999/01/15 14:11:56, 1]
smbd/service.c:close_cnum(514)
Jan 15 14:11:56 gate smbd[19246]:   tenison (0.0.0.0) closed connection to
service virus
Jan 15 14:12:02 gate smbd[20172]: [1999/01/15 14:12:02, 1]
smbd/service.c:make_connection(488)
Jan 15 14:12:02 gate smbd[20172]:   ost1 (192.168.2.128) connect to
service esimpson as user esimpson (uid=733, gid=100) (pid 20172)
Jan 15 14:12:20 gate smbd[19557]: [1999/01/15 14:12:20, 0]
smbd/oplock.c:request_oplock_break(943)
Jan 15 14:12:20 gate smbd[19557]:   request_oplock_break: no response
received to oplock break request to pid 19246 on port 1457 for dev = 301
, inode = 620605
Jan 15 14:12:20 gate smbd[19557]: [1999/01/15 14:12:20, 1]
smbd/service.c:close_cnum(514)
Jan 15 14:12:20 gate smbd[19557]:   ost1 (0.0.0.0) closed connection to
service virus






More information about the samba mailing list