• Jochen De Smet

    Jochen De Smet - 2011-06-09

    Should this just replace the sipe_backend_network_ip_address implementation in src/purple/purple-network.c ?  Or is there any reason why sipe-ft (which is the only caller of get_suitable_local_ip) is the only one that shouldn't get a 169.254 address ?

    Of course, in addition to not returning 169.254 addresses, using the code in get_suitable_local_ip also disables the purple option of manually entering an IP, and also disables STUN discovery.

    But the reason I'm bringing this up is actually much simpler: I can't easily get the get_suitable_local_ip code to compile in VC, so I'd like to get it out of the core.

    So I propose:

    1) move get_suitable_local_ip into src/purple/purple-network.c and make it static
    2) change the implementation of sipe_backend_network_ip_address to something like

    const gchar *sipe_backend_network_ip_address(void)
            const gchar *ip = purple_network_get_my_ip(-1);
            if (!strstr(ip,"169.254")) ip = get_suitable_local_ip(-1);
            return ip;

    (yeah that strstr is wrong; can't remember the right function off hand)

    This would move the 169.254 workaround from the core to the purple backend, and lets file transfers properly use STUN and hardcoded IPs.

  • Jakub Adam

    Jakub Adam - 2011-06-10

    Hi Jochen,

    I think get_suitable_local_ip() can be called whenever we need IP address, not only for filetransfer, as chances are low that connection to OCS will work with only link local address assigned. Your proposal seems ok to me, you are free to implement it.

    I wrote get_suitable_local_ip() after a problem I had on a computer with two network interfaces, one of which was up but with cable unplugged so avahi-autoipd assigned it an address from range. Later on attempt to send a file, purple_network_get_my_ip() returned address of this interface instead of the other one that was correctly connected to network, causing transfer to fail.

  • Jochen De Smet

    Jochen De Smet - 2011-06-11

    Checked in as commit 5e970e.

    Seems to work I'd appreciate it if you could give it a quick look in case I missed something.

  • Stefan Becker

    Stefan Becker - 2011-06-11

    @jochen: this will probably fail to compile on FreeBSD, Sun and Apple. As far as I remember this was one of the functions where you had to get the #includes right. As far as I can see you have only transferred one of the network #includes from sipe_utils.c with the code…

  • Jochen De Smet

    Jochen De Smet - 2011-06-11

    Thanks for the cleanup.
    I tried to transfer the minimal amount to make everything work. Is there anything available like OBS that I could use to test compiles for those platforms?   I can probably set up a FreeBSD VM locally, but not sure what to do about the others.

    I noticed that your commit just removes the unneeded includes from sipe-utils; does this mean you think purple-network is still broken on bsd/sun/apple after your cleanup ?

    (And while you're cleaning up, HX_SIZE_OF_IFREQ is defined but then never used; the hardcoded IFREQ_MAX value is used instead. Wasn't sure if that was intentional or some weird black magic so I left that alone.)

  • Stefan Becker

    Stefan Becker - 2011-06-11

    You added the last header from sipe-utils.c to purple-network.c. So I think it will probably be OK. That is the problem with OBS: there is nothing else than Linux. I.e. as no -non-Linux user compiles from git HEAD we only lean about portability issues (long) after releases.

    You are right, HX_SIZE_OF_IFREQ is a left-over from the original code that no longer compiled due to alignment issues. I forgot to remove that macro when I rewrote the code.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks