Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Jochen De Smet
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);
(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.
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 169.254.0.0/16 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
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.
@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…
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.)
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.