Hmmm...since this was probably a result of a Global Address
List query, what might the appropriate choice in the Decode As
Window?
- Phil
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