This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: ioctl() SOS -- Please help
- To: ashishcn@cisco.com
- Subject: Re: ioctl() SOS -- Please help
- From: Corinna Vinschen <corinna@vinschen.de>
- Date: Wed, 02 Jun 1999 00:15:28 +0200
- CC: cygwin@sourceware.cygnus.com
- References: <374C9D2B.CBDD1EC4@cisco.com> <374CA453.6E07EFD1@vinschen.de> <374D85CF.AC0FFED3@cisco.com> <374D9F8D.3F370DF3@vinschen.de> <37544AE1.AFE086C@cisco.com>
"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