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/branches/branch-1.6.x@458 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
Submitted By: Glen Masgai
after an UpnpSendActionAsync() for example, i get UPNP_E_OUTOF_MEMORY
in the callback using 1.4.4 on a x86_64 system. This happens in
http_MakeMessage(), which in some cases get called with wrong types
(int instead of size_t) in combination with format "b" and "Q".
The attached patch should fix this.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@166 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Michael Andersen - miwer
Issue was found to be related to sizeof (size_t) != sizeof (int)
on AMD64 systems. Emil Ljungdahl's AMD64 patch has been applied along
with some other fixes. Original user report follows:
When I run upnpd I get the above mentioned error (UPNP_E_OUTOF_MEMORY).
I've tried with 1.4.1 and 1.4.2-RC3, it's the same. I don't understand why,
because I have plenty of RAM, and I even tried closing some applications,
but it didn't help.
$ upnpd eth1 br0
The following is logged in the /var/log/messages:
Feb 6 01:33:47 server upnpd[6933]: Error registering the root device with
descDocUrl: http://192.168.0.1:49152/gatedesc.xml
Feb 6 01:33:47 server upnpd[6933]: UpnpRegisterRootDevice returned -104
I tried enabling debugging and it looks like it cannot allocate memory
through the membuffer_append function. It's wierd because it's only a few
bytes.
Please note, that I enabled some extra debugging lines that were commented,
in order to get more information. See attached files.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@154 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Jonathan - no_dice
Summary: This patch hopefully fixes the remaining types and related
code to enable files >= 2 GiB to be streamed. Jonathan claims to have
tested this with a patched version of ushare-0.9.8 and a D-Link DSM-520.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@121 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Generating an rpm now is as easy as:
$ rpmbuild -ta libupnp-1.4.1.tar.gz
- Added Eric's name to the THANKS file and sorted it in
ascending first name order.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@50 119443c7-1b9e-41f8-b6fc-b9c35fce742c
