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:m...@samba.org] Sent: Wednesday, September 07, 2011 4:45 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@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-boun...@cifs.org > [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Matthieu Patou > Sent: Monday, August 29, 2011 10:52 AM > To: Interoperability Documentation Help; p...@tridgell.net; > cifs-proto...@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 _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol