Bug 1713947
Summary: | Sip protocol fails for private IPv6 addresses on peer to peer | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stuart D Gathman <stuart> |
Component: | linphone | Assignee: | nucleo <alekcejk> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 32 | CC: | alekcejk, rakesh.pandit |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-05-25 17:15:15 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Stuart D Gathman
2019-05-26 00:56:42 UTC
The workaround for now is to echo 1 > /proc/sys/net/ipv6/conf/<yournetif>/disable_ipv6 Your VPN should not depend on IPv6 and the private IPs will still be available on the tunX interface for the VPN. To restore normal IPv6 connectivity, echo 0 to disable_ipv6 for the wifi/ethernet. Note: a peer to peer IPv6 sip URL looks like this: sip:username@[fc00:f1b5:5a17:e108:2b69:0614:f4e3:d9a8] Linphone addressbook handles that just fine. Also, upstream claims to have simplified and improved peer to peer operation. Note: a peer to peer call over public IPv6 also works fine. I tried just plugging in linphone-3.12.0 - and a required dependency is bctoolbox, which isn't in Fedora. So updating is not trivial. bctoolbox has a GPL2 license, so could be packaged for Fedora. Or maybe it should be embedded? Also mediastreamer is not included in new linphone sources. If you can suggest changes in linphone.spec to build all of them in one package (or submit for review separate packages containing required dependencies) then maybe will be possible to build linphone update. Building of belle-sip is also not trivial. Tried 3.6.99 (which has a fix that might address my problem), and it requires: configure: error: Package requirements (belle-sip >= 1.2.0) were not met I'm guessing they stopped using libeXosip2 at that point? I had no problem dropping in mediastreamer2 as an embedded source. It should probably be it's own package in Fedora, but just trying to find a target I can get working atm. Looks like belle-sip is new sip stack used for new linphone versions. It was packaged but currently FTBFS https://src.fedoraproject.org/rpms/belle-sip belle-sip will be removed if FTBFS will be not fixed (I have no time to work on fix). I'm going through belle-sip build errors on f29 - they are all compiler warnings. Some are real potential overwrite bugs, so I'm patching them all. Got 4 done. Got belle-sip-1.4.2 built for f29 and f30. Now I can drop the other sip libs as BR and add bell-sip. Building linphone-3.6.99 now fails at: config.status: creating m4/Makefile BUILDSTDERR: config.status: error: cannot find input file: `po/Makefile.in.in' There is indeed no po/Makefile* in the source. Copied po/Makefile.in.in to SOURCE2 for building 3.6.99 (missing in 3.12.0 also). Now configure for mediastream2 can't fine ortp: checking for ORTP... no BUILDSTDERR: configure: error: Couldn't find ortp library BUILDSTDERR: configure: error: ./configure failed for mediastreamer2 Maybe also ortp needs to be updated. I added sdgathman in acl for ortp, belle-sip, linphone. Yes, mediastreamer2 requires ortp >= 0.24.0 ortp 0.24.0 drops built-in srtp. Instead of disabling srtp, I think it's time to make the bctoolbox package, and see if we can get all the way up to date. I did a test with IPv4 VPN on linphone-3.6.1, it does the same thing. The two ends connect at private IPs, the call lasts for 30 secs, packet trace shows that the SIP stack replaces the private IP specified as "gateway" with an arbitrary public IP - despite the devices not being able to reach each other on public IP (behind NAT). As mentioned before, this broken behavior is new for 2019. I'll try to get back to updating, but I have two packages failing to build in rawhide... This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |