Matthieu, I confirmed that the value in COMM_TO will be either a Netbois name (such as DC1) or a UNC path with a FQDN name plus a "\\" attached in the beginning (such as \\dc1.mydomain.com). We are in the middle of updating the document now.
Thanks! Hongwei -----Original Message----- From: Matthieu Patou [mailto:[email protected]] Sent: Saturday, September 17, 2011 2:45 PM To: Hongwei Sun Cc: [email protected]; [email protected]; [email protected]; MSSolve Case Email Subject: Re: [REG:111082958393266] RE: [cifs-protocol] Precision related to FRS documentation 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:[email protected]] > Sent: Wednesday, September 07, 2011 4:45 PM > To: Hongwei Sun > Cc: [email protected]; [email protected]; 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: [email protected] >> [mailto:[email protected]] On Behalf Of Matthieu Patou >> Sent: Monday, August 29, 2011 10:52 AM >> To: Interoperability Documentation Help; [email protected]; >> [email protected] >> 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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
