Wireshark-users: Re: [Wireshark-users] Please help decode DCERPC packets between W2K, a DC, and a
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
