Learn how to use Network Monitor 3.0 for troubleshooting a remote scripting error in this tip originally published on WindowsNetworking.com.
In the previous article, Troubleshooting the mystery error -- Managing Windows networks using scripts, we began troubleshooting a mysterious error that occurred when we tried to remotely change the IP address on an XP machine using the ChangeIPAddress.vbs script we developed. The mysterious error that occurred was this:
SWbemObjectEx: The remote procedure call failed
In the previous article, I mentioned that I had contacted some scripting gurus concerning this error, and the best answer I received was that a hotfix had probably broken WMI functionality and the result was that this script worked remotely but generated an error.
But an astute reader contacted me afterward with the following comment:
"This isn't an error in any of the hotfixes in my opinion. Remember you are changing the IP address of XP2. The remote procedure call failed is because it lost the connection to the XP2 on the original IP address ( 172.16.11.43). Then it spends some time (about 1 minute) to look for XP2 on the new IP address (172.16.11.65) before it gives up."
Imagine you just telnet into a server as administrator and change the IP address of the server. Will you lose the connection? It will hang a while and this is the same. But changing the default gateway on the server will not interrupt the existing (telnet) connection (assuming you do this from the same subnet). If you try to change the default gateway setting from remote site, you should experience the same delay."
Good point! How can we test this explanation?
Using Network Monitor 3.0
Microsoft recently released a new version of Network Monitor, a packet-sniffing tool that is included as part of Microsoft Systems Management Server. Network Monitor 3.0 has several enhancements over the previous version of this tool, namely, the following:
- New, improved user interface that displays frames while they are being captured in real time
- Multiple simultaneous capture sessions and simultaneous capture on multiple network adapters
- The ability to display network "conversations," i.e., specific protocol sessions
- Support for Vista, Windows XP and Windows Server 2003 including both 32bit and 64bit platforms.
- New filtering panel that lets you manually specify filters
For more information about Network Monitor 3.0, see Paul Long's TechNet blog.
Here's my plan then. I'm going to use NM3 to capture a network trace from the machine on which I'm running the ChangeIPAddress.vbs script. My test setup for this is as follows:
Administrator workstation
Name: test124.test.com
IP address: 172.16.11.124 (static)
Target machine
Name: test125.test.com
IP address: 172.16.11.125 (static)
Domain controller
Name: dc181.test.com
IP address: 172.16.11.181
But before I try to run ChangeIPAddress.vbs on test124 in order to change the IP address of test125, let's take a quick look at NM3.
When you start NM3, it looks like this (Figure 1):
Figure 1: Network Monitor 3.0 opening screen (Click the image for a larger view)
Before we go any further, let's select the Enable Conversations checkbox so we can view each type of protocol session that occurs during our trace.
Now click Create A New Capture Tab. This opens a new tab named Capture1 that we can use to create our network trace (Figure 2):
Figure 2: Opening a new capture tab (Click the image for a larger view)
Now let's test NM3 with something simple. We'll click the Play button to start a capture, and then from machine test124 we'll open a command prompt and type ping 172.16.11.125 -- we're pinging test125 from test124. The result is this (Figure 3):
Figure 3: Trace of pinging 172.16.11.125 (Click the image for a larger view)
This is just what we expect: two ARP packets (an ARP request followed by an ARP response) and then a series of ICMP packets (Echo Request messages followed by Echo Reply messages). If you know basic TCP/IP networking, this should be easy to understand.
Let's look at the "conversations" that occurred. Expand the My Traffic node to display these, shown in Figure 4:
Figure 4: Showing conversations (Click the image for a larger view)
Note that two conversations occurred: ARP and IPv4 (ICMP). Again, this should be pretty obvious if you know basic TCP/IP networking.
Let's now select the ARP Request packet and look inside it (Figure 5):
Figure 5: Examining a packet (Click the image for a larger view)
Now that we've had a quick introduction to NM3 (there's lots more!) let's try using it to troubleshoot our mystery error.
Capturing Traces
I'll start by rebooting both workstations to clear any caches (ARP, DNS, etc.) and then I'll open a command prompt on test124 and type ChangeIPAddress.vbs 172.16.11.144 in order to change the IP address of test125 from 172.16.11.125 to 172.16.11.144. (I've hard-coded the target computer as "test125" within this script.) Here's the result (Figure 6):
Figure 6: Result of running ChangeIPAddress.vbs 172.16.11.144 (Click the image for a larger view)
 |
| Read other 'Managing Windows networks using scripts' tips |
Part 1: The basics
Part 2: Cleaning up
Part 3: Understanding WMI
Part 4: Using Win32_NetworkAdapterConfiguration
Part 5: Getting over the hump
Part 6: Remote scripting first steps
Part 7: Troubleshooting the mystery error
Part 8: Troubleshooting remote scripting with Network Monitor 3.0
Part 9: Understand remote scripting
Part 10: Two tricks using WMI scripts
Part 11: More remote scripting tips
Part 12: Properties of WMI class
Part 13: A return-all-values script
Part 14: WMI scripting resources |
|
|
|
|
Here's an overview of what happened: The capture lasted almost 90 seconds in total, and there were 274 frames captured. The error message appeared around frame 241, and the command prompt returned at frame 274. (I know this because I watched the command output while the trace was being captured.) That's a lot of traffic to analyze! Looking at Figure 6 above, we can at least make a start at analyzing it:
- Frames 3-4 show the name TEST125 being resolved into IP address 172.16.11.125 using DNS.
- Frames 5-6 show the IP address 172.16.11.125 being resolved into a MAC address using ARP.
- Frames 7-9 show a three-way TCP handshake (SYN, SYN/ACK, ACK) occurring between test124 and test125.
- Frames 10-11 show an RPC binding being established between the two machines.
- Frames 12-13 show DCOM being used over RCP (WMI uses DCOM to handle remote calls).
…and so on.
Obviously we can't display all 274 frames in the figure, so I copied the Frame Summary information to a text file. (I also saved the capture as a .cap file). You can see the Frame Summary that resulted when we ran ChangeIPAddress.vbs here.
That's pretty overwhelming, isn't it? How can one begin to understand what this capture is telling you?
Well, when you're troubleshooting, a good place to begin is with what you know, not what you don't know. And we know that the other script (ChangeGateway.vbs) that we developed in our previous article worked without generating any error messages. So before we look further at ChangeIPAddress.txt, let's reboot our workstations and do another capture, this time showing the result of running the command ChangeGateway.vbs 172.16.11.2 1 on test124 in order to change the default gateway of test125 from 172.16.11.1 to 172.16.11.2 (and specifying the metric as 1). Here's what this second capture looks like (Figure 7):
Figure 7: Result of running ChangeGateway.vbs 172.16.11.2 1 (Click the image for a larger view)
This time there are only 217 frames to analyze (!) as you can see in the Frame Summary.
Analysis of Capture for ChangeGateway.vbs
Let's try and analyze this second capture (the one that worked without generating an error) by breaking the Frame Summary down piece by piece. Here it goes:
| 1 0.000000 NetmonFilter NetmonFilter: Updated Capture Filter: None
2 0.000000 NetworkInfo NetworkInfo: Network info for TEST124, Network Adapter Count = 1 |
This is just NM3 header stuff -- ignore it.
| 3 0.000000 {DNS:3, UDP:2, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x4275, QUERY (Standard query), Query for 124.11.16.172.in-addr.arpa of type SOA on class Internet
4 1.281250 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: Request, 172.16.11.181 asks for 172.16.11.1
5 1.890625 {DNS:6, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0xEB6E, QUERY (Standard query), Query for test125.test.local of type Host Addr on class Internet
6 1.890625 {DNS:6, UDP:5, IPv4:1} dc181.test.local 172.16.11.124 DNS DNS: QueryId = 0xEB6E, QUERY (Standard query), Response - Success
7 1.906250 {ARP:7} 172.16.11.124 172.16.11.125 ARP ARP: Request, 172.16.11.124 asks for 172.16.11.125
8 1.906250 {ARP:7} 172.16.11.125 172.16.11.124 ARP ARP: Response, 172.16.11.125 at 00-11-D8-E3-EC-84 |
Here is name and address resolution stuff (DNS and ARP):
| 9 1.906250 {TCP:9, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=.S......, SrcPort=1069, DstPort=DCE endpoint resolution(135), Len=0, Seq=1441244938, Ack=0, Win=65535 (scale factor 0) = 65535
10 1.906250 {TCP:9, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: Flags=.S..A..., SrcPort=DCE endpoint resolution(135), DstPort=1069, Len=0, Seq=871910569, Ack=1441244939, Win=65535 (scale factor 0) = 65535
11 1.906250 {TCP:9, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1069, DstPort=DCE endpoint resolution(135), Len=0, Seq=1441244939, Ack=871910570, Win=65535 (scale factor 0) = 65535 |
Test124 just established a TCP connection with test125.
| 12 1.906250 {MSRPC:10, TCP:9, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Bind: UUID{99FCFEC4-5260-101B-BBCB-00AA0021347A} DCOM-IObjectExporter Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
13 1.906250 {MSRPC:10, TCP:9, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x32E9 Xmit=0x16D0 Recv=0x16D0
14 1.906250 {MSRPC:10, TCP:9, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
15 1.906250 {MSRPC:10, TCP:9, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM |
Test124 establishes an RCP binding with test125 and invokes DCOM.
TIP: If you're having trouble following the RPC portion of this trace, see KB 159258 for help.
| 16 1.921875 {TCP:11, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=.S......, SrcPort=1070, DstPort=DCE endpoint resolution(135), Len=0, Seq=3003512395, Ack=0, Win=65535 (scale factor 0) = 65535
17 1.921875 {TCP:11, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: Flags=.S..A..., SrcPort=DCE endpoint resolution(135), DstPort=1070, Len=0, Seq=4088700167, Ack=3003512396, Win=65535 (scale factor 0) = 65535
18 1.921875 {TCP:11, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1070, DstPort=DCE endpoint resolution(135), Len=0, Seq=3003512396, Ack=4088700168, Win=65535 (scale factor 0) = 65535 |
Here's another TCP three-way handshake between the machines.
| 19 1.921875 {UDP:12, IPv4:1} 172.16.11.124 dc181.test.local KerberosV5 KerberosV5: TGS Request Realm: TEST.LOCAL Sname: RPCSS/test125.test.local
20 1.921875 {UDP:12, IPv4:1} dc181.test.local 172.16.11.124 KerberosV5 KerberosV5: TGS Response Cname: Administrator |
Kerberos authentication (the machines are both domain-joined).
| 21 1.921875 {MSRPC:13, TCP:11, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Bind: UUID{000001A0-0000-0000-C000-000000000046} DCOM-IRemoteSCMActivator Call=0x2 Assoc Grp=0x32E9 Xmit=0x16D0 Recv=0x16D0
22 1.921875 {ARP:14} 172.16.11.181 172.16.11.125 ARP ARP: Request, 172.16.11.181 asks for 172.16.11.125
23 1.921875 {MSRPC:13, TCP:11, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Bind Ack: Call=0x2 Assoc Grp=0x32E9 Xmit=0x16D0 Recv=0x16D0
24 1.921875 {MSRPC:13, TCP:11, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{000001A0-0000-0000-C000-000000000046} DCOM-IRemoteSCMActivator Call=0x2
25 1.921875 {MSRPC:13, TCP:11, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x32E9 Xmit=0x16D0 Recv=0x16D0
26 1.921875 {MSRPC:13, TCP:11, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
27 1.937500 {MSRPC:13, TCP:11, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM |
There's more RPC and DCOM. I think "Alter Cont" indicates alternate context being used, but I'm actually not sure. Still, everything must be OK since the script worked without generating any errors.
| 28 1.937500 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=.S......, SrcPort=1072, DstPort=1117, Len=0, Seq=3011418470, Ack=0, Win=65535 (scale factor 0) = 65535
29 1.937500 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: Flags=.S..A..., SrcPort=1117, DstPort=1072, Len=0, Seq=554832695, Ack=3011418471, Win=65535 (scale factor 0) = 65535
30 1.937500 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1072, DstPort=1117, Len=0, Seq=3011418471, Ack=554832696, Win=65535 (scale factor 0) = 65535 |
Here we see another TCP handshake.
| 31 1.937500 {UDP:16, IPv4:1} 172.16.11.124 dc181.test.local KerberosV5 KerberosV5: TGS Request Realm: TEST.LOCAL Sname: TEST125$
32 1.937500 {UDP:16, IPv4:1} dc181.test.local 172.16.11.124 KerberosV5 KerberosV5: TGS Response Cname: Administrator |
… And more Kerberos stuff.
| 33 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Bind: UUID{00000143-0000-0000-C000-000000000046} DCOM-IRemUnknown2 Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
34 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
35 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{00000143-0000-0000-C000-000000000046} DCOM-IRemUnknown2 Call=0x1
36 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x1 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
37 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
38 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
39 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{D4781CD6-E5D3-44DF-AD94-930EFE48A887} WMI-IWbemLoginClientID Call=0x2
40 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
41 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
42 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
43 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{F309AD18-D86A-11D0-A075-00C04FB68820} WMI-IWbemLevel1Login Call=0x3
44 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x3 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
45 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
46 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
47 1.937500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
48 1.937500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
49 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{9556DC99-828C-11CF-A37E-00AA003240C7} WMI-IWbemServices Call=0x5
50 1.953125 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x5 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
51 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
52 1.953125 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
53 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
54 1.953125 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
55 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{1C1C45EE-4395-11D2-B60B-00104B703EFD} WMI-IWbemFetchSmartEnum Call=0x7
56 1.953125 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x7 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
57 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
58 1.953125 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
59 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{423EC01E-2E35-11D2-B604-00104B703EFD} WMI-IWbemWCOSmartEnum Call=0x8
60 1.953125 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Alter Cont Resp: Call=0x8 Assoc Grp=0x333D Xmit=0x16D0 Recv=0x16D0
61 1.953125 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
62 2.015625 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM |
There's lots of RPC/DCOM stuff in there. Looks cryptic, doesn't it? But if you look carefully you'll see some WMI stuff happening i.e. WMI-IWbemLoginClientID, WMI-IWbemLevel1Login, WMI-IWbemServices, WMI-IWbemFetchSmartEnum, and so on. Searching MSDN tells us more about what's happening here. For example, the Microsoft Developer Network library tells us that "The IWbemServices interface is used by clients and providers to access WMI services" so it looks like all these I-thingies are WMI interfaces (APIs) that are being called on the remote machine (using DCOM) by the workstation we're running our script from. And some of these interfaces actually seem to be undocumented, so we won't worry too much about trying to understand them.
From here on things get kind of dense. First there's a bunch more TCP stuff with RPC "Continued Response" packets that seem to indicate connections made earlier are being used for some purpose. I'm going to skip a few frames from this next portion of the trace:
| 63 2.015625 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: [Continuation to #62]Flags=....A..., SrcPort=1117, DstPort=1072, Len=1460, Seq=554835972 - 554837432, Ack=3011421991, Win=65061 (scale factor 0) = 65061
64 2.015625 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1072, DstPort=1117, Len=0, Seq=3011421991, Ack=554837432, Win=65535 (scale factor 0) = 65535
65 2.015625 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: [Continuation to #62]Flags=....A..., SrcPort=1117, DstPort=1072, Len=1460, Seq=554837432 - 554838892, Ack=3011421991, Win=65061 (scale factor 0) = 65061
66 2.015625 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1072, DstPort=1117, Len=0, Seq=3011421991, Ack=554838892, Win=65535 (scale factor 0) = 65535
67 2.015625 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: [Continuation to #62]Flags=...PA..., SrcPort=1117, DstPort=1072, Len=1449, Seq=554838892 - 554840341, Ack=3011421991, Win=65061 (scale factor 0) = 65061
68 2.015625 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Continued Response: WMI-IWbemWCOSmartEnum Call=0x8 Context=0x5 Hint=0x198C Cancels=0x0
.
.
.
155 2.031250 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 MSRPC MSRPC: c/o Continued Response: WMI-IWbemServices Call=0x9 Context=0x3 Hint=0x904 Cancels=0x0
156 2.031250 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: [Continuation to #155]Flags=...PA..., SrcPort=1117, DstPort=1072, Len=929, Seq=554924260 - 554925189, Ack=3011422236, Win=64816 (scale factor 0) = 64816
157 2.031250 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1072, DstPort=1117, Len=0, Seq=3011422236, Ack=554925189, Win=65535 (scale factor 0) = 65535
158 2.031250 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
159 2.031250 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: [Continuation to #158]Flags=...PA..., SrcPort=1072, DstPort=1117, Len=1, Seq=3011423696 - 3011423697, Ack=554925189, Win=65535 (scale factor 0) = 65535
160 2.031250 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: Flags=....A..., SrcPort=1117, DstPort=1072, Len=0, Seq=554925189, Ack=3011423697, Win=65535 (scale factor 0) = 65535 |
Only two seconds have elapsed so far. Now there's a bunch of DCOM stuff followed by TCP connections terminating using FIN/ACKs, so I guess the script has probably done its job and is cleaning up now:
| 161 2.062500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
162 2.062500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
163 2.062500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
164 2.062500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
165 2.062500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
166 2.062500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
167 2.062500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
168 2.062500 {MSRPC:17, TCP:15, IPv4:8} 172.16.11.124 test125.test.local DCOM DCOM
169 2.062500 {MSRPC:17, TCP:15, IPv4:8} test125.test.local 172.16.11.124 DCOM DCOM
170 2.078125 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=F...A..., SrcPort=1072, DstPort=1117, Len=0, Seq=3011424421, Ack=554926046, Win=64678 (scale factor 0) = 64678
171 2.078125 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: Flags=....A..., SrcPort=1117, DstPort=1072, Len=0, Seq=554926046, Ack=3011424422, Win=64811 (scale factor 0) = 64811
172 2.078125 {TCP:15, IPv4:8} test125.test.local 172.16.11.124 TCP TCP: Flags=F...A..., SrcPort=1117, DstPort=1072, Len=0, Seq=554926046, Ack=3011424422, Win=64811 (scale factor 0) = 64811
173 2.078125 {TCP:15, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1072, DstPort=1117, Len=0, Seq=3011424422, Ack=554926047, Win=64678 (scale factor 0) = 64678
174 2.093750 {TCP:9, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1069, DstPort=DCE endpoint resolution(135), Len=0, Seq=1441245035, Ack=871910766, Win=65339 (scale factor 0) = 65339
175 2.093750 {TCP:11, IPv4:8} 172.16.11.124 test125.test.local TCP TCP: Flags=....A..., SrcPort=1070, DstPort=DCE endpoint resolution(135), Len=0, Seq=3003514721, Ack=4088701653, Win=65535 (scale factor 0) = 65535
176 2.546875 {TCP:18, IPv4:1} 172.16.11.124 dc181.test.local TCP TCP: Flags=.S......, SrcPort=1074, DstPort=DCE endpoint resolution(135), Len=0, Seq=4283854964, Ack=0, Win=65535 (scale factor 0) = 65535
177 2.546875 {TCP:18, IPv4:1} dc181.test.local 172.16.11.124 TCP TCP: Flags=.S..A..., SrcPort=DCE endpoint resolution(135), DstPort=1074, Len=0, Seq=2447011944, Ack=4283854965, Win=16384 (scale factor 0) = 16384
178 2.546875 {TCP:18, IPv4:1} 172.16.11.124 dc181.test.local TCP TCP: Flags=....A..., SrcPort=1074, DstPort=DCE endpoint resolution(135), Len=0, Seq=4283854965, Ack=2447011945, Win=65535 (scale factor 0) = 65535 |
Now there's some DNS and LDAP stuff going on between test124 and the domain controller. I'm not sure why this is happening, but I'll skip some of these frames as there's a lot of them:
| 179 2.546875 {MSRPC:19, TCP:18, IPv4:1} 172.16.11.124 dc181.test.local MSRPC MSRPC: c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} Endpoint Mapper Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
180 2.546875 {MSRPC:19, TCP:18, IPv4:1} dc181.test.local 172.16.11.124 MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x7DAD Xmit=0x16D0 Recv=0x16D0
181 2.546875 {MSRPC:19, TCP:18, IPv4:1} 172.16.11.124 dc181.test.local EPM EPM: Request: ept_map: NDR, Tracking Server Service v1.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)]
182 2.546875 {MSRPC:19, TCP:18, IPv4:1} dc181.test.local 172.16.11.124 EPM EPM: Response: ept_map: 0x16C9A0D6 - EP_S_NOT_REGISTERED
183 2.546875 {DNS:21, UDP:20, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x896A, QUERY (Standard query), Query for _ldap._tcp.Default-First-Site._sites.dc._msdcs.test.local of type SRV on class Internet
184 2.546875 {DNS:21, UDP:20, IPv4:1} dc181.test.local 172.16.11.124 DNS DNS: QueryId = 0x896A, QUERY (Standard query), Response - Success
185 2.546875 {LDAP:23, UDP:22, IPv4:1} 172.16.11.124 dc181.test.local LDAP LDAP: Search Request, MessageID:4, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
186 2.546875 {LDAP:23, UDP:22, IPv4:1} dc181.test.local 172.16.11.124 LDAP LDAP: Search Result Entry, MessageID:4, Status: Success
.
.
.
212 6.546875 {DNS:32, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x266D, QUERY (Standard query), Query for download.windowsupdate.com of type Host Addr on class Internet
213 6.546875 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: Request, 172.16.11.181 asks for 172.16.11.1
214 7.546875 {DNS:32, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x266D, QUERY (Standard query), Query for download.windowsupdate.com of type Host Addr on class Internet
215 8.546875 {DNS:32, UDP:5, IPv4:1} 172.16.11.124 dc181.test.local DNS DNS: QueryId = 0x266D, QUERY (Standard query), Query for download.windowsupdate.com of type Host Addr on class Internet
216 9.281250 {ARP:4} 172.16.11.181 172.16.11.1 ARP ARP: Request, 172.16.11.181 asks for 172.16.11.1 |
At this point the script has already ended so I terminated the capture.
Analysis of Capture for ChangeIPAddress.vbs
We now have a bit of an idea of what a capture of a successful remote script looks like:
- Some DNS and ARP stuff
- Establishment of TCP sessions using 3-way handshake
- RPC bindings and DCOM
- More TCP handshaking
- Kerberos stuff (machines are in a domain)
- More RPC/DCOM stuff
- More TCP handshakes, more Kerberos, lots more RPC/DCOM combined with TCP communications
- MORE DCOM followed by tearing down the TCP sessions established earlier
And the whole thing took just over 2 seconds.
Now let's look at our capture for ChangeIPAddress.vbs (the script that generates an RPC error when we run it remotely) and see how it differs from the above.
| 1 0.000000 NetmonFilter NetmonFilter: Updated Capture Filter: None
2 0.000000 NetworkInfo NetworkInfo: Network info for TEST124, Network Adapter Count = 1 |
This is just some Netmon stuff.
| 3 0.000000 {DNS:3, UDP:2, IPv4:1} test124.test.local dc181.test.local DNS DNS: QueryId = 0x7869, QUERY (Standard query), Query for test125.test.local of type Host Addr on class Internet
4 0.000000 {DNS:3, UDP:2, IPv4:1} dc181.test.local test124.test.local DNS DNS: QueryId = 0x7869, QUERY (Standard query), Response - Success
5 0.015625 {ARP:4} 172.16.11.124 172.16.11.125 ARP ARP: Request, 172.16.11.124 asks for 172.16.11.125
6 0.015625 {ARP:4} 172.16.11.125 172.16.11.124 ARP ARP: Response, 172.16.11.125 at 00-11-D8-E3-EC-84
7 0.015625 {TCP:6, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=.S......, SrcPort=1063, DstPort=DCE endpoint resolution(135), Len=0, Seq=539163285, Ack=0, Win=65535 (scale factor 0) = 65535
8 0.015625 {TCP:6, IPv4:5} test125.test.local test124.test.local TCP TCP: Flags=.S..A..., SrcPort=DCE endpoint resolution(135), DstPort=1063, Len=0, Seq=981335265, Ack=539163286, Win=65535 (scale factor 0) = 65535
9 0.015625 {TCP:6, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1063, DstPort=DCE endpoint resolution(135), Len=0, Seq=539163286, Ack=981335266, Win=65535 (scale factor 0) = 65535 |
This is an ARP, a DNS, then a TCP handshake -- the same as before.
| 10 0.015625 {MSRPC:7, TCP:6, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Bind: UUID{99FCFEC4-5260-101B-BBCB-00AA0021347A} DCOM-IObjectExporter Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
11 0.015625 {MSRPC:7, TCP:6, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x32EA Xmit=0x16D0 Recv=0x16D0
12 0.031250 {MSRPC:7, TCP:6, IPv4:5} test124.test.local test125.test.local DCOM DCOM
13 0.031250 {MSRPC:7, TCP:6, IPv4:5} test125.test.local test124.test.local DCOM DCOM
14 0.078125 {TCP:8, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=.S......, SrcPort=1064, DstPort=DCE endpoint resolution(135), Len=0, Seq=1367843928, Ack=0, Win=65535 (scale factor 0) = 65535
15 0.078125 {TCP:8, IPv4:5} test125.test.local test124.test.local TCP TCP: Flags=.S..A..., SrcPort=DCE endpoint resolution(135), DstPort=1064, Len=0, Seq=3625279350, Ack=1367843929, Win=65535 (scale factor 0) = 65535
16 0.078125 {TCP:8, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1064, DstPort=DCE endpoint resolution(135), Len=0, Seq=1367843929, Ack=3625279351, Win=65535 (scale factor 0) = 65535
17 0.078125 {UDP:9, IPv4:1} test124.test.local dc181.test.local KerberosV5 KerberosV5: TGS Request Realm: TEST.LOCAL Sname: RPCSS/test125.test.local
18 0.078125 {UDP:9, IPv4:1} dc181.test.local test124.test.local KerberosV5 KerberosV5: TGS Response Cname: Administrator |
RPC, then DCOM, then another TCP handshake, then some Kerberos stuff. It looks the same as before.
| 19 0.078125 {MSRPC:10, TCP:8, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Bind: UUID{000001A0-0000-0000-C000-000000000046} DCOM-IRemoteSCMActivator Call=0x2 Assoc Grp=0x32EA Xmit=0x16D0 Recv=0x16D0
20 0.093750 {ARP:11} 172.16.11.125 172.16.11.181 ARP ARP: Request, 172.16.11.125 asks for 172.16.11.181
21 0.093750 {MSRPC:10, TCP:8, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Bind Ack: Call=0x2 Assoc Grp=0x32EA Xmit=0x16D0 Recv=0x16D0
22 0.093750 {MSRPC:10, TCP:8, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{000001A0-0000-0000-C000-000000000046} DCOM-IRemoteSCMActivator Call=0x2
23 0.093750 {MSRPC:10, TCP:8, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x32EA Xmit=0x16D0 Recv=0x16D0
24 0.093750 {MSRPC:10, TCP:8, IPv4:5} test124.test.local test125.test.local DCOM DCOM
25 0.093750 {MSRPC:10, TCP:8, IPv4:5} test125.test.local test124.test.local DCOM DCOM
26 0.093750 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=.S......, SrcPort=1066, DstPort=1117, Len=0, Seq=1180773456, Ack=0, Win=65535 (scale factor 0) = 65535
27 0.093750 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: Flags=.S..A..., SrcPort=1117, DstPort=1066, Len=0, Seq=539972629, Ack=1180773457, Win=65535 (scale factor 0) = 65535
28 0.093750 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1066, DstPort=1117, Len=0, Seq=1180773457, Ack=539972630, Win=65535 (scale factor 0) = 65535
29 0.093750 {UDP:13, IPv4:1} test124.test.local dc181.test.local KerberosV5 KerberosV5: TGS Request Realm: TEST.LOCAL Sname: TEST125$
30 0.109375 {UDP:13, IPv4:1} dc181.test.local test124.test.local KerberosV5 KerberosV5: TGS Response Cname: Administrator |
We see the same pattern.
| 31 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Bind: UUID{00000143-0000-0000-C000-000000000046} DCOM-IRemUnknown2 Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
32 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Bind Ack: Call=0x1 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
33 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{00000143-0000-0000-C000-000000000046} DCOM-IRemUnknown2 Call=0x1
34 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x1 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
35 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
36 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
37 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{D4781CD6-E5D3-44DF-AD94-930EFE48A887} WMI-IWbemLoginClientID Call=0x2
38 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
39 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
40 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
41 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{F309AD18-D86A-11D0-A075-00C04FB68820} WMI-IWbemLevel1Login Call=0x3
42 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x3 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
43 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
44 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
45 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM
COM
46 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
47 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{9556DC99-828C-11CF-A37E-00AA003240C7} WMI-IWbemServices Call=0x5
48 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x5 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
49 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
50 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
51 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
52 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
53 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{1C1C45EE-4395-11D2-B60B-00104B703EFD} WMI-IWbemFetchSmartEnum Call=0x7 54 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x7 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
55 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
56 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
57 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local MSRPC MSRPC: c/o Alter Cont: UUID{423EC01E-2E35-11D2-B604-00104B703EFD} WMI-IWbemWCOSmartEnum Call=0x8
58 0.109375 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Alter Cont Resp: Call=0x8 Assoc Grp=0x333E Xmit=0x16D0 Recv=0x16D0
59 0.109375 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM |
Then a whole bunch of RPC/DCOM stuff, just like the other trace.
| 60 0.187500 {TCP:6, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1063, DstPort=DCE endpoint resolution(135), Len=0, Seq=539163382, Ack=981335462, Win=65339 (scale factor 0) = 65339
61 0.187500 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local DCOM DCOM
62 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #61]Flags=....A..., SrcPort=1117, DstPort=1066, Len=1460, Seq=539975906 - 539977366, Ack=1180776977, Win=65061 (scale factor 0) = 65061
63 0.187500 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1066, DstPort=1117, Len=0, Seq=1180776977, Ack=539977366, Win=65535 (scale factor 0) = 65535
64 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #61]Flags=....A..., SrcPort=1117, DstPort=1066, Len=1460, Seq=539977366 - 539978826, Ack=1180776977, Win=65061 (scale factor 0) = 65061
65 0.187500 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1066, DstPort=1117, Len=0, Seq=1180776977, Ack=539978826, Win=65535 (scale factor 0) = 65535
66 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #61]Flags=...PA..., SrcPort=1117, DstPort=1066, Len=1449, Seq=539978826 - 539980275, Ack=1180776977, Win=65061 (scale factor 0) = 65061
67 0.187500 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Continued Response: WMI-IWbemWCOSmartEnum Call=0x8 Context=0x5 Hint=0x198C Cancels=0x0
.
.
.
148 0.187500 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Continued Response: WMI-IWbemServices Call=0x9 Context=0x3 Hint=0x1F84 Cancels=0x0
149 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #148]Flags=....A..., SrcPort=1117, DstPort=1066, Len=1460, Seq=540058365 - 540059825, Ack=1180777222, Win=64816 (scale factor 0) = 64816
150 0.187500 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1066, DstPort=1117, Len=0, Seq=1180777222, Ack=540059825, Win=65535 (scale factor 0) = 65535
151 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #148]Flags=....A..., SrcPort=1117, DstPort=1066, Len=1460, Seq=540059825 - 540061285, Ack=1180777222, Win=64816 (scale factor 0) = 64816
152 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #148]Flags=...PA..., SrcPort=1117, DstPort=1066, Len=1449, Seq=540061285 - 540062734, Ack=1180777222, Win=64816 (scale factor 0) = 64816
153 0.187500 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1066, DstPort=1117, Len=0, Seq=1180777222, Ack=540062734, Win=65535 (scale factor 0) = 65535
154 0.187500 {MSRPC:14, TCP:12, IPv4:5} test125.test.local test124.test.local MSRPC MSRPC: c/o Continued Response: WMI-IWbemServices Call=0x9 Context=0x3 Hint=0x904 Cancels=0x0
155 0.187500 {TCP:12, IPv4:5} test125.test.local test124.test.local TCP TCP: [Continuation to #154]Flags=...PA..., SrcPort=1117, DstPort=1066, Len=929, Seq=540064194 - 540065123, Ack=1180777222, Win=64816 (scale factor 0) = 64816
156 0.187500 {TCP:12, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1066, DstPort=1117, Len=0, Seq=1180777222, Ack=540065123, Win=65535 (scale factor 0) = 65535
157 0.187500 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM |
Here's RPC together with TCP. You can see the WMI interface calls happening.
| 158 0.218750 {ARP:15} 172.16.11.144 172.16.11.144 ARP ARP: Request, 172.16.11.144 asks for 172.16.11.144 |
Uh-oh, what's this? The script has successfully changed the IP address of the target machine (test125) from 172.16.11.125 to 172.16.11.144, so why is the target machine using ARP to try and resolve its own IP address into a MAC address? This is an example of gratuitous ARP, which happens when a node makes an ARP request for its own IP address. Why does the target machine do this? To make sure it's new IP address 172.16.11.144 isn't being used by any other node on the network. If it issues several ARP requests and no ARP response is received, it decides that its new address is unique to the network and the address can be kept. But if another node issues an ARP response to this request, the first node assumes there is an address conflict on the network and it disables its IP address (assigns it to 0.0.0.0).
TIP: See Address Resolution Protocol (ARP) Chapter 3 of Microsoft® Windows® 2000 TCP/IP Protocols and Services Technical Reference by Thomas Lee and Joseph Davies if you want to learn more about gratuitous ARP.
At this point things seem to fall apart -- you can tell this by the fact that the time interval between packets is increasing significantly. What seems to be happening next is that the source node (test124) keeps trying to acknowledge TCP with the target but isn't getting anywhere:
| 159 0.296875 {TCP:8, IPv4:5} test124.test.local test125.test.local TCP TCP: Flags=....A..., SrcPort=1064, DstPort=DCE endpoint resolution(135), Len=0, Seq=1367846254, Ack=3625280836, Win=65535 (scale factor 0) = 65535
160 0.437500 {ARP:15} 172.16.11.144 172.16.11.144 ARP ARP: Request, 172.16.11.144 asks for 172.16.11.144
161 0.515625 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
162 1.062500 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
163 1.437500 {ARP:15} 172.16.11.144 172.16.11.144 ARP ARP: Request, 172.16.11.144 asks for 172.16.11.144
164 2.265625 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM
165 2.453125 {ARP:15} 172.16.11.144 172.16.11.144 ARP ARP: Request, 172.16.11.144 asks for 172.16.11.144
166 3.437500 {ARP:15} 172.16.11.144 172.16.11.144 ARP ARP: Request, 172.16.11.144 asks for 172.16.11.144
167 4.437500 {ARP:15} 172.16.11.144 172.16.11.144 ARP ARP: Request, 172.16.11.144 asks for 172.16.11.144
168 4.671875 {MSRPC:14, TCP:12, IPv4:5} test124.test.local test125.test.local DCOM DCOM |
Let's look at packet 159 above more closely using NM3 (Figure 8):
Figure 8: TCP connection problems (Click the image for a larger view)
Note from this figure that the source machine (test124) still thinks the destination machine has IP address 172.16.11.125, and it keeps trying to ACK with test125 to maintain the TCP connection established earlier.
Now let's look at frame 161 (Figure 9):
Figure 9: RPC/DCOM problems (Click the image for a larger view)
Note that the RPC binding established earlier by the source machine (test124) with the target machine (test125) is trying to invoke DCOM to call the EnableStatic Method of the Win32_NetworkAdapterConfiguration class. (To see this, look at the right side of the Hex Details pane where you can see the hex payload of the RPC packet displayed in UNICODE text.) But in trying to invoke DCOM, the source machine still thinks the destination address of the target machine is 172.16.11.125 (see the Frame Details pane in the figure).
So it looks like the reader was right!
The rest of the ChangeIPAddress.vbs capture is interesting to try and analyze, but it looks like we've identified the reason our remote script doesn't run properly. Well, it does work of course if we use the On Error Resume Next workaround that we mentioned in the previous article.
About the author:
Mitch Tulloch is a writer, trainer and consultant specializing in Windows server operating systems, IIS administration, network troubleshooting, and security. He is the author of 15 books including the
Microsoft Encyclopedia of Networking (Microsoft Press), the
Microsoft Encyclopedia of Security (Microsoft Press),
Windows Server Hacks (O'Reilly),
Windows Server 2003 in a Nutshell (O'Reilly),
Windows 2000 Administration in a Nutshell (O'Reilly), and
IIS 6 Administration (Osborne/McGraw-Hill). Mitch is based in Winnipeg, Canada, and you can find more information about his books at his website:
www.mtit.com.
WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.
