Adding two new functions (UpnpSendAdvertisementLowPower and
UpnpUnRegisterRootDeviceLowPower) which can be used to specify values
for the three SSDP headers defined by UPnP Low Power. Those headers are
Powerstate, SleepPeriod and RegistrationState.
(cherry picked from commit 98e4f938d6)
Putting all access to ssdpReqSock4 and ssdpReqSock6 under
INCLUDE_CLIENT_APIS compilation flag to be able to compile when
client part of library is disable.
(cherry picked from commit 0996d23318)
Add a new UpnpRegisterRootDevice4 which allow user to specify a
description URL to be returned for legacy CPs (for example, CPs
searching for a v1 when the device is v2). Most of those CPs does not
work if they found a v2 in the XML description, so this new function is
only used to solve interoperability issues.
(cherry picked from commit 11f9a2bafe)
This function uses a ThreadPool object as an argument, which is not
supposed to be exported. Also, debug compilation was broken.
(cherry picked from commit 32e510b45a)
Major bug fix in miniserver.c for IPv6, bug was introduced when
changing implementation of get_port in November 20th 2010 ("gena:fix
several compiler warnings" commit).
(cherry picked from commit 063d472f80)
The files FreeList.h, LinkedList.h, ThreadPool.h and TimerThread.h
from the threautil library were being installed in the include
directory of the library, incorrectly exposing internal data structure
of the library.
(cherry picked from commit 0bbe9f62df)
Add 'requiredThreads' field to the ThreadPool structure, to avoid
a race condition when waiting for a new thread to be created. The
race condition occurs when a thread is destroyed while the master
thread is waiting for a new thread to be created.
Thanks to Chuck Thomason for pointing the problem.
Summary: Race condition can hang miniserver thread - ID: 3158591
Details:
Hello,
I have found a race condition in the thread pool handling of
libupnp-1.6.6 that periodically results in the miniserver thread
getting blocked infinitely.
In my setup, I have the miniserver thread pool configured with 1
job per thread, 2 threads minimum, and 50 threads maximum.
Just before the lockup occurs, the miniserver thread pool contains
2 threads: one worker thread hanging around from a previous HTTP
request job (let's call that thread "old_worker") and the
miniserver thread itself.
A new HTTP request comes in. Accordingly, the miniserver enters
schedule_request_job() and then ThreadPoolAdd(). In
ThreadPoolAdd(), the job gets added to the medium-priority queue,
and AddWorker() is called. In AddWorker(), jobs = 1 and threads =
1, so CreateWorker gets called.
When we enter CreateWorker(), tp->totalThreads is 2, so
currentThreads is 3. The function creates a new thread and then
blocks on tp->start_and_shutdown. The miniserver thread expects
the newly created thread to increment tp->totalThreads and then
signal the condition variable to wake up the miniserver thread and
let it proceed.
The newly created thread starts in the WorkerThread() function. It
increments tp->totalThreads to 3, does a broadcast on the
start_and_shutdown condition, and starts running its job. However,
before the miniserver thread wakes up, "old_worker" times out. It
sees that there are no jobs in any queue and that the total number
of threads (3) is more than the minimum (2). As a result, it
reduces tp->totalThreads to 2 and dies.
Now the miniserver thread finally wakes up. It checks
tp->totalThreads and sees that its value is 2, so it blocks on
tp->start_and_shutdown again. It has now "missed" seeing
tp->totalThreads get incremented to 3 and will never be unblocked
again.
When this issue does occur for a server device, the miniserver
port remains open, but becomes unresponsive since the miniserver
thread is stuck. SSDP alive messages keep getting sent out, as
they are handled by a separate thread. Reproducing the issue is
difficult due to the timing coincidence involved, but in my
environment I am presently seeing it at least once a day. I
figured out the sequence described above through addition of my
own debug logs.
The relevant code involved in this bug has not changed
substantially in libupnp-1.6.10, though I am planning to test
against 1.6.10 as well in the near future.
Do you have any input for an elegant fix for this issue?
Thanks,
Chuck Thomason
(cherry picked from commit c4e9757bcf)
Make these definitions available to programs using the library.
Thanks to Chandra Penke for pointing the problem.
(cherry picked from commit abfa841318)
Details:
Hello. I trying compile libupnp-1.6.10 on the Fedora 14 MinGW
Environment and get many errors. I create patch to fix it. With this
patch i can get static library. This patch is very raw.
Submitted: Ivan Romanov (ivanromanov) - 2010-12-16 23:29:19 UTC
(cherry picked from commit b2a88aa70b)
Currently, http_SendMessage was not able to write to write a buffer
due to a bad use of file_buf instead of buf. This bug was introduced by
the 0197-Doxygen-reformating-compiler-warnings patch.
(cherry picked from commit 2c3bce13bd)
Currently, Upnp_Event_Subscribe always contains an empty chain in the
Sid parameter. This patch now saves the client Subscription ID in this
parameter so Control Points can see and use the same SID in the
Upnp_Event_Subscribe and in the Upnp_Event structures.
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 8651174861)
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 e6c548f57a)
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 32cffb5bb5)
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 ff006272b5)
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 852c301c5c)
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 ef7edf6cf8)
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 c65ec8a720)
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 2d22e997e1)
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 96dc968f18)
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 8e846368e0)
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 2bdc9e075e)
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 f74746ff3f)
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 c73d870f46)
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 ab54cb3dc5)
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 c33b11d09f)
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 4966423d96)
Add Content-Language header in the response if and only if there is an Accept-Language header in the request.
Manually ported from revision d2238615e3.
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 2fcbe6df52)
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 467f9987a1)
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 55d581481f)
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 25a4bd6d25)
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 2b3ab1799b)
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 4657e57766)
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 21660334e4)
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 ebc941f265)
* 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
Thanks for the load of updates, I'm still assimilating them ! Could I make
a suggestion though? The addition of printNodes(IXML_Node) to upnpdebug a
dds a new dependency on ixml.h for anything using upnpdebug.h. I'm making
quite a bit of use of upnpdebug in porting things to version 1.8.0, and I'd
prefer it if printNodes could be added to ixmldebug.h instead. I'm attach
ing a patch, what do you think ?
Nick
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@532 119443c7-1b9e-41f8-b6fc-b9c35fce742c
- int ithread_initialize_library(void);
- int ithread_cleanup_library(void);
- int ithread_initialize_thread(void);
- int ithread_cleanup_thread(void);
* SF Bug Tracker [ 2876374 ] Access Violation when compiling with Visual Studio 2008
Submitted: Stulle ( stulleamgym ) - 2009-10-10 19:05
Hi,
I am one of the devs of the MorphXT project and I use this lib in some
other of my projects, too. When I tried to upgrade the lib earlier for one
of my projects I had to realise that something did not work at first and
while most of the things were reasonably ease to be fixed. Now, the last
thing I encountered was not so easy to fix and I am uncertain if my fix is
any good so I'll just post it here and wait for some comments.
The problem was that I got an Access Violation when calling "UpnpInit". It
would call "ithread_rwlock_init(&GlobalHndRWLock, NULL)" which eventually
led to calling "pthread_cond_init" and I got the error notice at
"EnterCriticalSection (&ptw32_cond_list_lock);". It appeared that
"ptw32_cond_list_lock" was NULL. Now, I found two ways to fix this. Firstly
moving the whole block after at least one of the "ThreadPoolInit" calls
will fix the issue. Secondly, you could add:
#ifdef WIN32
#ifdef PTW32_STATIC_LIB
// to get the following working we need this... is it a good patch or
not... I do not know!
pthread_win32_process_attach_np();
#endif
#endif
right before "ithread_rwlock_init(&GlobalHndRWLock, NULL)".
Just so you know, I am using libupnp 1.6.6 and libpthreads 2.8.0 and both
are linked static into the binaries. I am currently using Visual Studio
2008 for development with Windows being the target OS. Any comment at your
end?
Regards, Stulle
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@527 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Patch Tracker [ 2836704 ] Patch for Solaris10 compilation and usage.
Submitted By: zephyrus ( zephyrus00jp )
This second part covers the issue on linking with -lsocket -lnsl -lrt.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@526 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* SF Bug Tracker [ 2392166 ] ithread_detach not called for finished worker thread
Submitted: Ulrik ( ulsv_enea ) - 2008-12-05 08:24
Valgrind reports a memory leak due to that the function ithread_detach is
not called for finished worker threads in ThreadPool.c.
==21137== 2,176 bytes in 8 blocks are possibly lost in loss record 5 of 5
==21137== at 0x4C20F3F: calloc (vg_replace_malloc.c:279)
==21137== by 0x4010F58: _dl_allocate_tls (in /lib/ld-2.6.1.so)
==21137== by 0x544BA92: pthread_create@@GLIBC_2.2.5 (in
/lib/libpthread-2.6.1.so)
==21137== by 0x5F94592: CreateWorker (ThreadPool.c:639)
==21137== by 0x5F95079: ThreadPoolInit (ThreadPool.c:784)
I'm using libupnp 1.6.6
For more info on pthread_detach, see:
http://gelorakan.wordpress.com/2007/11/26/pthead_create-valgrind-memory-lea
k-solved/
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@521 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* SF Bug Tracker [ 2392304 ] Memory leak in SSDP AdvertiseAndReply
Submitted: Ulrik ( ulsv_enea ) - 2008-12-05 08:24
Valgrind reports a memory leak function in AdvertiseAndReply
(ssdp/ssdp_server.c) in libupnp 1.6.6
There are continue statements in many places in AdvertiseAndReply. In some
of those error handling cases the variable nodelist is not free'ed before
continuing to the next iteration. The next iteration will take care of
free'ing the nodelist from the previous iteration in most cases, but not
when breaking out of the for loop after the last element.
I belive this memory leak can be solved by makeing sure that the rows
ixmlNodeList_free( nodeList );
nodeList = NULL;
are always executed, also in the beginning of the last iteration when we
found out that there are not more elements.
==29110== at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==29110== by 0x5D8DE0E: ixmlNodeList_addToNodeList (nodeList.c:106)
==29110== by 0x5D8B7E2: ixmlNode_getElementsByTagNameRecursive
(node.c:1438)
==29110== by 0x5D8E587: ixmlElement_getElementsByTagName
(element.c:491)
==29110== by 0x5B6C0F1: AdvertiseAndReply (ssdp_server.c:201)
==29110== by 0x5B7AB74: UpnpSendAdvertisement (upnpapi.c:1495)
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@519 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submited by Carlo Parata from STMicroelectronics.
Hi Roberto and Nektarios,
after an analysis of the problem of libupnp with a multi-flows scenario, I
noticed that the only cause of the freezed system is the ThreadPool
management. There are not mutex problems. In practise, if all threads in the
thread pool are busy executing jobs, a new worker thread should be created if
a job is scheduled (I inspired to tombupnp library). So I solved the problem
with a little patch in threadutil library that you can find attached in this
e-mail. I hope to have helped you.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@514 119443c7-1b9e-41f8-b6fc-b9c35fce742c
...blah... with...
Submitted: Nick Leverton ( leveret ) - 2010-03-07 05:18
Full error:
/usr/bin/install: will not overwrite just-created
`/tmp/buildd/libupnp-1.6.6/debian/tmp/usr/share/doc/libupnp3-dev/examples/s
ample_util.c' with `common/sample_util.c'
This seems to be from Automake 1.11 which doesn't like having duplicate
files in a Makefile.am. Patch attached, kindly provided by Stefan Potyra
for Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543068)
This fix will be needed for both 1.6.x and 1.8.x branches.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@510 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Patch Tracker [ 2836704 ] Search for nested serviceList (not
stopping at the first lis
Submitted By: zephyrus ( zephyrus00jp )
Internet Gateway Device description contains nested serviceList (rootdevice
-> servicelist, subdevice
and subdevice has the lower-level serviceList, etc..)
Unfrotunately, the sample code sample_util.c used by tv_device sample,
etc.
has a code that looks for only the first top-level serviceList.
This results in the failure to read all the services of an IGD xml
description.
Attached patch modifies this behavior and looks for the service by
visiting all the serviceList in xml document in turn.
With the modified patch (ad additional modification), I could
simulate an IGD device and created a modified control program for that.
Patch against 1.6.6
TIA.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@503 119443c7-1b9e-41f8-b6fc-b9c35fce742c
code list
Submitted By: Nick Leverton ( leveret )
ErrorMessage[] in upnptools.c has got a bit out of sync, the attached
patch (generated from grep 'define UPNP_E_') should bring it up to date.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@495 119443c7-1b9e-41f8-b6fc-b9c35fce742c
(void) argument list.
Submitted By: zephyrus ( zephyrus00jp )
In a publicly installed headers, a few functions are declared without any
arguments at all, a la "()".
When I used gcc's -Wimplict and -Wstrict-prototypes to check for the
mismatch of
function prototype declarations and their usage in my own program,
some headers from libupnp-1.6.6 produced warnings.
They are not strictly bugs, but pretty much annoying. This is 2009, and
almost all the important compilers
understand ISO-C.
So the offending functions are declared as "(void") to show that they have
no arguments at all.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@493 119443c7-1b9e-41f8-b6fc-b9c35fce742c
too-short renewal interval
Submitted By: Nick Leverton (leveret)
Auto-renewals send an invalid SID due to a missing UpnpString_get_String
call. They also send a renewal interval of 0 instead of copying it from
the original subscription.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@492 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Seems like SF's tracker won't let me add a patch to someone else's issue ?!
This refers to https://sourceforge.net/support/tracker.php?aid=2724578
The calls to inet_ntoa are in getlocalhostname(), which is called from
UpnpInit when it is returning the bound IP address.
UpnpInit/getlocalhostname hasn't been updated to IPv6, I presume this is
deliberate so that it doesn't start returning IPv6 addresses and
overwriting the caller's IPv4-sized allocation.
The attached patch just updates getlocalhostname to use inet_ntop instead
of inet_ntoa, and also documents the fact that UpnpInit is IPv4 only whilst
UpnpInnit2 is both IPv4 and IPv6.
A fuller solution might be to change UpnpInit to use some variant on
UpnpGetIfInfo. UpnpInit could still be left as IPv4 only if desired -
perhaps UpnpGetIfInfo could take an option for the desired address family.
getlocalhostname and its own copy of the interface scanning code would then
be redundant. I don't have IPv6 capability here though so I'm reluctant to
change the IPv6 code, as I have no way to test it.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@491 119443c7-1b9e-41f8-b6fc-b9c35fce742c
add devices.
each time a device been added, UpnpInit() is called, on exit, UpnpFinish()
is called, but the memories allocated by ThreadPoolInit() may lost because
there's no code to call ThreadPoolShutdown() to release the memories. And
inet_ntoa() is not thread safe, so in my patch, I substitute inet_ntoa()
with inet_ntop().
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@489 119443c7-1b9e-41f8-b6fc-b9c35fce742c
object API
As per email to pupnp-devel, this is the patch to add the _strget_
accessors for string-like objects in the interface.
Will add a further patch shortly to udpate the sample programs.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@488 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SOAPACTION and User-Agent headers.
There is something going wrong in soap_ctrlpt.c at line 931 (based on
version 1.6.6 release).
The http_Makemessage call looks as follows:
if (http_MakeMessage(
&request, 1, 1,
"Q" "sbc" "N" "s" "s" "Ucc" "sss",
SOAPMETHOD_POST, path.buf, path.length,
"HOST: ", host.buf, host.length,
content_length,
ContentTypeHeader,
"SOAPACTION:
\"urn:schemas-upnp-org:control-1-0#QueryStateVariable\"",
xml_start, var_name, xml_end ) != 0 ) {
return UPNP_E_OUTOF_MEMORY;
}
This will result in the SOAPACTION header to be immediately followed by the
User-Agent header, while a cr-lf should separate the two. I propose to fix
this by changing the second "s" to "sc" to force the addition of a cr-lf
after the SOAPACTION. This looks consistent to the other Makemessage calls.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@484 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Nick Leverton - leveret
Gnu/KFreeBSD is one of the Debian architectures, it includes a FreeBSD
kernel with GNU userspace (glibc etc). The Gnu/KfreeBSD developers
provided the attached patch to test the appropriate #define and allow pupnp
to build in their environment, and asked me to forward it to you.
Since the test is a simple check for defined(__GLIBC__), this would
presumably also help with other ports of GNU libc to non-Linux kernels.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@457 119443c7-1b9e-41f8-b6fc-b9c35fce742c
The fact that we now have an active developer on branch ipv6 made me do this before I would like to.
The idea here is to hide libupnp internal data structures from the outside world so that
developers can be free to change them without breaking the interface. There is still some work to do
before a formal release, but the samples (device and control point) should be working.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@353 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Thomas Norheim - kjakan_no
Device no longer segfaults with the following malformed xml action:
<u:SetColor xmlns:U="urn:schemas-upnp-org:service:tvpicture:1">
<Color>2</Color>
</u:SetColor>
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@348 119443c7-1b9e-41f8-b6fc-b9c35fce742c
upnp/sample/tvdevie and upnp/sample/tvcombo directories. The variable
port was a short int instead of an unsigned short and it was beeing
print as a negative value.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@332 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By Luke Kim - nereusuj
Version 1.6.5 cannot be compiled because of some changes in 1.6.3.
MSVC does not support stdint.h, gettimeofday(), sys/param.h, const int
variables in array size and Windows does not define _WINDOWS_ but define
_WINDOWS.
* MSVC does not understand "const int"'s as declarators of array
dimensions, we must use #define'd constants.
* Use WIN32 instead of _WINDOWS_ or _WINDOWS.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@331 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Hartmut Holzgraefe - hholzgra
typo in docs comment ACCAPTED instead of ACCEPTED in
@name UPNP_E_UNSUBSCRIBE_UNACCAPTED [-302]
Also, the documentation file name was mispelled and was corrected in
the Makefile.am.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@287 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Define _GNU_SOURCE if needed. The fallback behaviou will only be
implemented if _GNU_SOURCE prooves to be insufficient on some
platforms.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@274 119443c7-1b9e-41f8-b6fc-b9c35fce742c
rwlock. HandleLock() is mapped to HandleWriteLock() while all other
instances have not been checked. One instance in AdvertiseAndReply()
has been changed to HandleReadLock(). Thanks to Alex (afaucher) for the
bug report and suggestions.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@233 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Luke Kim - nereusuj
Worker thread still alive after calling UpnpFinish() because
ThreadPoolShutdown() is in the #ifdef DEBUG block.
421
422 #ifdef DEBUG
423 ThreadPoolShutdown( &gSendThreadPool );
424 ThreadPoolShutdown( &gRecvThreadPool );
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@228 119443c7-1b9e-41f8-b6fc-b9c35fce742c
to (virtualDirCallback.open)(filename, UPNP_WRITE) (notice the
parenthesis) due to a change in glibc that produces compilation
errors.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@223 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Bug Tracker [ 1686420 ] Modifications for MacOSX.
Some of the proposed changes were already done by Rene Hexel's patch.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@213 119443c7-1b9e-41f8-b6fc-b9c35fce742c
ax_cflags_warn_all.m4, m4/ax_cflags_warn_all_ansi.m4,
m4/type_socklen_t.m4.
* Fixed an issue with the instalation of the file upnpdebug.h. Since
the last modifications that removed the macro DEBUV_ONLY, this file
must be installed even on a non-debug build.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@204 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Bob Ciora
The field DestAddr of the structure Upnp_Discovery is now a full
SOCKADDRIN instead of a pointer to SOCKADDRIN. Commented code sugests
that in a previous moment, the function ssdp_handle_ctrlpt_msg() did
not use a postponed thread to call ctrlpt_callback(). Now the code
uses a thread, and most probably the original data would get lost and
the pointer would point to an invalid memory region. This fix caused
an interface change in the library and the minor library version was
bumped. Also, the libtool library numbers were changed accordingly.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@203 119443c7-1b9e-41f8-b6fc-b9c35fce742c
defines. These were just aliases, no reason to keep them.
* Changed the comments of the include files that expose the UPnP API
to use only C89 comments and no C99 comments.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@198 119443c7-1b9e-41f8-b6fc-b9c35fce742c
compatible with WinXP/IE control point. 'in' arguments must appear before
'out' arguments in argument list.
Thanks to Martin Tremblay for pointing out the solution originally
provided by MORIOKA Yasuhiro.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@193 119443c7-1b9e-41f8-b6fc-b9c35fce742c
