Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sourceware.cygnus.com
Message-ID: <37545B80.4C31E1D1@vinschen.de>
Date: Wed, 02 Jun 1999 00:15:28 +0200
From: Corinna Vinschen <corinna@vinschen.de>
MIME-Version: 1.0
To: ashishcn@cisco.com
CC: cygwin@sourceware.cygnus.com
Subject: Re: ioctl() SOS -- Please help
References: <374C9D2B.CBDD1EC4@cisco.com> <374CA453.6E07EFD1@vinschen.de> <374D85CF.AC0FFED3@cisco.com> <374D9F8D.3F370DF3@vinschen.de> <37544AE1.AFE086C@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"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