[cifs-protocol] [REG:110012953632586] [MS-WINSRA] 188.8.131.52 Name Record Padding field description incorrect
billwe at microsoft.com
Fri Jan 29 07:58:53 MST 2010
Good morning Stefan - thanks for your comments. I have created the below case to track the issue. One of my team members will contact you shortly!
110012953632586 [MS-WINSRA] 184.108.40.206 Name Record Padding field description incorrect
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email: billwe at microsoft.com
Tel: +1(980) 776-8200
Cell: +1(704) 661-5438
Fax: +1(704) 665-9606
Microsoft is committed to protecting your privacy. Please read the Microsoft Privacy Statement for more information.
The above is an email for a support case from Microsoft Corp.
REPLY ALL TO THIS MESSAGE or INCLUDE casemail at microsoft.com
IN YOUR REPLY if you want your response added to the case automatically.
For technical assistance, please include the Support Engineer on the TO: line.
From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
Sent: Friday, January 29, 2010 9:25 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: CAR: Bug in MS-WINSRA section "220.127.116.11 Name Record"
I found a bug in MS-WINSRA section "18.104.22.168 Name Record".
> Padding (variable): If the Name field is not 4-byte aligned, this
> Padding field will be added to pad to 4-byte alignment. If the Name
> field itself is 4-byte aligned, then there is no Padding field. This
> field MUST be ignored upon receipt.
This is wrong!
The documentation would indicate this:
pad_len = ((offset & (4-1)) == 0 ? 0 : (4 - (offset & (4-1))))
But Windows Servers (at least 2003 SP1 and 2008) use this:
pad_len = 4 - (offset & (4-1));
The difference is the case where the name field is already 4 byte aligned. In that case Windows adds 4 bytes instead of 0 bytes of aligment.
See frame 75 in the attached capture (172.31.9.211 is a windows 2008 server and 172.31.9.1 a modified smbtorture).
The name length is 20 and there're 4 extra bytes before the Reserved1 field.
More information about the cifs-protocol