Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Stefan, I am just following up on this request to collect the TTT trace on this issue. We will need the trace to pursue the investigation. We have not observed behavior (of 255 bytes Name Length) between Windows-based WINS replication partners. Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Friday, February 12, 2010 12:09 PM To: Stefan (metze) Metzmacher Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Stefan, Regarding the issue you raised on replicating a name with a length of 255, we have not observed the behavior between Windows-based WINS replication partners. We need you reproduce the issue in your environment and send us the network trace and time travel tracing (TTT). I created the following workspace and uploaded the TTT utility for you: Workspace location: (https://sftus.one.microsoft.com/choosetransfer.aspx?key=0591488a-b578-409a-88df-288aaf6cdf1f) Password: i...@zy!ikccrmy3 Please collect the traces per these instructions: 1. Run the TTTSetup_x86_external.msi to install capture utility on Windows 2008 WINS server. 2. Open a command prompt and CD to your TTT folder ( ex. cd C:\Debuggers\ttt ) 3. If running on Vista/Windows Server 2008 or later make sure to run the following command from and elevated command prompt the first time after a reboot: TTTracer –initialize This will install the driver that is used to capture the data. 4. Find process ID for WINS.EXE process. You can use Task Manager to do this. 5. Type this command for each process, using a separate cmd prompt for each process we are attaching to: TTTracer.exe -attach pid -dumpFull pid is the process id of the wins.exe process. You should see a small dialog box pops up that has the title wins01.run. 6. Start network capture, e.g. by using Wireshark or Network Monitor. 7. Reproduce the problem. 8. Uncheck “Tracing on” in the dialog box and dismiss them. At this point you should see an .out file and a .run file under your ttt folder. 9. Upload the .out and .run files, along with the corresponding network trace on the workspace. Best regards, Edgar -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, February 04, 2010 1:19 PM To: Edgar Olougouna Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Edgar, Could you send me which build of Windows 2008 you ran the tests corresponding to the network traces you provided? To determine the version, service pack and build number: Start Run msinfo32 On the System Summary, the Version item provides that information. Microsoft Windows Server 2008 Standard 6.0.6001 Service Pack 1 Build 6001 It's the 32-Bit Version. metze Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Monday, February 01, 2010 9:39 AM To: Stefan (metze) Metzmacher; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [REG:110012953632586] RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Thanks Stefan - forwarding this email to Edgar, who owns the case. 110012953632586 Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email:bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Saturday, January 30, 2010 4:40 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Bill, there's one additional bug regarding the Name length. Name (variable): Name terminates with a 0x00 byte. It may include a NetBIOS scope identifier, as specified in [RFC1001]. The maximum length of the Name field is 255 bytes including the 0x00 byte. If no NetBIOS scope is included, then the length of the name is 17 including the 0x00 byte. When a windows server gets a name with length == 255 it removes the last character of the scope before storing it. Windows returns a name with length 254 when it returns the name again. See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a modified smbtorture). Frame 19 smbtorture = windows 2008 name length 255 Frame 25 windows 2008 = smbtorture name length 254 metze
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Edgar, sorry I'm busy with other stuff currently. Stefan, I am just following up on this request to collect the TTT trace on this issue. We will need the trace to pursue the investigation. We have not observed behavior (of 255 bytes Name Length) between Windows-based WINS replication partners. I'll try to produce it next week. metze -Original Message- From: Edgar Olougouna Sent: Friday, February 12, 2010 12:09 PM To: Stefan (metze) Metzmacher Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Stefan, Regarding the issue you raised on replicating a name with a length of 255, we have not observed the behavior between Windows-based WINS replication partners. We need you reproduce the issue in your environment and send us the network trace and time travel tracing (TTT). I created the following workspace and uploaded the TTT utility for you: Workspace location: (https://sftus.one.microsoft.com/choosetransfer.aspx?key=0591488a-b578-409a-88df-288aaf6cdf1f) Password: i...@zy!ikccrmy3 Please collect the traces per these instructions: 1. Run the TTTSetup_x86_external.msi to install capture utility on Windows 2008 WINS server. 2. Open a command prompt and CD to your TTT folder ( ex. cd C:\Debuggers\ttt ) 3. If running on Vista/Windows Server 2008 or later make sure to run the following command from and elevated command prompt the first time after a reboot: TTTracer –initialize This will install the driver that is used to capture the data. 4. Find process ID for WINS.EXE process. You can use Task Manager to do this. 5. Type this command for each process, using a separate cmd prompt for each process we are attaching to: TTTracer.exe -attach pid -dumpFull pid is the process id of the wins.exe process. You should see a small dialog box pops up that has the title wins01.run. 6. Start network capture, e.g. by using Wireshark or Network Monitor. 7. Reproduce the problem. 8. Uncheck “Tracing on” in the dialog box and dismiss them. At this point you should see an .out file and a .run file under your ttt folder. 9. Upload the .out and .run files, along with the corresponding network trace on the workspace. Best regards, Edgar -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, February 04, 2010 1:19 PM To: Edgar Olougouna Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Edgar, Could you send me which build of Windows 2008 you ran the tests corresponding to the network traces you provided? To determine the version, service pack and build number: Start Run msinfo32 On the System Summary, the Version item provides that information. Microsoft Windows Server 2008 Standard 6.0.6001 Service Pack 1 Build 6001 It's the 32-Bit Version. metze Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Monday, February 01, 2010 9:39 AM To: Stefan (metze) Metzmacher; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [REG:110012953632586] RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Thanks Stefan - forwarding this email to Edgar, who owns the case. 110012953632586 Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel: +1(980) 776-8200 Cell:+1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Saturday, January 30, 2010 4:40 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Bill, there's one additional bug regarding the Name length. Name (variable): Name terminates with a 0x00 byte. It may include a NetBIOS scope identifier, as specified in [RFC1001]. The maximum length of the Name field is 255 bytes including the 0x00 byte. If no NetBIOS scope is included, then the length of the name is 17 including the 0x00 byte. When a windows server gets a name with length == 255 it removes the last character of the scope before storing it. Windows returns a name with length 254 when it returns the name again. See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a modified
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Stefan, Regarding the issue you raised on replicating a name with a length of 255, we have not observed the behavior between Windows-based WINS replication partners. We need you reproduce the issue in your environment and send us the network trace and time travel tracing (TTT). I created the following workspace and uploaded the TTT utility for you: Workspace location: (https://sftus.one.microsoft.com/choosetransfer.aspx?key=0591488a-b578-409a-88df-288aaf6cdf1f) Password: i...@zy!ikccrmy3 Please collect the traces per these instructions: 1. Run the TTTSetup_x86_external.msi to install capture utility on Windows 2008 WINS server. 2. Open a command prompt and CD to your TTT folder ( ex. cd C:\Debuggers\ttt ) 3. If running on Vista/Windows Server 2008 or later make sure to run the following command from and elevated command prompt the first time after a reboot: TTTracer –initialize This will install the driver that is used to capture the data. 4. Find process ID for WINS.EXE process. You can use Task Manager to do this. 5. Type this command for each process, using a separate cmd prompt for each process we are attaching to: TTTracer.exe -attach pid -dumpFull pid is the process id of the wins.exe process. You should see a small dialog box pops up that has the title wins01.run. 6. Start network capture, e.g. by using Wireshark or Network Monitor. 7. Reproduce the problem. 8. Uncheck “Tracing on” in the dialog box and dismiss them. At this point you should see an .out file and a .run file under your ttt folder. 9. Upload the .out and .run files, along with the corresponding network trace on the workspace. Best regards, Edgar -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, February 04, 2010 1:19 PM To: Edgar Olougouna Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Edgar, Could you send me which build of Windows 2008 you ran the tests corresponding to the network traces you provided? To determine the version, service pack and build number: Start Run msinfo32 On the System Summary, the Version item provides that information. Microsoft Windows Server 2008 Standard 6.0.6001 Service Pack 1 Build 6001 It's the 32-Bit Version. metze Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Monday, February 01, 2010 9:39 AM To: Stefan (metze) Metzmacher; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [REG:110012953632586] RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Thanks Stefan - forwarding this email to Edgar, who owns the case. 110012953632586 Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email:bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Saturday, January 30, 2010 4:40 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Bill, there's one additional bug regarding the Name length. Name (variable): Name terminates with a 0x00 byte. It may include a NetBIOS scope identifier, as specified in [RFC1001]. The maximum length of the Name field is 255 bytes including the 0x00 byte. If no NetBIOS scope is included, then the length of the name is 17 including the 0x00 byte. When a windows server gets a name with length == 255 it removes the last character of the scope before storing it. Windows returns a name with length 254 when it returns the name again. See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a modified smbtorture). Frame 19 smbtorture = windows 2008 name length 255 Frame 25 windows 2008 = smbtorture name length 254 metze Good morning Stefan - I am including our below initial response, since I missed CC: doch...@microsoft.com on the first one. -Original Message- From: Bill Wesse Sent: Friday, January 29, 2010 9:59 AM To: 'me...@samba.org' Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect Good morning Stefan - thanks for your comments. I have created the below case to track the issue.
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Hi Stefan, We completed our investigation on the Padding issue regarding the name record in MS-WINSRA. The product team confirmed the observed behavior. As a result, the definition of the Padding field will be updated to reflect the following. The change will appear in a future release of the document. MS-WINSRA section 2.2.10.1 Name Record. Current definition: 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. Update similar to: Padding (variable): If the Name field is not 4-byte aligned, the Padding field is padded to 4-byte alignment. If the Name field itself is 4-byte aligned, then the Padding field is padded with 4 bytes. This field MUST be ignored upon receipt. Best regards, Edgar -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, January 29, 2010 8:25 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi, I found a bug in MS-WINSRA section 2.2.10.1 Name Record. It says: 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. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Hi Edgar, Could you send me which build of Windows 2008 you ran the tests corresponding to the network traces you provided? To determine the version, service pack and build number: Start Run msinfo32 On the System Summary, the Version item provides that information. Microsoft Windows Server 2008 Standard 6.0.6001 Service Pack 1 Build 6001 It's the 32-Bit Version. metze Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Monday, February 01, 2010 9:39 AM To: Stefan (metze) Metzmacher; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [REG:110012953632586] RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Thanks Stefan - forwarding this email to Edgar, who owns the case. 110012953632586 Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email:bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Saturday, January 30, 2010 4:40 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Bill, there's one additional bug regarding the Name length. Name (variable): Name terminates with a 0x00 byte. It may include a NetBIOS scope identifier, as specified in [RFC1001]. The maximum length of the Name field is 255 bytes including the 0x00 byte. If no NetBIOS scope is included, then the length of the name is 17 including the 0x00 byte. When a windows server gets a name with length == 255 it removes the last character of the scope before storing it. Windows returns a name with length 254 when it returns the name again. See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a modified smbtorture). Frame 19 smbtorture = windows 2008 name length 255 Frame 25 windows 2008 = smbtorture name length 254 metze Good morning Stefan - I am including our below initial response, since I missed CC: doch...@microsoft.com on the first one. -Original Message- From: Bill Wesse Sent: Friday, January 29, 2010 9:59 AM To: 'me...@samba.org' Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect 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] 2.2.10.1 Name Record Padding field description incorrect Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel: +1(980) 776-8200 Cell:+1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, January 29, 2010 9:25 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi, I found a bug in MS-WINSRA section 2.2.10.1 Name Record. It says: 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. signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [REG:110012953632586] RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Thanks Stefan - forwarding this email to Edgar, who owns the case. 110012953632586 Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Saturday, January 30, 2010 4:40 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Bill, there's one additional bug regarding the Name length. Name (variable): Name terminates with a 0x00 byte. It may include a NetBIOS scope identifier, as specified in [RFC1001]. The maximum length of the Name field is 255 bytes including the 0x00 byte. If no NetBIOS scope is included, then the length of the name is 17 including the 0x00 byte. When a windows server gets a name with length == 255 it removes the last character of the scope before storing it. Windows returns a name with length 254 when it returns the name again. See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a modified smbtorture). Frame 19 smbtorture = windows 2008 name length 255 Frame 25 windows 2008 = smbtorture name length 254 metze Good morning Stefan - I am including our below initial response, since I missed CC: doch...@microsoft.com on the first one. -Original Message- From: Bill Wesse Sent: Friday, January 29, 2010 9:59 AM To: 'me...@samba.org' Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect 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] 2.2.10.1 Name Record Padding field description incorrect Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email:bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, January 29, 2010 9:25 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi, I found a bug in MS-WINSRA section 2.2.10.1 Name Record. It says: 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. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Good morning Stefan - I am including our below initial response, since I missed CC: doch...@microsoft.com on the first one. -Original Message- From: Bill Wesse Sent: Friday, January 29, 2010 9:59 AM To: 'me...@samba.org' Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect 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] 2.2.10.1 Name Record Padding field description incorrect Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, January 29, 2010 9:25 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi, I found a bug in MS-WINSRA section 2.2.10.1 Name Record. It says: 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. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
