Previously, NUM_COPY was used in ssdp_device.c to send multiple copies
of each advertisements but also multiple replies to each M-SEARCH
request. As sending multiple replies is not compliant with HTTPU/MU
spec, NUM_COPY has been set to 1 in an older patch. However, as this
variable is not needed and has been replaced with SSDP_COPY, it has
been removed.
(cherry picked from commit 2d22e997e1ff06ad2b202623d73f4d3f321c6131)
Currently, SSDP_COPY is used only to send multiple M-SEARCH requests (in
ssdp_ctrlpt.c). With this patch, SSDP_COPY is also used to send multiple
copies of each advertisements packets (in ssdp_device.c).
(cherry picked from commit 96dc968f18c9a2273dc76cdc59dd5438df553b26)
By "Carl Benson" <carl.benson@windriver.com>:
I had to do some modifications myself though, because the Android
build system insists on having a file named "util.h" taking precedence
in its include path, libupnp gets confused because of the same filename
in upnp/src/inc/util.h
(hand cherry picked from commit 8e846368e0f0e33a5d42bc56b0c6025a8afd5e78)
Fix a bug in miniserver.c, in which maxMiniSock was wrongly declared as
unsigned int and as a result it was beeng set to ((unsigned int)(-1)).
As a result, after beeing incremented, it became zero, and this value
was beeing used in the select() call.
Thanks to Fabrice Fontaine for helping and testing with this issue.
(cherry picked from commit 2bdc9e075e33efa35f49e8a9766e75df9eb91420)
the sleep() call, it was just a workaround.
SF Bug Tracker [ 3086852 ] 99% CPU loop in miniserver.c on a non ipv6
system.
Submitted by: Jin ( jin_eld ) - 2010-10-13 19:29:13 UTC
I cross compiled libupnp 1.6.7 for ARM9 using the --disable-ipv6
option, my system is an ipv4 only setup.
I do not know why this problem only appears when running the app in the
background (for instance using nohup &), but then it starts using 99%
CPU.
I traced the problem down to the select() call in miniserver.c in the
RunMiniServer() function. Select returns code 1, but errno is set to
"Socket operation on non-socket", I also see this when running my app
under strace.
I set all ...Sock6 variables to INVALID_SOCKET to make sure that they
do not get added to the FD_SET and the problem is gone.
(cherry picked from commit f74746ff3f06316a37d0359f11a84cb887b0a388)
Adding a configure flag to disable GENA notification reordering as even
with an imillisleep(1), this mechanism consumes too much CPU on embedded
devices when there is a burst of notifications.
(cherry picked from commit c73d870f46a9be94bc0e7b898dba4e480348933e)
When a device with embedded devices (like IGD) when created and one of
the embedded devices did not have any service, there was a Segmentation
Fault (see SF Tracker [ 2688125 ]).
(cherry picked from commit ab54cb3dc5ac6b30f6566593804a919473d4e6a5)
When a lot of notifications were generated by a device in a short
period of time then 100% of the CPU was used to reorder those
notifications by pushing back the thread in the job queue. This
mechanism has been modified so now thread sleep 1 ms before being
pushed back into the job queue.
Removing DEFAULT_SCHED_PARAM parameter and use
sched_get_priority_min(DEFAULT_POLICY) instead.
(cherry picked from commit c33b11d09f526c156760b24bb88c9100f107a042)
Devices must respond to M-SEARCH requests for any supported version and the
response should specify the same version as was contained in the search target.
Previously, the device did not answer if the M-SEARCH request did not
contain the same version number than the version number of the device.
(cherry picked from commit 4966423d96a2a7d81a5765587f219d11d9bee511)
Add Content-Language header in the response if and only if there is an Accept-Language header in the request.
Manually ported from revision d2238615e347c45c6abd255597d304cf50b763b5.
This patch adds the WEB_SERVER_CONTENT_LANGUAGE parameter so the user can specify
the language used by the device during Description and Presentation steps of UPnP
through the HTTP CONTENT-LANGUAGE header.
By default, the WEB_SERVER_CONTENT_LANGUAGE is an empty string so no
CONTENT-LANGUAGE is added.
(cherry picked from commit 2fcbe6df52265576ad6bfc902541612ca89f30d4)
This patch allows a user to customize the stack size of the threads used by
pupnp through the new THREAD_STACK_SIZE variable. This is especially useful
on embedded systems with limited memory where the user can set THREAD_STACK_SIZE
to ITHREAD_STACK_MIN.
However, as this modification can have side effects, I set 0 as the default
value, so threads will continue to use the default stack size of the system
(which varies greatly as stated in
https://computing.llnl.gov/tutorials/pthreads/).
(cherry picked from commit 467f9987a135986419222da968562aab26a3e637)
IPv6 is currently broken in latest release of branch-1.6.x, so find
a patch attached that correct the issue (small fixes on define,
undef and retVal).
(cherry picked from commit 55d581481f901bce22ce014e0ec5b74a5ed325e6)
Updated threadutil to use mutexes instead of read-write locks if
UPNP_USE_RWLOCK is false (0).
(cherry picked from commit 2b399b17911372c90cca67e464109359a586f518)
I discovered a reliable denial-of-service issue on the last stable
release of libupnp (1.6.6) remotely triggerable by any
unauthenticated user. The issue is related with a bad parsing of
malformed XML.
(cherry picked from commit 25a4bd6d253cec60ee11d7a43491e1b1a6be5465)
Sending messages over UDP is broken in some Apple OSes
such as OS X and iOS. This might be broken in other OSes to but didn't
verify.
The fix is to modify the socket lenght argument of sendto to use the correct
sockaddr lenght dependng on whether the socket is IPV4 or IPV6.
Also added some error checks and debugging related to the issue
(cherry picked from commit 2b3ab1799bca2514b772a2f7475e18aebf1df1af)
crash. This happens when the file being downloaded exceeds the device
memory - entirely possible when transferring video files.
The programmatic cause is that the logic implemented in the function
http_ReadHttpGet (which UpnpReadHttpGet calls) reads the entire file
into memory. The fix modifies the existing logic to discard data after
it's been read; there's no reason to keep it around since the caller
of UpnpReadHttpGet already has a copy of it.
This issue exists in 1.6.6 as well as the latest sources.
Patch submitted by Chandra (inactiveneurons).
(cherry picked from commit 4657e577662aa5136d63ebbb35d419a895e28c7b)
use connect() are broken. More specifically, connect() in these methods
is returning with an EINVAL. The programatic cause is that the address_len
argument passed to connect() is different in IPV4 vs IPV6 (as described in:
http://www.opengroup.org/onlinepubs/009695399/functions/connect.html).
The current code always uses the IPV6 size. The fix modifies each use of
connect() to use the correct size based on the address family being used.
Patch submitted by Chandra (inactiveneurons).
(cherry picked from commit 21660334e420382625aa145eeaf6d60b38d328aa)
(the netinet/* headers are not available).
Patch submitted by Chandra (inactiveneurons).
(cherry picked from commit 934bd2682fe15612f593fb0128eae26dd53bfb82)
at the end of the notification ("\r\n") in notify_send_and_recv() in
upnp/src/gena/gena_device.c.
Patch by Fabrice Fontaine.
(cherry picked from commit ebc941f2652f95158b121f208f202a781dce2234)
* InitHandleList() has never been implemented, I guess no one has ever
called it, so remove it.
* GetFreeHandle() and FreeHandle() are now static as they should.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@567 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* New internal buffer added to store global/ula IPV6 address.
* Macros to test whether an IPV6 address is global or ula.
* UpnpGetServerUlaGuaIp6Address(): added interface.
* IN6_IS_ADDR_GLOBAL, IN6_IS_ADDR_ULA: new macros.
* gIF_IPV6_ULA_GUA: new buffer.
* UpnpRegisterRootDevice3(): Change to the test of already registered
devices for IPV6.
* UpnpGetIfInfo(): gua/ula issues.
Patch submitted by Ronan Menard.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@565 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Hello,
When my patch for tracker ID 3007407 was accepted, the definition of the
serviceList string was changed from
#define SERVICELIST_STR "serviceList"
to
static const char *SERVICELIST_STR = "serviceList";
During internal code review of the final patch, it was pointed out that
sizeof(SERVICELIST_STR) == 4 since SERVICELIST_STR is now declared as
a pointer instead of an array.
If you wish to use a variable instead of a define, I suggest the
following instead:
static const char SERVICELIST_STR[] = "serviceList";
Thanks,
Chuck Thomason
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@556 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted: Chuck Thomason ( cyt4 ) - 2010-05-26 15:07:39 UTC
When the UPnP server is started, one alive message is broadcast for each
service in each device. It appears that libupnp's implementation of the
alive message generation does not correctly navigate the XML description
document when locating the services. This can result in the wrong UDN
being used in the alive message sent for a service.
In my specific case (see attached XML), the root EchoSTB device contains
no services, but its embedded MediaServer device contains 2 services.
When the existing libupnp code traverses the EchoSTB device in the XML,
it searches the global list of serviceLists within the document instead
of searching for a serviceList that is its direct child node. The
ContentDirectory and ConnectionManager services are then announced with
the UDN of EchoSTB1 (the root device) instead of with the UDN of
MediaServer, which is actually their parent device.
I discovered this behavior using libupnp-1.6.6. I have generated a patch
against branch-1.6.x that corrects the XML navigation such that all
services are traversed from their parent device, which results in the
correct UDN being sent in the alive message for each service. I built
from branch-1.6.x without this patch, tested, and confirmed that the
issue still exists as I observed it in libupnp-1.6.6. I then built
from branch-1.6.x with this patch, tested, and confirmed that the
issue was resolved.
Thanks,
Chuck Thomason
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@552 119443c7-1b9e-41f8-b6fc-b9c35fce742c
[svn] SF Bug Tracker [ 2995758 ] libupnp 1.6.6, wrong bind when reuseaddr is 1.
Submitted: viallard anthony ( homer242 )
When trying to use reuseaddr option in miniserver/miniserver.c, there
isn't a affectation of the port chosen (serverAddr.sin_port isn't
receive listen_port variable value).
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@549 119443c7-1b9e-41f8-b6fc-b9c35fce742c
