XP Name Resolution and ARP

I decided to capture some packets with Wireshark to observe an ARP broadcast and reply.
Prior to capturing the data, I went to command line and ran arp -d, nbtstat -R and an ipconfig /flushdns.
 Here is a portion of the ARP request:

Frame 18 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: Usi_88:ed:b3 (00:1e:37:88:ed:b3), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (0x0001)
    Sender MAC address: Usi_88:ed:b3 (00:1e:37:88:ed:b3)
    Sender IP address: 172.16.3.141 (172.16.3.141)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 172.16.3.140 (172.16.3.140)

No.     Time            Source                Destination           Protocol Info
     19 08:33:44.527556 Foxconn_db:1c:a3      Usi_88:ed:b3          ARP      172.16.3.140 is at 00:15:58:db:1c:a3

Frame 19 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Foxconn_db:1c:a3 (00:15:58:db:1c:a3), Dst: Usi_88:ed:b3 (00:1e:37:88:ed:b3)
Address Resolution Protocol (reply)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (0x0002)
    Sender MAC address: Foxconn_db:1c:a3 (00:15:58:db:1c:a3)
    Sender IP address: 172.16.3.140 (172.16.3.140)
    Target MAC address: Usi_88:ed:b3 (00:1e:37:88:ed:b3)
    Target IP address: 172.16.3.141 (172.16.3.141)

My question is this. How did my laptop (172.16.3.141) know the IP address for the server I was trying to connect to? (172.16.3.140) My capture does not show a WINS or DNS queries between frame 18 and frame 19.
I do not have any static host file entries either.

Thank you in advance

Don
dwesolowiczAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DCMBSCommented:
It was probably in the ARP cache.
0
dwesolowiczAuthor Commented:
prior to the capture I went to cmd line and ran arp -d which should delete the cahce.
I confirmed this by running arp -a and the only entry was for my gateway.
So Im still unsure how this is happening
0
DCMBSCommented:
Frame 18 is an ARP request for the device with IP 172.16.3.140 to respond with it's MAc address.  so the IP was resolved prior to frame 18
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

dwesolowiczAuthor Commented:
This is what I am unable to see.
I have the capture in a text file if you would be willing to look at it.

Thanks again!


arp.txt
0
DCMBSCommented:
Yes you are right. the trace does not show it being resolved so it mustr be cached somewhere.  If this is your Domain Controller then it will be hard to keep it's address out of the cahches as the domain contrioller is continuosly talking to all machines so it could well be that the IP was cahche inbetween ypou clearing all the caches and running the capture.  To see all the packets you should probably try doing this to a workstation you would not not normally connect to so the it is unlikely the IP or MAC is cached.
0
dwesolowiczAuthor Commented:
I just had a thought.
I was using some software called Dameware during the trace I sent you.
This software is used for remote administration.
During the trace, I was trying to connect to the machine by name.

For the heck of it it tried to connect to the machine in question using UNC, during a second trace.
The trace shows the name being resolved prior to the ARP request. So I guess the application must be resolving the name.

Thank you for working with me on this.

Don
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Internet Protocols

From novice to tech pro — start learning today.