Package Details: linuxigd 1.0-9

Git Clone URL: https://aur.archlinux.org/linuxigd.git (read-only)
Package Base: linuxigd
Description: Linux UPnP Internet Gateway Device.
Upstream URL: http://linux-igd.sourceforge.net/
Keywords: igd network upnp
Licenses: GPL
Submitter: None
Maintainer: vinipsmaker
Last Packager: vinipsmaker
Votes: 15
Popularity: 0.000000
First Submitted: 2007-08-04 22:38
Last Updated: 2015-06-25 03:50

Latest Comments

biergaizi commented on 2014-01-23 10:53

The upnpd.service is too buggy and ugly to use, I can not understand the reason of its implementation.

Here is an elegant one:

[Unit]
Description=Linux Internet Gateway Device
Requires=network.target
After=network.target

[Service]
EnvironmentFile=/etc/conf.d/upnpd
ExecStart=/usr/sbin/upnpd -f $EXTERNAL_INTERFACE $INTERNAL_INTERFACE

[Install]
WantedBy=multi-user.target

Happy Hacking!

Anonymous comment on 2013-06-06 16:13

In the build() function of the PKGBUILD change:

From: CFLAGS+=-D_GNU_SOURCE
To: CFLAGS+=\ -D_GNU_SOURCE

i.e. add an escaped space after the +=

BeepDog commented on 2013-06-05 20:57

After having a few problems trying to build this.

Firstly, I couldn't validate the upnpd.conf:
Validating source files with sha256sums...[
linuxigd-1.0.tar.gz ... Passed
igd-iptables-arch.patch ... Passed
igd-install-destdir.patch ... Passed
Makefile.patch ... Passed
upnpd.conf ... /startdir/upnpd.conf: Permission denied
FAILED

I had to change the permissions on that file to 0666 to be able to validate the sha256, which is really strange.

Finally, the build doesn't work:
cc1: error: invalid --param value '4-D_GNU_SOURCE'
cc1: error: invalid --param value '4-D_GNU_SOURCE'
cc1: error: invalid --param value '4-D_GNU_SOURCE'
cc1: error: invalid --param value '4-D_GNU_SOURCE'
make: *** [main.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [pmlist.o] Error 1
cc1: error: invalid --param value '4-D_GNU_SOURCE'

Investigating...

Anonymous comment on 2013-06-03 14:05

Just as a heads-up, this package will need updating for the /usr/bin move. The daemon currently resides in /usr/sbin.

Anonymous comment on 2013-03-28 22:03

@Noread: It looks like upnpd is starting but failing afterwards. My guess would be that you have not configured the multicast route on your internal interface. The netcfg profile was responsible for doing that and you will have to arrange a route if you use another means.

psi-jack commented on 2013-01-07 22:20

Interesting.

Neil, can you detail out what you're doing with your system to have this conflict? Why would a password be required, ultimately, to run this?

Anonymous comment on 2013-01-06 22:02

There is a problem with:

Requires=network.target
After=network.target

and starting the daemon after boot with it prompting for a password on the console. This won't be desirable on a headless system.

Simplifying the above to just:

After=network.target

fixes this problem and will suit pretty-much any usage scenario.

Regards,
Neil Darlow

Anonymous comment on 2013-01-02 21:52

Thanks for picking this package up and maintaining it.

Re. my upnpd.service contribution
1) Good move on using the upnpd.conf file to set interfaces. You can probably remove the comment about changing the interface names in ExecStart.
2) I have replaced netcfg.service with network.target in the After= and Requires= declarations

Regards,
Neil Darlow

psi-jack commented on 2012-12-23 20:26

Updated to use systemd

Anonymous comment on 2012-11-15 07:47

I should correct point 2) of my previous post. pidof will not be in base when sysvinit-tools is removed.

Anonymous comment on 2012-11-14 18:55

I use the following upnpd.service and I should justify two features of it:

1) The multicast route is configured by the internal network interface netcfg profile. This is because netcfg has builtin logic to manage routes and it is a sensible place to do it.

2) StartExecPost looks ugly. Yes it does but it only uses functionality from base. The existing initscript uses pidof which is not in base.

upnpd.service follows:

# This service relies on a netcfg profile that adds a multicast route to the internal interface e.g.:
# ...
# IP=static
# ADDR=192.168.0.1
# ROUTES=('224.0.0.0/4 via 192.168.0.1')
# ...
# Adjust the interface names in ExecStart below to match your external and internal interfaces.

[Unit]
Description=Linux Internet Gateway Device
Requires=netcfg.service
After=netcfg.service

[Service]
Type=forking
PIDFile=/run/%p.pid
ExecStart=/usr/sbin/upnpd eth0 eth1
ExecStartPost=/bin/sh -c "echo -n $(ps -ax |grep -m 1 /usr/sbin/upnpd |awk '{ print $1 }') > /run/%p.pid"

[Install]
WantedBy=multi-user.target

Anonymous comment on 2012-11-04 12:21

Disowning: I am no longer using Arch Linux.

jimmyxu commented on 2012-11-04 04:28

Please add a systemd service file, thanks.

Anonymous comment on 2011-12-18 20:52

Hi, I took ownership of this package, and I implemented the below comments except for cvs. Are the cvs comments still valid? If so then please give me a patch and I will implement it.

heftig commented on 2011-02-17 20:38

Had to do this in order to get it to build:
CFLAGS+=" -D_GNU_SOURCE"
sed -i '1i#include <stdio.h>' gatedevice.c pmlist.c
sed -i '1i#include <string.h>' main.c pmlist.c

Anonymous comment on 2010-12-06 04:57

Your tarball has some issues. Binaries are usually frowned upon. Such as:
linuxigd/igd-startup-script.tgz
Try to find sources for the binaries instead of embedding them. Besides, what is the point to tarballing already compressed files? Please fix this.

Anonymous comment on 2010-10-23 18:52

I marked it as out of date because of changes made in cvs (that propably should be backported as ability to actually insert forward rule at beginning of chain is very useful):

- Renamed the insert_forward_rules option to create_forward_rules to
better reflect what it actually does.
- Added the forward_rules_append to do what people thought
insert_forward_rules did.