This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]