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

Sat Sep 17 13:44:32 MDT 2011

On 15/09/2011 15:15, Hongwei Sun wrote:
> 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.
So basically the COMM_TO can be either a UNC (ie. \\dc1.mydomain.com), a 
FQDN (ie. dc1.mydomain.com) or a netbios name (ie. DC1), is it right ?
If so let me know when the documentation will be updated in the mean 
time the issue is closed.

Matthieu.
>
> 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
>
>
>


-- 
Matthieu Patou
Samba Team
http://samba.org