Re: ioctl() SOS -- Please help

Re: ioctl() SOS -- Please help

[Ashish C. Nagre]

Hello,
I was trying to debug (using gdb) the application that I am trying to
port from UNIX to NT.
I have made a strange observation, when the following call is made:
	
	ioctl(fd, SIOCGIFFLAGS, (char *)&ifr)

The value returned in the member ifr.ifr_ifru.ifru_flags is different
when I just run the executable compared to when I run it in the
debugger.
	ifr.ifr_ifru.ifru_flags = 34 (executable)
	ifr.ifr_ifru.ifru_flags = 99 (in gdb)
As a result, the following condition
	(ifr.ifr_ifru.ifru_flags & 0x1) ---> indicates that interface is up
always returns TRUE (correctly) in the gdb but returns FALSE
(erroneously) as the executable.
 Why are the flags returned with different values ?
Is there a bug in the command ?
Thanks for your help.


Regards,
Ashish

Corinna Vinschen wrote:
> 
> "Ashish C. Nagre" wrote:
> > [...]
> > My question is should I overwrite the cygwin1.dll with the new dll that
> > I got like you asked me to or should I copy it somewhere and just add
> > the new dll in the PATH (using set PATH etc.)
> 
> Overwrite it. To have more than one of this DLLs in the PATH is a
> no no!
> 
> > Because, even though now I have the dll and the source, I don't know how
> > to get my code which makes the ioctl() calls to work with these new
> > files.
> 
> After you have copied the new DLL over the old one, you only have to
> copy
> winsup/include/asm/socket.h to the according directory in your include
> path.
> 
> This would have been easier, if you had taken my DLL, which I mentioned
> in the first mail, too. It contains exactly the needed files.
> 
> Regards,
> Corinna
> 
> --
> new mail address:
> mailto:corinna@vinschen.de

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Corinna Vinschen]

"Ashish C. Nagre" wrote:
> I have made a strange observation, when the following call is made:
> 
>         ioctl(fd, SIOCGIFFLAGS, (char *)&ifr)
> 
> The value returned in the member ifr.ifr_ifru.ifru_flags is different
> when I just run the executable compared to when I run it in the
> debugger.
>         ifr.ifr_ifru.ifru_flags = 34 (executable)
>         ifr.ifr_ifru.ifru_flags = 99 (in gdb)
> [...]
>  Why are the flags returned with different values ?

The flags are computed through the address of the interface.
Is it possible, that you are testing it on a RAS device, e.g
a modem line? When a modem line isn't connected, it returns
the IP address 0.0.0.0, when it's connected, it returns a legal
address.
In case of address 0.0.0.0, the cygwin DLL knows, that the interface
isn't connected and so returns the flags
	IFF_NOTRAILERS | IFF_BROADCAST
The hex value of the above flags is 0x34.

If the address is a legal IP address, the cygwin DLL knows that the
interface is connected and so returns
	IFF_NOTRAILERS | IFF_BROADCAST | IFF_UP | IFF_RUNNING
The hex code is 0x99.

You see, both values are possible and you should check it out, if
you have tested it under different conditions.

Regards,
Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Corinna Vinschen]

Corinna Vinschen wrote:
> 
> "Ashish C. Nagre" wrote:
> > I have made a strange observation, when the following call is made:
> > [...]
> In case of address 0.0.0.0, the cygwin DLL knows, that the interface
> isn't connected and so returns the flags
>         IFF_NOTRAILERS | IFF_BROADCAST
> The hex value of the above flags is 0x34.

Oops, this isn't correct, is it? I have checked it on linux. The
ppp interfaces, which are not connected are nevertheless up and
running!

I will patch it ASAP.

Regards,
Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

ioctl() confusion

[Ashish C. Nagre]

Hi,
You said that it could be because of the RAS device. But the host that I
am testing on has 3 devices: "lo0" (loopback), "eth0" (ether) and 
"ppp4" ( the RAS device ??)
I am confused really because the flags that are returned when I run the
program in the gdb are 0x99 but when I run the executable the flags
returned are 0x34. This observation is quite inexplicable to me.
I would be really grateful if you could clear this issue with me.
If you need I can send you the segment of code where the ioctl() call is
made.
Meanwhile, I wait for your reply.
Thank you for all the help.


Regards,
Ashish

Corinna Vinschen wrote:
> 
> "Ashish C. Nagre" wrote:
> > I have made a strange observation, when the following call is made:
> >
> >         ioctl(fd, SIOCGIFFLAGS, (char *)&ifr)
> >
> > The value returned in the member ifr.ifr_ifru.ifru_flags is different
> > when I just run the executable compared to when I run it in the
> > debugger.
> >         ifr.ifr_ifru.ifru_flags = 34 (executable)
> >         ifr.ifr_ifru.ifru_flags = 99 (in gdb)
> > [...]
> >  Why are the flags returned with different values ?
> 
> The flags are computed through the address of the interface.
> Is it possible, that you are testing it on a RAS device, e.g
> a modem line? When a modem line isn't connected, it returns
> the IP address 0.0.0.0, when it's connected, it returns a legal
> address.
> In case of address 0.0.0.0, the cygwin DLL knows, that the interface
> isn't connected and so returns the flags
>         IFF_NOTRAILERS | IFF_BROADCAST
> The hex value of the above flags is 0x34.
> 
> If the address is a legal IP address, the cygwin DLL knows that the
> interface is connected and so returns
>         IFF_NOTRAILERS | IFF_BROADCAST | IFF_UP | IFF_RUNNING
> The hex code is 0x99.
> 
> You see, both values are possible and you should check it out, if
> you have tested it under different conditions.
> 
> Regards,
> Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Corinna Vinschen]

"Ashish C. Nagre" wrote:
> 
> Hi,
> I am sorry but this mail confused me a bit. Can you elaborate ?
> Are you saying that there is a problem with the cygwin1.dll which
> supports the ioctl() call ?
> Please do let me know.

It says, that a _disconnected_ interface is interpreted as _down_.
This is an error in cygwin. Await the patch in one of the next snapshots.

Again: The description in my previous mail is only relevant for RAS
interfaces (pppX). Local ethernet cards (ethX) are interpreted as UP
and RUNNING in any case.

Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Corinna Vinschen]

Corinna Vinschen wrote:
> 
> "Ashish C. Nagre" wrote:
> > I have made a strange observation, when the following call is made:
> > [...]
> In case of address 0.0.0.0, the cygwin DLL knows, that the interface
> isn't connected and so returns the flags
>         IFF_NOTRAILERS | IFF_BROADCAST
> The hex value of the above flags is 0x34.

Oops, this isn't correct, is it? I have checked it on linux. The
ppp interfaces, which are not connected are nevertheless up and
running!

I will patch it ASAP.

Regards,
Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Corinna Vinschen]

"Ashish C. Nagre" wrote:
> I have made a strange observation, when the following call is made:
> 
>         ioctl(fd, SIOCGIFFLAGS, (char *)&ifr)
> 
> The value returned in the member ifr.ifr_ifru.ifru_flags is different
> when I just run the executable compared to when I run it in the
> debugger.
>         ifr.ifr_ifru.ifru_flags = 34 (executable)
>         ifr.ifr_ifru.ifru_flags = 99 (in gdb)
> [...]
>  Why are the flags returned with different values ?

The flags are computed through the address of the interface.
Is it possible, that you are testing it on a RAS device, e.g
a modem line? When a modem line isn't connected, it returns
the IP address 0.0.0.0, when it's connected, it returns a legal
address.
In case of address 0.0.0.0, the cygwin DLL knows, that the interface
isn't connected and so returns the flags
	IFF_NOTRAILERS | IFF_BROADCAST
The hex value of the above flags is 0x34.

If the address is a legal IP address, the cygwin DLL knows that the
interface is connected and so returns
	IFF_NOTRAILERS | IFF_BROADCAST | IFF_UP | IFF_RUNNING
The hex code is 0x99.

You see, both values are possible and you should check it out, if
you have tested it under different conditions.

Regards,
Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Ashish C. Nagre]

Hello,
I was trying to debug (using gdb) the application that I am trying to
port from UNIX to NT.
I have made a strange observation, when the following call is made:
	
	ioctl(fd, SIOCGIFFLAGS, (char *)&ifr)

The value returned in the member ifr.ifr_ifru.ifru_flags is different
when I just run the executable compared to when I run it in the
debugger.
	ifr.ifr_ifru.ifru_flags = 34 (executable)
	ifr.ifr_ifru.ifru_flags = 99 (in gdb)
As a result, the following condition
	(ifr.ifr_ifru.ifru_flags & 0x1) ---> indicates that interface is up
always returns TRUE (correctly) in the gdb but returns FALSE
(erroneously) as the executable.
 Why are the flags returned with different values ?
Is there a bug in the command ?
Thanks for your help.


Regards,
Ashish

Corinna Vinschen wrote:
> 
> "Ashish C. Nagre" wrote:
> > [...]
> > My question is should I overwrite the cygwin1.dll with the new dll that
> > I got like you asked me to or should I copy it somewhere and just add
> > the new dll in the PATH (using set PATH etc.)
> 
> Overwrite it. To have more than one of this DLLs in the PATH is a
> no no!
> 
> > Because, even though now I have the dll and the source, I don't know how
> > to get my code which makes the ioctl() calls to work with these new
> > files.
> 
> After you have copied the new DLL over the old one, you only have to
> copy
> winsup/include/asm/socket.h to the according directory in your include
> path.
> 
> This would have been easier, if you had taken my DLL, which I mentioned
> in the first mail, too. It contains exactly the needed files.
> 
> Regards,
> Corinna
> 
> --
> new mail address:
> mailto:corinna@vinschen.de

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

ioctl() confusion

[Ashish C. Nagre]

Hi,
You said that it could be because of the RAS device. But the host that I
am testing on has 3 devices: "lo0" (loopback), "eth0" (ether) and 
"ppp4" ( the RAS device ??)
I am confused really because the flags that are returned when I run the
program in the gdb are 0x99 but when I run the executable the flags
returned are 0x34. This observation is quite inexplicable to me.
I would be really grateful if you could clear this issue with me.
If you need I can send you the segment of code where the ioctl() call is
made.
Meanwhile, I wait for your reply.
Thank you for all the help.


Regards,
Ashish

Corinna Vinschen wrote:
> 
> "Ashish C. Nagre" wrote:
> > I have made a strange observation, when the following call is made:
> >
> >         ioctl(fd, SIOCGIFFLAGS, (char *)&ifr)
> >
> > The value returned in the member ifr.ifr_ifru.ifru_flags is different
> > when I just run the executable compared to when I run it in the
> > debugger.
> >         ifr.ifr_ifru.ifru_flags = 34 (executable)
> >         ifr.ifr_ifru.ifru_flags = 99 (in gdb)
> > [...]
> >  Why are the flags returned with different values ?
> 
> The flags are computed through the address of the interface.
> Is it possible, that you are testing it on a RAS device, e.g
> a modem line? When a modem line isn't connected, it returns
> the IP address 0.0.0.0, when it's connected, it returns a legal
> address.
> In case of address 0.0.0.0, the cygwin DLL knows, that the interface
> isn't connected and so returns the flags
>         IFF_NOTRAILERS | IFF_BROADCAST
> The hex value of the above flags is 0x34.
> 
> If the address is a legal IP address, the cygwin DLL knows that the
> interface is connected and so returns
>         IFF_NOTRAILERS | IFF_BROADCAST | IFF_UP | IFF_RUNNING
> The hex code is 0x99.
> 
> You see, both values are possible and you should check it out, if
> you have tested it under different conditions.
> 
> Regards,
> Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: ioctl() SOS -- Please help

[Corinna Vinschen]

"Ashish C. Nagre" wrote:
> 
> Hi,
> I am sorry but this mail confused me a bit. Can you elaborate ?
> Are you saying that there is a problem with the cygwin1.dll which
> supports the ioctl() call ?
> Please do let me know.

It says, that a _disconnected_ interface is interpreted as _down_.
This is an error in cygwin. Await the patch in one of the next snapshots.

Again: The description in my previous mail is only relevant for RAS
interfaces (pppX). Local ethernet cards (ethX) are interpreted as UP
and RUNNING in any case.

Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com