This function avoids some unecessary memory allocation.
The memory alloc'd by this function must be freed later by the caller.
(cherry picked from commit 8651174861657b9d99b741b1ffe12ff164284e4e)
Currently, in notify_send_and_recv function, pupnp waits for
HTTP_DEFAULT_TIMEOUT seconds when trying to send a GENA notification.
When there is a lot of notifications with CPs which was disconnected
without unsusbcribing, all the pupnp threads are blocked on this
timeout. To correct, this issue, this patch adds a new variable,
GENA_NOTIFICATION_SENDING_TIMEOUT, which can be used to lower the
timeout so GENA threads return quickly when writing is impossible. By
the same mean, pupnp waits the CP's answer to the NOTIFY for
HTTP_DEFAULT_TIMEOUT seconds, so this patch adds a new variable,
GENA_NOTIFICATION_ANSWERING_TIMEOUT, to customize this value.
(cherry picked from commit e6c548f57a26ef5e681135cf34ea780b95209be8)
Currently, pupnp is using a blocking connect to sends GENA
notifications. As a result, when there is a lot of notifications with
CPs which were disconnected without unsusbcribing, all the pupnp
threads are blocked for 20s (timeout). To correct this issue, this
patch replace the call to connect with a call to private_connect and add
a compilation flag to disable blocking TCP connections, so if we are not
able to connect to the CP, the notification is lost.
(cherry picked from commit 32cffb5bb55a650b1eb962c6fe2e58e6bf4fe2c5)
Currently, in sock_read_write function, if the timeout is 0, pupnp
realizes a "blocking" select (with an infinite timeout). With this
patch, if timeout is set to 0, pupnp will realize a "polling" select
and returns immediately if it can not read or write on the socket. This
is very useful for GENA notifications when pupnp is trying to send
events to a disconnected Control Point. "Blocking" select can now be
done by putting a negative timeout value.
SF Bug Tracker - ID: 3104527
Submitted: OBATA Akio ( obache ) - 2010-11-07 07:10:28 BRST
In threadutil/inc/ithread.h, it is expected that
PTHREAD_MUTEX_RECURSIVE is defined as macro. But on DragonFly BSD,
it is defined as enum, so not works as expected.
Attachment patch treat that DragonFly BSD always
have PTHREAD_MUTEX_RECURSIVE.
(cherry picked from commit ff006272b5cee2b02a50466db8a4b093880d3e76)
SF Bug Tracker - ID: 3104521
Submitted: OBATA Akio ( obache ) - 2010-11-07 07:03:44 BRST
In configure.ac
AC_CHECK_FUNCS(ftime,, [AC_CHECK_LIB(compat, ftime)])
But since version 1.6.3, ftime(3) is not used, so it should be
removed, or introduce unwanted linkage with -lcompat.
(cherry picked from commit 852c301c5c4dda8ad943f3c2b4dbbbc42a418504)
Fix for bug introduced in samples code in svn revision 502, commit
git:25c908c558c8e60eb386c155a6b93add447ffec0
Sample device and combo were aborting with the message:
"***** SampleUtil_Initialize was called multiple times!"
(cherry picked from commit ef7edf6cf8a0f1acafdaecaf09b30aaeaac91d10)
Put the loop to send multiple copies of each SSDP advertisements in
ssdp_server.c instead of ssdp_device.c so we have only one call to
imillisleep ( SSDP_PAUSE ) to speed up advertisements.
(cherry picked from commit c65ec8a720cc3c65b4ca173ea7536d03b0652890)
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
