|
|
 |
|||
|
CDO Network Traffic
This section describes network traffic occuring during a CDO logon. Often it is important to understand what kind of traffic an application with CDO generates. I have written a trivial VB application (App/VbLogon) that provides 3 operations: CDO logon to a mailbox, a read operation of the 1st messages subject, and a logoff (see Figure below). I have used Network Monitor to capture associated network traffic. 
VbLogon application.
The code for the application is very simple and follows below. Dim objSession As MAPI.Session Private Sub Logon_Click() Set objSession = New MAPI.Session Dim strProfileInfo As String strProfileInfo = ServerTxt.Text & vbLf & AliasTxt.Text 'Logon objSession.Logon NewSession:=True, ProfileInfo:=strProfileInfo MsgBox "After Logon call" End Sub Private Sub Read_Click() Dim objInbox As MAPI.Folder Set objInbox = objSession.Inbox Dim objMessage As MAPI.Message Set objMessage = objInbox.Messages.Item(1) MsgBox objMessage.Subject Set objMessage = Nothing Set objInbox = Nothing End Sub Private Sub Logoff_Click() objSession.Logoff Set objSession = Nothing MsgBox "After Logoff call" End Sub I have conducted 2 experiments with 2 different mailboxes. One mailbox was pretty empty (it had only 3 messages in the Inbox). The other had 100 read and 1001 unread messages. My goal was to determine whether Inbox size or may be folder hierarchy has any impact on network traffic. In each experiment I have done a logon, then after a few seconds a read operation, and after another small delay a logoff. My experiments did not show any significant difference in network activity between small and large mailboxes, as well as slightly modified folder hierarchy. For example, introducing 2 additional Inbox subfolders or having a few new Inbox siblings does not seem to change volume of network activity. I am including 2 captures here for reference. The files are located in App\NetMonCaptures directory.
Let us examine the CdoTrafficBig.cap capture. I'll try analize individual frames where possible. The logon operation takes 79 frames. The first 11 frames of this (see Figure below) represent traffic on port 135 (RPC endpoint mapper) to the Exchange machine to determine the remote port number for Exchange Directory service. In my specific example illustrated on the figure the client port is 3317. Port 135 on Exchange system is depicted as epmap. Specifically, the first 3 frames establish a socket connection (3317-135), then the client in frame 4 attempts to bind to the endpoint mapper supplying its UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA (offset 0x56, 16 bytes). More information about endpoint mapper may be found in the following knowledge base article: http://support.microsoft.com/support/kb/articles/Q159/2/98.ASP. Frame 5 is an aknowledgement to a bind. Then the client in frame 6 asks for a port number of Exchange Directory service. Exchange Directory service in this particular case is identified by UUID F5CC5A18-4264-101A-8C59-08002B2F8426 (16 bytes at offset 0x73). Frame 7 contains the resulting port 1050 (0x041A), the data is at offset 0xBE (2 bytes). Frames 8-11 terminate the socket. 
The first 11 frames of CDO logon traffic.
Frames 12-50 represent a conversation with Exchange directory service happening on 2 new sockets. What appears to happen is that a socket 3318-1050 is connected and some data get through in frames 12-18. Then another socket is created in frames 19-21. This time it's an authenticated socket because I can see NTLM challenge-response data in frames 22-24 (frame 22 is an NTLM authentication request, frame 23 contains an embedded 8-byte challenge, frame 24 is a response to it). It appears that the conversation 3319-1050 is embedded in 3318-1050. Probably everything is happening in one client thread. Some directory hierarchy data is passed in frames 29 and 30. Frame 32 contains mailbox alias (=niko at offset 0xC6). Frame 36 from Exchange server carries full mailbox distinguished name (/o=Infowave/ou=Taz/cn=Recipients/cn=Niko at offset 0x010E) as well as MDB DN (offset 0x146, data: /o=Infowave/ou=Taz/cn=Configuration/cn=Servers/cn=TAZDEVIL/cn=Microsoft Private MDB). Frame 40 transmits RPC binding information (ncalrpc:TAZDEVIL, ncacn_ip_tcp:tazdevil.infowave.com, etc.). Frames 43-50 terminate both sockets. By frame 50 the client has received mailbox DN and RPC binding information from the directory service. 
A portion of traffic between a client and Exchange directory service.
Frames 51-61 is the same conversation with endpoint mapper as frames 1-11 to obtain port 1050. The remaining part of the logon process (frames 62-79) happens on 2 new sockets. The socket 3321-1050 is created (frames 62-64), followed by an RPC bind with the Directory service (frames 65-66), and an RPC call on it (nspi:NspiBind(..), frames 67, 68, and 78). The second socket 3322-1050 is created in frames 69-71, RPC bind happens in frames 72-74 (this time NTLM v1 authentication data are passed trhough), then an RPC call is made in frames 75-77, and 79. Frame 79 is the last frame in the logon process. Notice that both sockets stay open after frame 79. 
Network traffic finalizing the logon process.
I have used both Network Monitor and Ethereal traffic sniffers for my traffic analysis. I have found value in both. For example, Network Monitor provides more explanatory data for RPC frames. You can localize and drill down into individual data structure members because NetMon appears to recognize some of them. This is very valuable. Ethereal product is more generic, works on many platforms, and is free. It may be used with captures produced by other sniffers, which NetMon can't recognize. I also like its filtering capabilities. The read 1st subject operation is taking place in frames 80-113. Traffic in frames 80-90 is yet another new conversation with endpoint mapper, this time to determine the information store port 1061. The information store UUID is A4F1DB00-CA47-1067-B31F-00DD010662DA. It is passed along in frame 85 at offset 0x73. The result is passed back in frame 86 at offset 0xBE (data is 0x0425, decimal 1061). Frames 91-93 create a new socket 3326-1061. Frames 94-96 is an NTLM authenticated RPC bind. Then this socket is used to make 7 RPC calls in frames 97-113. Logoff operation takes place in frames 114-232. Here is what happens in detail: Frames 114-117. 2 more RPC calls on socket 3326-1061.
In summary, here is what happens in terms of frames and socket numbers: Logon: 79 frames, 6 new sockets opened (4 closed, 2 stay open till logoff). Conversation with Directory service only.
|
|