GNOME Bugzilla – Bug 337166
UPnP for firewall/NAT penetration
Last modified: 2020-06-06 16:30:44 UTC
It would be nice to have Ekiga support UPnP for NAT penetration. Most NATting routers currently understand it. Several bittorrent clients already do this (bittornado for example), and it works great.
Given the amount of work required, and given the huge list of features that are requested, compared to the little amount of time that I have and of patches that I receive from non-core developers, I have to add that this is VERY low on my TODO list.
*** Bug 342433 has been marked as a duplicate of this bug. ***
Damien, Would you accept a patch for this feature? Just trying to get a sense of your level of interest here. Thanks, Ben
Patches are always welcome. The level of interest is very low if we have to do it ourselves, as we have so much to do.
Hi, GUPnP may help in this task: "GUPnP is an object-oriented open source framework for creating UPnP devices and control points, written in C using GObject and libsoup. The GUPnP API is intended to be easy to use, efficient and flexible." (...) "The GUPnP framework was born out of frustration with libupnp and its mess of threads. GUPnP is entirely single-threaded (though asynchronous), integrates with the GLib main loop, and provides the same set of features as libupnp while hiding most of the UPnP internals through an elegant object-oriented design." "The GUPnP framework is free software released under the GNU LGPL." http://www.gupnp.org/ And last but not least, GUPnP is part of GNOME Mobile: http://www.gnome.org/mobile/ In hope that helps, Regards, Yannick
You're confusing: http://en.wikipedia.org/wiki/Upnp#UPnP_AV_.28Audio_and_Video.29_standards and: http://en.wikipedia.org/wiki/Upnp#NAT_traversal gupnp isn't helpful at all.
(In reply to comment #6) > You're confusing: > http://en.wikipedia.org/wiki/Upnp#UPnP_AV_.28Audio_and_Video.29_standards > and: > http://en.wikipedia.org/wiki/Upnp#NAT_traversal > > gupnp isn't helpful at all. > gupnp can be used for NAT traversal. You can test with the utility gupnp-universal-cp which allows to perform operations on an IGD, such as getting the external IP address, and doing the necessary portmapping. From the files at http://www.gupnp.org/sources/ it requires gupnp and gupnp-tools.
Another option is miniUPnP, http://miniupnp.free.fr/ "The MiniUPnP project offers software which supports the UPnP Internet Gateway Device (IGD) specifications. Recently, NAT-PMP support was added to MiniUPnPd. For client side NAT-PMP support, use libnatpmp. The MiniUPnP daemon (MiniUPnPd) supports OpenBSD, FreeBSD, NetBSD and (Open)Solaris in combination with pf or ipf and Linux with netfilter. The MiniUPnP client (MiniUPnPc) and MiniSSDPd are portable and should work on any POSIX system. MiniUPnPc also works under MS Windows."
Under what licences are those libs?
"The GUPnP framework is free software released under the GNU LGPL." miniUPnP is... hum... like this: "Copyright (c) 2005-2008, Thomas BERNARD All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
Looks like some kind of BSD : out. GUPnP is LGPL : perfect licence-wise. How portable is it?
(In reply to comment #11) > Looks like some kind of BSD : out. > > GUPnP is LGPL : perfect licence-wise. How portable is it? > At a discussion at Zeeshan's blog, http://zee-nix.blogspot.com/2008/06/gupnp-developer-tools-06-released.html On compatibility with Win32, he says "The main problem is that no one had a chance to even try it out on windows. The only unix-specific bits I see in the code are network-related stuff so that need to be ported at least."
Is it possible to have a description of which files would need to be worked on to have uPnP support?
(In reply to comment #6) > You're confusing: > http://en.wikipedia.org/wiki/Upnp#UPnP_AV_.28Audio_and_Video.29_standards > and: > http://en.wikipedia.org/wiki/Upnp#NAT_traversal > > gupnp isn't helpful at all. > Sorry for a very late reply but I was just informed of this bug. I am sorry to say this but you misunderstand GUPnP. It would be nice if you have a look at our poor project before discouraging people from utilizing it. <sigh>
(In reply to comment #8) > Another option is miniUPnP, > http://miniupnp.free.fr/ Agreed that miniUPnP has some advantages over GUPnP in this context, however: * GUPnP is nicely divided into separate libraries so one can decide to use whichever it likes, depending on her needs: gssdp, gupnp and gupnp-av. [1] * GUPnP is very nicely documented. You can easily find the links to docs on the homepage while it isn't the case with miniUPnP. One needs to download (after successfully finding the right tarball) the code and there is a manpage there. No devhelp/gtkdoc integration like the one GUPnP offers. * GUPnP provides a much nicer, yet generic gobject-based API that ties very nicely to glib's mainloop. * GUPnP offers both asynchronous (recommended) and synchronous API. In most cases you want asynchronous calls when it comes to UPnP since it might take a while before a particular UPnP device/service responds to a discovery request or an action invocation. miniUPnP seem to ONLY offer synchronous API. * Last but not the least, would be nice to have one common framework for UPnP in the GNOME (hopefully freedesktop) world and MiniUPnP is specific to IGD and therefore does not qualify for this. If you compare these two libs, it's very obvious that GUPnP was specifically designed for GNOME world while MiniUPnP was obviously not. Do I need to say more to convince you that GUPnP is *the* right choice for your (GNOME) app? :) [1] Would be really cool if someone can contribute a wrapper lib for IGD stuff: gupnp-igd, not that doing IGD in the app on top of raw gupnp API is any difficult.
I seem to remember that ptlib/opal (maybe it was pwlib/openh323) had support for the closed source Intel upnp stack, with that work in place is it possible to use it as a base to port it over to gupnp?
(In reply to comment #16) > I seem to remember that ptlib/opal (maybe it was pwlib/openh323) had support > for the closed source Intel upnp stack, with that work in place is it possible > to use it as a base to port it over to gupnp? > closed source? I thought libupnp (intel's UPnP lib) is open-source. I haven't seen the code so can't be completely sure but keeping in mind that our core library (gupnp) is on the same level as libupnp and that you are talking about libupnp, it should not be too hard (if not trivial).
libupnp is not being developed anymore, "As of 2005-2006, the original developers did not have the time to work on libupnp any more and nobody expressed interest in taking over development of the main project. As a result, Michael Pfeiffer forked a new project, pupnp, where he has pledged to continue active development." Source: http://upnp.sourceforge.net/ The new project is libpupnp, http://pupnp.sourceforge.net/ comes with the BSD license, "The Portable SDK for UPnP™ Devices is distributed under the BSD (Berkeley Standard Distribution) license." which is not suitable for Ekiga. Therefore, this brings us back to gupnp.
Sorry for the confusion about the Intel upnp. My point was that there has been support for it in the past in the voip libraries that ekiga is built upon using some intel upnp library (from memory at the time the support was added it had to be linked against binary object files or something and was primarily supported on windows) so support for it might be a matter of porting that effort to gupnp within ptlib/opal.
At this stage, shall we change 1. Priority, from Low to Normal 2. Status, from NEEDINFO to NEW The fact that gupnp has not been tested on Windows, is it a showstopper for this feature? I suppose on Windows, Ekiga could use the UPnP API from the Microsoft Platform SDK.
> I suppose on Windows, Ekiga could use the UPnP API from the Microsoft Platform > SDK. Either that or someone in Ekiga team with Windows programming skills can help us port GUPnP to Windows. If all the deps (libsoup, libxml2, gobject) work on Windows, I suspect this shouldn't be a hard task at all.
There are several ways to implement UPNP support for Ekiga. The easiest one is to add support for GUPNP in PTLIB itself. PTLIB has nice abstraction classes which are being used by OPAL and also by Ekiga. One of them is defined in src/ptclib/psockbun.cxx, PMonitoredSockets. This class is the class that provides sockets abstraction, which allows using several NAT Methods. The only supported NAT method is current STUN, but UPNP could be added easily. The purpose is nearly the same : request a port binding, and receive the public IP and port in return. So the implementation will not differ that much. Notice that the use of such an abstraction class is very useful. That means that all protocols classes will get support for UPNP without having to change anything in them, no need to change the SIP code or the IAX code or the H.323 code, because that code is using a specical kind of socket, which is (sort of) the real socket but with the public ports and IP if available. They are thus being substituted in the PDUs without any effort. Hope it helps potential contributors.
This is no NEEDINFO...
There is now gupnp-igd which nicely wraps breaking through NATs with UPnP into a simple library: http://svn.o-hand.com/repos/gupnp/trunk/gupnp-igd/
And it seems that gupnp is now working on windows too. http://jensge.org/?p=206
Any news about this bug? Is there anyone still working on it? I took a look at the sources of the Transmission bittorrent client and it uses miniupnp for NAT traversal and automatic port forwarding. I think much of the Transmission NAT traversal code can be reused, so this should not be so hard to implement in Ekiga. I saw that Transmission embeds the library in its own subdirectory, would this be a problem in Ekiga? Regarding cross-platform support, miniupnp claims to be cross-platform, so Windows portability should not be an issue, especially if embedding the sources is acceptable so we don't rely on external libraries being present in the system. I'll try to implement support for UPnP in ekiga using this library and I'll send a patch in case of success, and hopefully it will be integrated in Ekiga soon enough.
(In reply to comment #26) > Regarding cross-platform support, miniupnp claims to be cross-platform, so > Windows portability should not be an issue, especially if embedding the sources > is acceptable so we don't rely on external libraries being present in the > system. That should not be a concern anymore since GUPnP has been made to work on win32 as well. Since GUPnP is already a blessed dependency of GNOME and Ekiga aims to be a GNOME app, I don't see any reason to consider any other alternatives. There is even a nice easy library that wraps the needs of Ekiga for you: gupnp-igd which has been successfully used in a consumer product even: Nokia N900. However, code speaks more than words so just supply the patch and then decision is in the hands of Ekiga maintainers.
Yes, it makes a lot of sense to use GUPnP in this case, I have no idea why transmission chose the other path since they are also a Gnome app. Thanks, I didn't know about that wrapper, I'll try it too and we'll see which approach is better for Ekiga.
(In reply to comment #28) > Yes, it makes a lot of sense to use GUPnP in this case, I have no idea why > transmission chose the other path since they are also a Gnome app. AFAIK, they wrote that code a long time ago before GUPnP was considered seriously by anyone. :) > Thanks, I didn't know about that wrapper, I'll try it too and we'll see which > approach is better for Ekiga. Cool!
(In reply to comment #26) > Any news about this bug? Is there anyone still working on it? No. Please make a patch if you can (better without hacks inside). I suppose it is for ptlib. In that case, it should be directed to opalvoip bug tracker, we will see that later.
Cristian, forgot to tell you to use the active branches from http://wiki.ekiga.org/index.php/Download_Ekiga_sources for your development.
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.