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
