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
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
