ioctl() on socket fd's take 3 seconds on 1.7.7

Jason Curl
Tue Nov 23 09:39:00 GMT 2010

René Berber <r.berber <at>> writes:

> On 11/22/2010 2:29 PM, Jason Curl wrote:
> [snip]
> > And the interface that is failing: D4B7FEA9 = 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 The problematic instance isn't listed in "ipconfig".

So the question can be, where does 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      80:00:60:0F:E8:00 yes   no
{A045DC0F-A979-49B3-954C-D0678365FF26} AF_INET  00:60:57:1B:21:99 yes   no
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} AF_INET      80:00:60:0F:E8:00 yes   no
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007} AF_INET
          00:60:57:1B:21:99 yes   no
{56D2E68A-4173-4117-A719-65123B973C65} AF_INET     00:24:1D:71:F6:EC yes  yes
{7E5203E8-97DE-4822-9A2E-380BD258D97E} AF_INET  00:50:56:C0:00:01 yes  yes
{8424F604-4FAE-4541-9D8E-7B0A583A0956} AF_INET    00:50:56:C0:00:08 yes  yes
{846EE342-7039-11DE-9D20-806E6F6E6963} AF_INET        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,

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list