René Berber <r.berber <at> computer.org> writes:
>
> On 11/22/2010 2:29 PM, Jason Curl wrote:
> [snip]
> > And the interface that is failing: D4B7FEA9 = 169.254.183.212 doesn't
> > appear by a call to "ipconfig /all". I'm guessing that Windows is
> [snip]
> > I'm not sure where this IP is currently coming from...
>
> It's Microsoft's default address, used when the network interface is set
> to "Obtain an IP address automatically" and no server responds or
> accepts the request, and the "Alternate Configuration" is set to use
> "Automatic private IP address".
>
> But the real point is: it shouldn't be used in any case other than when
> the interface can't get an address. And that is only during
> configuration...
Your second point is not relevant, it doesn't matter if my interface is fixed,
DHCP or AutoIP, so long as the Windows routing table knows what IP address
belongs with which MAC. Proof is in the logs.
There are two instances of AutoIP. The second instance (VMware Network Adapter
VMnet1) is bound to an interface with 169.254.211.193. The problematic instance
169.254.183.212 isn't listed in "ipconfig".
So the question can be, where does 169.254.183.212 which doesn't appear to be
bound to a particular interface, so that when SendARP() is called, Win7 thinks
it needs to send a query out on the network thus causing a 3 second delay?
I didn't get enough time to get this far last night. It appears to be a problem
with "Tunnel adapter isatap.{A045DC0F-A979-49B3-954C-D0678365FF26}". But I have
a feeling it's probably to do with my Bluetooth Interface (as other tunnel
adapters don't cause problems).
{4ED54D4E-1024-4BDF-A926-67D2895D2DC4} a9fe0202
{A045DC0F-A979-49B3-954C-D0678365FF26} a9feb7d4 <- Culprit
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} a9fe0202
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007} 00000000
{56D2E68A-4173-4117-A719-65123B973C65} c0a80119
{7E5203E8-97DE-4822-9A2E-380BD258D97E} a9fed3c1
{8424F604-4FAE-4541-9D8E-7B0A583A0956} c0a8df01
{846EE342-7039-11DE-9D20-806E6F6E6963} 7f000001
The output of my "ifconf" replacement shows, where the MAC address of the
culprit is the same as the BT interface:
{4ED54D4E-1024-4BDF-A926-67D2895D2DC4} AF_INET 169.254.2.2
255.255.255.0
169.254.2.255 169.254.2.2 80:00:60:0F:E8:00 yes no
{A045DC0F-A979-49B3-954C-D0678365FF26} AF_INET 169.254.183.212
255.255.0.0
169.254.255.255 169.254.183.212 00:60:57:1B:21:99 yes no
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} AF_INET 169.254.2.2
255.255.255.0
169.254.2.255 169.254.2.2 80:00:60:0F:E8:00 yes no
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007} AF_INET 0.0.0.0
255.0.0.0
0.255.255.255 0.0.0.0 00:60:57:1B:21:99 yes no
{56D2E68A-4173-4117-A719-65123B973C65} AF_INET 192.168.1.25
255.255.255.0
192.168.1.255 192.168.1.25 00:24:1D:71:F6:EC yes yes
{7E5203E8-97DE-4822-9A2E-380BD258D97E} AF_INET 169.254.211.193
255.255.0.0
169.254.255.255 169.254.211.193 00:50:56:C0:00:01 yes yes
{8424F604-4FAE-4541-9D8E-7B0A583A0956} AF_INET 192.168.223.1
255.255.255.0
192.168.223.255 192.168.223.1 00:50:56:C0:00:08 yes yes
{846EE342-7039-11DE-9D20-806E6F6E6963} AF_INET 127.0.0.1
255.0.0.0
127.255.255.255 127.0.0.1 00:00:00:00:00:00 yes yes
In this case, it appears that this is an example of an interface that is
*not* up.
Thanks & Best Regards,
Jason.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
