On Nov 23 21:19, Jason Curl wrote:
On 23/11/2010 16:38, Corinna Vinschen wrote:
I applied a patch so that IFF_NOARP is
only set for PPP and SLIP devices, so the call to SendARP is gone.
Please test CVS or the next developer snapshot.
I tried to understand what this flag is for. As far as
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I tried to understand what this flag is for. As far as I can
understand, windows will always reply to ARP requests. There's a
registry entry for gratuitous arp. So doesn't that imply IFF_NOARP
will be set for all interfaces?
You
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
On Nov 22 21:29, Jason Curl wrote:
The actual delays are caused by SendARP() called from get_xp_ifs().
Interestingly enough, it isn't always slow, only sometimes.
[...]
First of all, thanks for looking deeper into this.
And the interface that is failing: D4B7FEA9 = 169.254.183.212
doesn't
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Nov 22 21:29, Jason Curl wrote:
The actual delays are caused by SendARP() called from get_xp_ifs().
Interestingly enough, it isn't always slow, only sometimes.
[...]
First of all, thanks for looking deeper into this.
Thanks for
On Nov 23 14:10, Jason Curl wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
On Nov 22 21:29, Jason Curl wrote:
The actual delays are caused by SendARP() called from get_xp_ifs().
Interestingly enough, it isn't always slow, only sometimes.
[...]
Ok, so SendARP is kind of
On 23/11/2010 16:38, Corinna Vinschen wrote:
On Nov 23 14:10, Jason Curl wrote:
Actually, after reading a bit about this flag, the usage in Cygwin
seems to be wrong anyway. I applied a patch so that IFF_NOARP is
only set for PPP and SLIP devices, so the call to SendARP is gone.
Please test CVS
On Nov 20 18:25, Jason Curl wrote:
On 15/11/2010 17:22, Corinna Vinschen wrote:
On Nov 9 09:20, Jason Curl wrote:
166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364
--- Process 5580, exception C005 at 610C8C86
Crash in Cygwin, but the address doesn't help much, unfortunately.
On 22/11/2010 14:17, Corinna Vinschen wrote:
On Nov 20 18:25, Jason Curl wrote:
On 15/11/2010 17:22, Corinna Vinschen wrote:
On Nov 9 09:20, Jason Curl wrote:
166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364
--- Process 5580, exception C005 at 610C8C86
Crash in Cygwin, but
On 22/11/2010 14:17, Corinna Vinschen wrote:
Can you retry with the next developer snapshot? Are the ioctl calls
still slow? If so, I'm wondering if the GetAdaptersAddresses call is
rather slow if a lot of interfaces exist. Every single ioctl in your
application calls GetAdaptersAddresses
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
On 15/11/2010 17:22, Corinna Vinschen wrote:
On Nov 9 09:20, Jason Curl wrote:
166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364
--- Process 5580, exception C005 at 610C8C86
Crash in Cygwin, but the address doesn't help much, unfortunately.
Interestingly enough, the program
On Nov 9 09:20, Jason Curl wrote:
166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364
--- Process 5580, exception C005 at 610C8C86
Crash in Cygwin, but the address doesn't help much, unfortunately.
Interestingly enough, the program works. That is, it finds all
interfaces and
Hello,
Cygwin 1.7.7 is definitely an improvement over 1.5.x but I see a
regression on 1.7.7 (on Win7 x64) that ioctl() on a socket FD takes 3
seconds.
I'm writing my own ifconfig replacement and I do the following:
#define IFC_BUF 10 * sizeof(struct ifreq)
#define MAX_IFC_BUF
14 matches
Mail list logo
