[cifs-protocol] [REG:111082958393266] RE: Precision related to FRS documentation

Hongwei Sun hongweis at microsoft.com
Thu Sep 15 16:15:22 MDT 2011 

Matthieu, 

  I found that the host name set in COMM_TO field of COMM_PACKET is not a FQDN name of the upstream partner, as you observed in the trace.  It should be just a Netbois name.  This is actually shown in the example in 4.3 COMM_PACKET.  We are working on updating the related section in document MS-FRS1.  I can send you the final update when it is finalized.   If you have any more questions regarding this issue, please let me know  Otherwise I consider this issue closed.

Thanks!

Hongwei
 

-----Original Message-----
From: Matthieu Patou [mailto:mat at samba.org] 
Sent: Wednesday, September 07, 2011 4:45 PM
To: Hongwei Sun
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [REG:111082958393266] RE: [cifs-protocol] Precision related to FRS documentation

Hello Hongwei,

On 07/09/2011 22:55, Hongwei Sun wrote:
> Hi, Matthieu,
>
>     I am working on this request.  What are the format of the need_join_1 and need_join_2 attached ?   Also what are the difference between those two scenarios from the high level ?   The second instance returns " WARNING! 52 unread bytes".   And the first instance returns " NT_STATUS_OK".
They are extracted with wireshark from a dialog between 2 windows DCs, it's the payload of DCERPC packet for the FRSRPC protocol.
The second return 52 unread bytes because the end, of the packet contains 52 bytes that hasn't been consumed by the C code generated by our IDL parser. It's quite frequent in RPC code to receive packets from Windows server that have a couple of trialling bytes, apart from this the ndrdump returns NT_STATUS_OK when parsing this blob so it means that its structure is conform to what has been defined in our IDL.

Both blobs has been obtained from a network trace while S2-W2K3R2 is joining the domain w2k.home.matws.net as a DC.

The first blob is the need_join packet sent by S2-W2K3R2 just after sending a startpromotionparent, the second one is the need_join of the DC s1-w2k3r2 once the other DC has finished the FRS join.

If you can explain me why we have the 52 bytes at the end of the packet after the end BOP (0xffffffff) it could be great but I have the impression that it's mostly padding.

Matthieu.



>
>     FQDN and DNS host name effectively are the same.
>
> Thanks!
>
> Hongwei
>
> -----Original Message-----
> From: cifs-protocol-bounces at cifs.org 
> [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Matthieu Patou
> Sent: Monday, August 29, 2011 10:52 AM
> To: Interoperability Documentation Help; pfif at tridgell.net; 
> cifs-protocol at samba.org
> Subject: [cifs-protocol] Precision related to FRS documentation
>
>
> Hello Dochelp,
>
> I have a couple of question related to FRS, it seems that the documentation is not 100% coherent among different paragraph and with the traces and also I'm not 100% sure to understand what it means.
>
> In paragraph "3.3.4.4.1 Common Details" it is stated:
>
>
>
> "COMM_TO:
>   GUID: MUST be P_IN.COMM_FROM.GUID.
>   Name: MUST be FQDN of the partner"
>
>
> And in paragraph "3.3.4.6Establishing a Connection Session" it is stated:
>
> "COMM_TO:
> GUID: MUST be the objectGuid of the upstream partner NTFRS member object.
> Name: MUST be the DNS host name of the upstream partner."
>
> Is FQDN and DNS host name the same ? it seems so, if so can the same term be used in both places ?
>
> The thing is that traces between 2 w2k3r2 DCs seems to show a bit 
> different value
>
> As you can see below in the dump of need_join_1 and need_join_2 the 
> name field in the COMM_TO chunk is either a unc path
> ('\\s1-w2k3r2.w2k.home.matws.net') or short hostname ('S2-W2K3R2') and 
> the case makes me think it's more a netbios name (well in my case
> lower_case(netbios) = hostname(fqdn)).
>
>
> ./bin/ndrdump frsrpc frsrpc_FrsSendCommPkt in ~/need_join_1 pull 
> returned NT_STATUS_OK
> frsrpc_FrsSendCommPkt: struct frsrpc_FrsSendCommPkt
> in: struct frsrpc_FrsSendCommPkt
> req: struct frsrpc_FrsSendCommPktReq
> major : FRSRPC_COMM_PKT_MAJOR_0 (0)
> minor : FRSRPC_COMM_PKT_MINOR_8 (8)
> cs_id : 0x00000001 (1)
> memory_len : 0x00000200 (512)
> pkt_len : 0x00000196 (406)
> upk_len : 0x00000000 (0)
> ctr : *
> ctr: struct frsrpc_CommPktChunkCtr
> num_chunks : 0x00000009 (9)
> chunks: ARRAY(9)
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_BOP (0x1) data : union 
> frsrpc_CommPktChunkData(case 1) bop : 0x00000000 (0)
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_COMMAND (0x2) data : union 
> frsrpc_CommPktChunkData(case 2) command : FRSRPC_COMMAND_NEED_JOIN 
> (0x121)
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_TO (0x3)
> data : union frsrpc_CommPktChunkData(case 3)
> to: struct frsrpc_CommPktChunkGuidName guid : 
> 5a38e8ea-be6f-4f63-a15e-d28a70fecffe
> name : '\\s1-w2k3r2.w2k.home.matws.net'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_FROM (0x4) data : union 
> frsrpc_CommPktChunkData(case 4)
> from: struct frsrpc_CommPktChunkGuidName guid : 
> 0b23079e-6c35-44f5-803f-3e252489ec29
> name : 'S2-W2K3R2'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_REPLICA (0x5) data : union 
> frsrpc_CommPktChunkData(case 5)
> replica: struct frsrpc_CommPktChunkGuidName guid : 
> 5a38e8ea-be6f-4f63-a15e-d28a70fecffe
> name : 'DOMAIN SYSTEM VOLUME (SYSVOL SHARE)'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_CONNECTION (0x8) data : union 
> frsrpc_CommPktChunkData(case 8)
> connection: struct frsrpc_CommPktChunkGuidName guid : 
> f855cff3-5697-437e-a736-f46b590bd645
> name : '\\s1-w2k3r2.w2k.home.matws.net'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_JOIN_GUID (0x6) data : union 
> frsrpc_CommPktChunkData(case 6) join_guid : 
> 00000000-0000-0000-0000-000000000000
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_LAST_JOIN_TIME (0x12) data : union 
> frsrpc_CommPktChunkData(case 18) last_join_time : jeu. janv. 1 
> 01:00:00 1970 CET
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_EOP (0x13) data : union 
> frsrpc_CommPktChunkData(case 19) bopend : 0xffffffff (4294967295) 
> data_name : 0x00000002 (2) data_handle : 0x00000000 (0) dump OK
>
>
> ./bin/ndrdump frsrpc frsrpc_FrsSendCommPkt in ~/need_join_2 pull returned NT_STATUS_OK WARNING! 52 unread bytes [0000] 8A E3 13 71 02 F4 36 71 02 40 28 00 B4 59 CC F5 ...q..6q .@(..Y..
> [0010] 64 42 1A 10 8C 59 08 00 2B 2F 84 26 01 00 01 00 dB...Y.. +/.&....
> [0020] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .]...... ....+.H` [0030] 02 00 00 00 ....
> frsrpc_FrsSendCommPkt: struct frsrpc_FrsSendCommPkt
> in: struct frsrpc_FrsSendCommPkt
> req: struct frsrpc_FrsSendCommPktReq
> major : FRSRPC_COMM_PKT_MAJOR_0 (0)
> minor : FRSRPC_COMM_PKT_MINOR_8 (8)
> cs_id : 0x00000001 (1)
> memory_len : 0x00000180 (384)
> pkt_len : 0x00000178 (376)
> upk_len : 0x00000000 (0)
> ctr : *
> ctr: struct frsrpc_CommPktChunkCtr
> num_chunks : 0x00000009 (9)
> chunks: ARRAY(9)
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_BOP (0x1) data : union 
> frsrpc_CommPktChunkData(case 1) bop : 0x00000000 (0)
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_COMMAND (0x2) data : union 
> frsrpc_CommPktChunkData(case 2) command : FRSRPC_COMMAND_NEED_JOIN 
> (0x121)
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_TO (0x3)
> data : union frsrpc_CommPktChunkData(case 3)
> to: struct frsrpc_CommPktChunkGuidName guid : 
> 0b23079e-6c35-44f5-803f-3e252489ec29
> name : 'S2-W2K3R2'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_FROM (0x4) data : union 
> frsrpc_CommPktChunkData(case 4)
> from: struct frsrpc_CommPktChunkGuidName guid : 
> 5a38e8ea-be6f-4f63-a15e-d28a70fecffe
> name : 'S1-W2K3R2'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_REPLICA (0x5) data : union 
> frsrpc_CommPktChunkData(case 5)
> replica: struct frsrpc_CommPktChunkGuidName guid : 
> 0b23079e-6c35-44f5-803f-3e252489ec29
> name : 'DOMAIN SYSTEM VOLUME (SYSVOL SHARE)'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_CONNECTION (0x8) data : union 
> frsrpc_CommPktChunkData(case 8)
> connection: struct frsrpc_CommPktChunkGuidName guid : 
> 9d75a3bd-ee1e-4ee3-bafd-84ec61a914f9
> name : '042988D1-41FB-4D3A-9992-416414FF05A4'
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_JOIN_GUID (0x6) data : union 
> frsrpc_CommPktChunkData(case 6) join_guid : 
> 00000000-0000-0000-0000-000000000000
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_LAST_JOIN_TIME (0x12) data : union 
> frsrpc_CommPktChunkData(case 18) last_join_time : jeu. janv. 1 
> 01:00:00 1970 CET
> chunks: struct frsrpc_CommPktChunk
> type : FRSRPC_COMM_PKT_CHUNK_EOP (0x13) data : union 
> frsrpc_CommPktChunkData(case 19) bopend : 0xffffffff (4294967295) 
> data_name : 0x00000002 (2) data_handle : 0x00000000 (0) dump OK
>
>
> Can you explain ?
>
> Matthieu.
>
> --
> Matthieu Patou
> Samba Team        http://samba.org
> Private repo      http://git.samba.org/?p=mat/samba.git;a=summary
>
>


--
Matthieu Patou
Samba Team        http://samba.org
Private repo      http://git.samba.org/?p=mat/samba.git;a=summary

More information about the cifs-protocol mailing list