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

[Elliott Slaughter]

Ok, I have a possible reason why this may be failing.

In l1-sockets.lisp, line 1436 (from trunk several months ago, so exactly
line number may have changed) says:

      (do* ((reservedlen (* 4 (record-length #>INTERFACE_INFO))
                         (* 2 reservedlen)))

I always thought this would increase the size of the buffer until it was
large enough to fit the data. But in ip-interfaces, when I tested a larger
initial value, it suddenly started working. (And it's returning 6
interfaces, so it's understandable how it might not have been able to fit
those in my initial memory size.)

I don't have all the stuff set up to build ccl from source, but would
someone (i.e. a ccl developer) like to try this out?

On Mon, Jul 19, 2010 at 9:11 PM, Elliott Slaughter <
elliottslaughter at gmail.com> wrote:

> 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
>



-- 
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/ebe88907/attachment.htm>