Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Please help decode DCERPC packets between W2K, a DC, and a

From: "Schlesinger, Philip" <pschlesinger@xxxxxxxxxxx>
Date: Thu, 17 Aug 2006 16:29:29 -0700
Hmmm...since this was probably a result of a Global Address List query, what might the appropriate choice in the Decode As Window?
 
- Phil


From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of ronnie sahlberg
Sent: Thursday, August 17, 2006 4:16 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Please help decode DCERPC packets between W2K,a DC, and an Exchange Server

dcerpc is a transport for interfaces/protocols transported atop it.


due to the way dcerpc works   the information about exactly which protocol is transported atop it is only present inside the initial dcerpc BIND calls    that is sued to attach a specific application protocol to a dcerpc session.


unless wireshark has actually seen the initial bind call that occurs at the very beginning of the session    it is not possible to know what protocol is transported atop dcerpc and thus it can not be decoded.



If you KNOW it is exchange   you can manually force wireshark to decode this payload as a specific such protocol using DECODE AS.
If it is exchange    it is likely that the protocol transported is either MAPI or NSPI


note that since these two protocols are undocumented and very little interest for them exist in the wireshark community    wireshark will still not be able to do much more than tell you the name of that particular procedure   but nothing more.



wireshark knows however only the procedure name for procedures 0-9 for MAPI and not procedure 11.

procedure 11 for NAPI is called   NspiModProps    but wireshark can not decode the payload for it.





On 8/18/06, Schlesinger, Philip <pschlesinger@xxxxxxxxxxx> wrote:

Hi all.  We're trying to figure out why Outlook periodically freezes on the machines in our department (my company uses Exchange Server - either 2000 or 2003).  So I set up Wireshark to record data to two one-megabyte files in a ring - it has been running for days now. 

Today, I had a freeze-up, so I opened up a second Wireshark and peeked inside the newest log file.  My Outlook and Exchange appear to be just peachy keen one moment:

#3108
89.038216
Source <my IP>
Destination <exchange svr IP>
DCERPC Request: call_id:417 opnum: 11 ctx_id: 0

#3109
89.039143
Source <exchange svr IP>
Destination <my IP>
DCERPC Response: call_id:417 opnum: 11

And shortly thereafter:

#3145
90.803519
Source <my IP>
Destination <the company's domain controller>
DCERPC Request: call_id: 3 opnum: 12 ctx_id: 0
(note: I log into the company domain, but my computer is a member of a department domain, and that department domain trusts my company's domain)

#3171, #3238, #3371, #3447, and #3576 are all TCP Retransmissions of #3145

Finally, a TCP SYN command occurs (I've seen it in the past, but I set up too small of a log file size) occurs and everything seems to kick back into gear. 

Any ideas?

What's also weird is that on the call to the company domain controller includes a line in the DCE RPC Request description: "[No bind info for this interface Context ID - capture start too late?]" 

What does this mean?


_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users