FWIW I have NO firewalls running and I get this same behavior in safe mode. What's perplexing is how everything works fine with my internal wifi but not the 4 other interfaces. Diags below:
ROUTE PRINT===========================================================================
Interface List0x1 ........................... MS TCP Loopback interface
0x90002 ...00 1a 80 64 01 30 ...... Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.2 10 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 10
192.168.0.2 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.0.255 255.255.255.255 192.168.0.2 192.168.0.2 10
224.0.0.0 240.0.0.0 192.168.0.2 192.168.0.2 10
255.255.255.255 255.255.255.255 192.168.0.2 192.168.0.2 1Default Gateway: 192.168.0.1
===========================================================================
Persistent Routes: None
IPCONFIGWindows IP Configuration
Host Name . . . . . . . . . . . . : laptop Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : nyc.rr.com
Ethernet adapter Dock LAN:
Connection-specific DNS Suffix . : nyc.rr.com
Description . . . . . . . . . . . : Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller Physical Address. . . . . . . . . : 00-1A-80-64-01-30
Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1 DHCP Server . . . . . . . . . . . : 192.168.0.1
DNS Servers . . . . . . . . . . . : 192.168.0.1 Lease Obtained. . . . . . . . . . : Tuesday, January 27, 2009 12:53:36 AM
Lease Expires . . . . . . . . . . : Sunday, February 08, 2009 12:53:36 PM
On Tue, Jan 27, 2009 at 12:32 AM, Jim Young
<sysjhy@xxxxxxxxxxxxxxx> wrote:
>>> staedtlerx <staedtlerx@xxxxxxxxx> 1/26/2009 11:16 PM >>>
> I tried NetMon - it appears to output the same exact info that Wireshark
> does. Should I somehow be invoking more info?
The two traces you sent both indicate that the Sony system (192.168.0.2)
--- the system that initiated the DNS queries --- is actually rejecting the DNS
replies it asked for!
The two ICMP "Destination Unreachable (Port unreachable)" messages
within each trace are responses generated by your host (192.168.0.2) in
response the DNS response packets.
I've seen similar behavior when someone's workstation based firewall is
mis-configured, when multiple NIC cards are installed and mis-configured
or also (rarely) when the application that initiated the DNS request is no
longer listening on the UDP port that the request was initiated from.
FWIW: I doubt that your ping or tracert initiated DNS requests resulted
in the UDP port itself to be closed so soon after the requests was sent.
Generally speaking the Windows DNS stub resolver uses the same
ephemeral UDP port for all requests until the system is rebooted. The
nslookup tool on the other hand uses a new ephemeral UDP port
for each DNS request.
It's seems somewhat odd that your system sends two DNS requests
so close in time to one other, but these are NOT duplicate packets,
each DNS request has a unique incrementing ip.id value.
Someone suggested that you show us a copy of how routing in
configured on this Windows machine. You can generate this report
from a Windows cmd shell with the either of the following commands:
route print
or
netstat -r
Also a complete copy of your workstation's complete ip setup might
be useful: e.g.
ipconfig /all
Perhaps attaching the output of these two reports might shed some
light on what may be going on.
Best regards,
Jim Y.
