Recent changes to bugs

#7 "TimerThreadRemove failed!" message because eventId is garbled

nyet — Wed, 16 Jul 2014 22:58:59 -0000

Sorry. Forgot to mark it as pre.

*** /home/nyet/17-initialize-portmap-struct.patch
--- a/pmlist.c
+++ b/pmlist.c
@@ -18,7 +18,7 @@
                   char *externalPort, char *internalPort,
                   char *protocol, char *internalClient, char *desc)
 {
-   struct portMap* temp = (struct portMap*) malloc(sizeof(struct portMap));
+   struct portMap* temp = (struct portMap*) calloc(1,sizeof(struct portMap));

    temp->m_PortMappingEnabled = enabled;

@@ -35,6 +35,7 @@
    if (strlen(desc) < sizeof(temp->m_PortMappingDescription)) strcpy(temp->m_PortMappingDescription, desc);
        else strcpy(temp->m_PortMappingDescription, "");
    temp->m_PortMappingLeaseDuration = duration;
+   temp->expirationEventId = -1;

    temp->next = NULL;
    temp->prev = NULL;
@@ -212,7 +213,7 @@
        else if (temp == pmlist_Tail) // We are the Tail, but not the Head so we have prev
        {
            pmlist_Tail = pmlist_Tail->prev;
-           free (pmlist_Tail->next);
+           free (temp);
            pmlist_Tail->next = NULL;
            action_succeeded = 1;
        }

"TimerThreadRemove failed!" message because eventId is garbled

nyet — Wed, 16 Jul 2014 22:56:41 -0000

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720495 /home/nyet/17-initialize-portmap-struct.patch
--- a/pmlist.c
+++ b/pmlist.c
@@ -18,7 +18,7 @@
char externalPort, char internalPort,
char protocol, char internalClient, char desc)
{
- struct portMap temp = (struct portMap) malloc(sizeof(struct portMap));
+ struct portMap temp = (struct portMap) calloc(1,sizeof(struct portMap));

temp->m_PortMappingEnabled = enabled;

@@ -35,6 +35,7 @@
if (strlen(desc) < sizeof(temp->m_PortMappingDescription)) strcpy(temp->m_PortMappingDescription, desc);
else strcpy(temp->m_PortMappingDescription, "");
temp->m_PortMappingLeaseDuration = duration;
+ temp->expirationEventId = -1;

temp->next = NULL;
temp->prev = NULL;

@@ -212,7 +213,7 @@
else if (temp == pmlist_Tail) // We are the Tail, but not the Head so we have prev
{
pmlist_Tail = pmlist_Tail->prev;
- free (pmlist_Tail->next);
+ free (temp);
pmlist_Tail->next = NULL;
action_succeeded = 1;
}

upnpd segfaults in libc*.so

Nick Leverton — Sat, 07 Jul 2012 15:57:31 -0000

Reported by some Debian users, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499827

upnpd[10145]: segfault at 7 ip b7e8a0a9 sp b4df81d0 error 4 in
libc-2.7.so[b7e1a000+155000]

Mar 4 07:04:46 rover upnpd[18238]: ExpireMapping: Proto:UDP Port:4500
Mar 4 07:05:26 rover kernel: [476754.504058] upnpd[18241]: segfault at 90d46ee ip b7e6f8f7 sp b6de9bd8 error 4 in libc-2.7.so[b7e05000+138000]

Mar 8 00:57:42 rover upnpd[31797]: ExpireMapping: Proto:UDP Port:5353
Mar 8 00:57:42 rover upnpd[31797]: ExpireMapping: Proto:UDP Port:4500
Mar 8 00:58:27 rover kernel: [800334.797920] upnpd[31805]: segfault at a19072e ip b7eb98f7 sp b4633848 error 4 in libc-2.7.so[b7e4f000+138000]

Mar 11 09:27:36 rover upnpd[31747]: *** glibc detected *** /usr/sbin/
upnpd: malloc(): memory corruption (fast): 0x08198d30 ***

Valgrind logs:

==9510== Thread 12:
==9510== Invalid write of size 4
==9510== at 0x804A0A0: free_expiration_event (gatedevice.c:770)
==9510== by 0x804A42F: ExpireMapping (gatedevice.c:797)
==9510== by 0x404871B: WorkerThread (ThreadPool.c:573)
==9510== by 0x4197F3A: start_thread (pthread_create.c:297)
==9510== by 0x411EBED: clone (in /usr/lib/debug/libc-2.7.so)
==9510== Address 0x434c01c is 108 bytes inside a block of size 124
free'd
==9510== at 0x4021B8A: free (vg_replace_malloc.c:323)
==9510== by 0x804C62A: pmlist_Delete (pmlist.c:206)
==9510== by 0x804A3A4: ExpireMapping (gatedevice.c:788)
==9510== by 0x404871B: WorkerThread (ThreadPool.c:573)
==9510== by 0x4197F3A: start_thread (pthread_create.c:297)
==9510== by 0x411EBED: clone (in /usr/lib/debug/libc-2.7.so)

==7610== Thread 9:
==7610== Invalid read of size 1
==7610== at 0x402377E: strcmp (mc_replace_strmem.c:337)
==7610== by 0x804B895: HandleActionRequest (gatedevice.c:121)
==7610== by 0x804BD92: EventHandler (gatedevice.c:36)
==7610== by 0x403128D: handle_invoke_action (soap_device.c:972)
==7610== by 0x40316D0: soap_device_callback (soap_device.c:1062)
==7610== by 0x40329AC: handle_request (miniserver.c:196)
==7610== by 0x404871B: WorkerThread (ThreadPool.c:573)
==7610== by 0x4197F3A: start_thread (pthread_create.c:297)
==7610== by 0x411EBED: clone (in /usr/lib/debug/libc-2.7.so)
==7610== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==7610==
==7610== Process terminating with default action of signal 11 (SIGSEGV)
==7610== Access not within mapped region at address 0x0

running linux-idg muliple times( pidfiles?)

Anonymous — Mon, 24 May 2010 23:43:16 -0000

hi,
i have setup a router running debian 5.0.4 running linux-igd version 1.0+cvs20070630-2
my problem that i have 2 internal networks, i'll explain:

i have a public ip on eth0
eth1 and eth2 are internal networks

i have copyed /etc/init.d/linux-igd to linux-igd-eth1 and linux-igd-eth2
and editited ther $name=...

same for /etc/default/linux-igd

now it seems that in order to have start-stop-daemon to not look at the prosesname u need to spesify a pidfile linux-igd should create.

i will try to write a patch myself but i want to know what you think off it and if you have other sujections

also let me know if you want to help

See yea

inconsisten iptables calling

Thu, 18 Jun 2009 03:45:14 -0000

In pmlist.c in AddPortMapping, there calls to iptables from execv and iptc are inconsistent when compared against each other. One INSERTS a rule into the forwarding chain, and appends a rule into the prerouting chain, while the other appends into forwards, inserts into nat.

Attached is a fixed version of pmlist.c (Lines 247~300 have been somewhat changed)

incorrect duration=HH:MM regexp in config.c

Takahiro Kurosawa — Wed, 07 Mar 2007 05:39:15 -0000

The "duration=..." regular expression in config.c looks incorrect (at least inconsistent with the description of etc/upnpd.conf).

Each of the hours/minutes part should be exactly 2 digits when we specify the duration in HH:MM format, but the regular expression in config.c is not specified so.

The attached file is the patch that fixes the problem.

Configure script

doclist — Mon, 01 Jan 2007 19:09:43 -0000

Please include a './configure' script (or other configuration script). This makes installation more robust, flexible and vastly easier to package.

getConfigOptionArgument truncates arguments to 3 chars

Chris Butler — Tue, 15 Mar 2005 17:26:35 -0000

In config.c, the function getConfigOptionArgument
truncates all of the options to 3 characters.

This is due to the fact that character arrays are
actually passed as pointers, so sizeof(string) will
always return 4 on 32-bit architechtures, not the size
of the array as you may expect.