On Sun, Aug 5, 2012 at 2:54 PM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote: > Hi folks, > > [MS-CIFS] in section 2.2.1.6.2 says, in part: > > --------------- > The value 0xFFFF MUST NOT be used as a valid MID. All other possible > values for MID, including > zero (0x0000), are valid. The value 0xFFFF is used in an OpLock Break > Notification request, > which is an SMB_COM_LOCKING_ANDX Request (section 2.2.4.32.1) sent > from the server. > --------------- > > However, in smb1ops.c:cifs_get_next_mid I do not see where a MID value > of 0xFFFF is skipped. > > Perhaps it is done somewhere else that I have not found, and if so, > could someone point it out to me? I don't see a place where this was checked, and cifs.ko has been doing this presumably before MS-CIFS was published. Apparently has not been causing problems having a mid of 0xFFFF from time to time, but might as well fix it so we never send such a mid. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html