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

[Gary Byers]

On Mon, 19 Jul 2010, Elliott Slaughter wrote:

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

Except for the lisp kernel, the stuff that you need to build CCL from source
is CCL itself, and you presumably have that ...

Since this doesn't involve the lisp kernel, you can just change lisp code and
build a lisp image via:

? (rebuild-ccl :clean t)

In any case, you seem to be correct in suggesting that the problem has to do
with the case when the initial guess ("reservedlen") is too small.  If the number
of interfaces is > 4 in the original lisp code (or > than ... oh, 53.9 or so
in the case of the C code that someone mailed out), then the call to WSAIoctl
that tries to enumerate those interfaces fails (returns -1, aka SOCKET_ERROR)
and causes WSAGetLastError to return WSAEFAULT, which means "either a memory
fault occurred, or some buffer wasn't big enough.  Who knows which ?"

If we guess that WSAEFAULT means "the buffer wasn't big enough" and try again
with a larger buffer size, we'll eventually succeed in guessing how large the
buffer needs to be.  (Or we'll keep provoking the same memory fault over and
over again.  Who knows ?)

As I've gotten older and mellower, I've come to see the wisdom in the
old adage that says "If you can't say anything nice about a
programming interface, it's best not to say anything at all."  This
certainly seems to be true, no matter how brain-dead and misbegotten
and error-prone the interface in question is.

The modified code is in the trunk as of r13990; if you need it in other branches,
let me know.

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