ifaddrs.h: getifaddrs() causing invalid argument exception.

[MadcowD]

Hi. In alignement with my explorations today, it appears that ifaddrs.h is not fully implemented, or there is some other bug. Whenever one attempts to call getifaddrs(), errno is set to EINVAL.

This is causing issues in #134 and is probably just as related to #69 as anything else is. Furthermore, this is the reason why almost all of the LibZMQ tests seem to be failing. I've attached the test suite output after building libzmq and running make check. Finally this is causing errors with Anaconda, in particular the iPython or Jupyter notebook projects cannot use sockets to communicate between the browser and the iPython kernel, this is seen in this issue #1331.

The following code replicates the error:

#include <ifaddrs.h>
#include <iostream>
#include <errno.h>

int main(){
    ifaddrs *p = 0;
    int rc = getifaddrs(&p);

    std::cout << "Succeded ? " << rc << "\n";

    if(rc == -1){
        if(errno == 22)
            std::cout << "Invalid argument exception.";
    }

    std::cin.get();
    return 0;

}

[sunilmut]

@MadcowD getifaddrs requires NETLINK\RAW socket support, which unfortunately we don't have at the moment. Meanwhile, help us prioritize this by up voting network interface query support in our user voice page. Thanks for trying out WSL and providing us valuable feedback.

[sunilmut]

Also see #118

[bobsummerwill]

Hello! I'm seeing exactly the same issue for cpp-ethereum.

I've worked through build errors in #147 and am now onto runtime errors, the first of which is a showstopper on getifaddrs().

See https://twitter.com/BobSummerwill/status/740820732737904640.

The failure is occurring very early on, at https://github.com/bobsummerwill/cpp-ethereum/blob/merge_repos/libp2p/Network.cpp#L82, in code which is likely very similar to networking code which many other Linux apps have.

[misenesi]

Works on my latest internal builds, the fix should make its way to the insider builds eventually (if it already hasn't).

[sunilmut]

This is fixed in the latest insider build 14971. Thanks.

[alehostert]

Hi, just a question.
How many days would take to launch the fix on regular version? I'm not into Insider Program.

[aseering]

Hi @Hostert -- these improvements are scheduled to be released as part of the next major Windows version, which we've been told is scheduled for release sometime in maybe the first quarter or half of 2017?

[marcobehler]

Is this one really closed? I am on 14971 but am still experiencing the problem.

[alehostert]

Thank you @aseering.

[sunilmut]

@marcobehler - I am not able to repro the above issue on build 14971 using the sample program posted by @MadcowD. Do you have the teredo interface installed by any means on your Windows box? If so, you might be running into #1414 or #468. See the workaround posted by @saschagehlich in #468 to disable the teredo interface. A fix for that is coming soon.

[mattrothenberg]

@sunilmut I can confirm that @saschagehlich's workaround posted in in #468 resolved my problem in trying to run Middleman (middleman/middleman#1960). Thank you so much! Care to explain (to a Windows & Ubuntu newbie like myself) what this change actually does?

[marcobehler]

@sunilmut can also make it work with @saschagehlich's workaround. (then the error goes away)...

[sunilmut]

Glad to know @mattrothenberg and @marcobehler that it resolves both of your issues. @JasonLinMS can provide the exact details. But as I understand, the "Teredo Tunneling Pseudo-Interface" has a HW address of 32 bytes. In string format, each byte requires 3-byte for representation i.e 32*3 = 96bytes. While the 'ip' tool is hard coded to only expect 64 bytes overall. So, there is buffer overflow and the tool crashes.

[JasonLinMS]

@sunilmut Thanks for the great explanation.

[sunilmut]

The teredo issue should be fixed in 15007

[sunilmut]

Closing this out. If anyone is still (on builds 15007+) having problems, please let us know and we can reopen.