[Openmcl-devel] %get-ip-interfaces returning nil

[Elliott Slaughter]

I don't know how I can possibly not have an active interface when I am using
my computer to write this email ;-)

If you'd like me to do any testing, I'd be happy to. I've tried both ccl 1.4
and 1.5 and both still return nil for me.

On Mon, Jul 19, 2010 at 1:07 AM, Gary Byers <gb at clozure.com> wrote:

> We used to use an address returned by %GET-IP-INTERFACES as part of
> random-state
> initialization, and my recollection is that that would sometimes fail on
> Windows
> because %GET-IP-INTERFACES sometimes returned NIL.  Unless something's
> really
> badly misconfigured on a Unix box, at least the loopback interface
> (127.0.0.1)
> would always be there, and you'd generally see other interfaces known to
> the OS
> regardless of whether they were up or down and regardless of whether or not
> they
> had had IP(V4) addresses assigned to them or not; you'd pretty much see
> what
> "ifconfig -a" would show you (and it was likely that the ifconfig program
> and
> %GET-IP-INTERFACES were using the same mechanism to enumerate network
> interfaces.)
>
> On a Win7 box running the CCL trunk - where the ethernet interface is
> active and
> a WiFi interface is disabled - %GET-IP-INTERFACES returns a list describing
> the
> loopback and ethernet interfaces.  I'm ssh'ed into that box and can't
> conveniently
> try, but I'm fairly sure that if I disabled the ethernet interface it'd
> return
> an empty list (the loopback interface might only be visible if some
> non-loopback
> interface is active in some sense.)  Many laptop WiFi cards will go to
> sleep (to
> save power) if they haven't seen traffic for a while, and that might also
> cause
> %GET-IP-INTERFACES to return NIL.
>
> If this is true ... well, what %G-I-I does on Windows isn't quite what it
> does
> on Unix systems (it's more like "%GET-ACTIVE-INTERFACES", for a possibly
> strict
> definition of "active.")  There's likely some way of enumerating all
> interfaces
> on Windows (things like network control panels need some way of doing
> that), but
> there may or may not be a public, supported way.  I don't know.
>
> I also don't know how much I trust my theory about WiFi interfaces
> turning themselves on and off - the SIO_GET_INTERFACE_LIST ioctl is
> supposed to
> return a list of "configured" interfaces, and I don't know whether a
> power-saving
> mode would involve loss of configuration.
>
> (All of this is a long way of saying "I don't know"; I'm pretty confident
> in
> saying that the CCL code for %GET-IP-INTERFACES hasn't changed in at least
> a year
> or two and that what it returns on Windows depends on what interfaces are
> "active",
> though I don't know precisely how "active" is defined.)
>
>
>
> On Sun, 18 Jul 2010, Elliott Slaughter wrote:
>
>  Hi,
>>
>> I have kind of a bizarre problem. I noticed recently that
>> ccl::%get-ip-interfaces returns nil for me, but just 3 or 4 months
>> ago I used to get a list of my network connections. I am running Windows 7
>> Pro 64-bit, and have not upgraded or changed my CCL
>> installation in any way during that time frame. My CCL version is
>> 1.4-r13122. The only thing I can think of that might changed
>> on my system are security updates from Microsoft. I have tried changing
>> network settings, and disabling the firewall, and
>> nothing seems to help.
>>
>> The reason I ask is because several months ago I
>> ported ccl::%get-ip-interfaces to CFFI. At the time, that implementation
>> worked perfectly on 5 different CL implementations. Now it returns nil in
>> all of them in Windows. I have not made any changes
>> to the ip-interfaces code during that time. Everything still works fine on
>> other operating systems.
>>
>> Any ideas would be appreciated. Thanks.
>>
>> --
>> Elliott Slaughter
>>
>> "Don't worry about what anybody else is going to do. The best way to
>> predict the future is to invent it." - Alan Kay
>>
>>


-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict
the future is to invent it." - Alan Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100719/c019b1a9/attachment.htm>