UPnP support
-
There is still a bug where it is resyncing packages twice causing issues. It you look at the log it takes longer for miniupnpd to exit than it does for the new one to start. Is there a way to make killall miniupnpd in the miniupnpd.sh file wait until it actually exits before proceeding?
Oct 7 00:58:56 check_reload_status: updating dyndns
Oct 7 00:58:42 check_reload_status: reloading filter
Oct 7 00:58:42 miniupnpd[1106]: Failed to open socket for SSDP. EXITING
Oct 7 00:58:42 miniupnpd[1106]: bind(udp): Address already in use
Oct 7 00:58:42 miniupnpd[1092]: received signal 15, exiting
Oct 7 00:58:35 php: : Resyncing configuration for all packages.
Oct 7 00:58:30 php: : Creating rrd graph index
Oct 7 00:58:30 php: : Creating rrd update script
Oct 7 00:58:30 php: : Informational: DHClient spawned /etc/rc.newwanip and the new ip is wan - 68.100.53.135.
Oct 7 00:58:21 login: login on console as root
Oct 7 00:58:01 sshlockout[868]: sshlockout starting up
Oct 7 00:58:01 sshlockout[868]: sshlockout starting up
Oct 7 00:58:01 login: login on console as root
Oct 7 00:57:50 check_reload_status: rc.newwanip starting
Oct 7 00:57:50 check_reload_status: check_reload_status is starting
Oct 7 00:57:44 miniupnpd[804]: received signal 15, exiting
Oct 7 00:57:44 miniupnpd[820]: Failed to open socket for SSDP. EXITING
Oct 7 00:57:44 miniupnpd[820]: bind(udp): Address already in use
Oct 7 00:57:43 miniupnpd[804]: Unknown soap method
Oct 7 00:57:43 miniupnpd[804]: Unknown soap method
Oct 7 00:57:37 dnsmasq[567]: reading /var/dhcpd/var/db/dhcpd.leases
Oct 7 00:57:36 php: : Resyncing configuration for all packages. -
Hopefully both problems have been addressed now.
-
Yep you got them. Works great.
-
I was wondering if you'd be willing to commit this to the miniupnpd.inc file. Instead of just waiting blindly it checks and loops until all the miniupnpd processes are killed. I have tested it and it works.
It counts the number of lines returned by ps relating to /usr/local/sbin/miniupnpd. If its not equal to 0 then we know miniupnpd is still running.
$start = "# Clear existing rules and rdr entries \n";
$start .= "/sbin/pfctl -aminiupnpd -Fr 2>&1 >/dev/null\n";
$start .= "/sbin/pfctl -aminiupnpd -Fn 2>&1 >/dev/null\n";
$start .= "/usr/bin/killall miniupnpd\n";
$start .= "while [ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l!= 0 ]; do sleep 1; done\n";
$start .= "/usr/local/sbin/miniupnpd -p 2869{$ifaces_final}"; -
One more adition to miniupnpd.inc that I found usefull on mine. We only need to run the start_service command if the serivce is not running or if the user changes the settings.
Othewise everytime the wan dhcp is updated the service is restarted. This is unecessary as only the wan interface NAME is used not the IP. For the -o override the ip is going to be static so it won't change. Plus it causes downtime with apps and game consoles, which can be bothersome.
Also this speeds up the boot process as the service won't be restarted numerous times. It starts once and gets restarted once when the rc file is called.
/* if not ONE instance running lets start /
/ or if $_POST data as user is changing settings */
if((int)exec("ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l") != 1 || $_POST['interface_array']) {
start_service("miniupnpd");
}EDIT – I spoke to soon its still restarting when dhcp renewed. Wonder where it is getting called from? I'm using the following code
/* if not ONE instance running lets start /
/ or if $_POST data as user is changing settings */
if((int)exec("ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l") != 1 || $_POST['interface_array']) {
log_error("miniupnpd resync package: start");
start_service("miniupnpd");
} else {
log_error("miniupnpd resync package: none");
}and am getting this in my log
Oct 7 16:08:19 miniupnpd[4067]: Unknown soap method
Oct 7 16:08:17 check_reload_status: reloading filter
Oct 7 16:08:16 miniupnpd[3242]: received signal 15, exiting
Oct 7 16:08:15 php: : miniupnpd resync package: none
So I wonder where its getting called from. Reguardless it would've restarted twice instead of once without it -
Provide a patch in diff -rub format for all of your recent posts. At this point its becoming hard to follow you.
-
Provide a patch in diff -rub format for all of your recent posts. At this point its becoming hard to follow you.
I think this is what you want.
miniupnpd.inc
36a37 > 40c41,43 < $start .= "killall miniupnpd; sleep 3; /usr/local/sbin/miniupnpd -p 2869{$ifaces_final}"; --- > $start .= "/usr/bin/killall miniupnpd\n"; > $start .= "while [ `ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l` != 0 ]; do sleep 1; done\n"; > $start .= "/usr/local/sbin/miniupnpd -p 2869{$ifaces_final}"; 57c60,66 < start_service("miniupnpd"); --- > > /* if not ONE instance running lets start */ > /* or if $_POST data as user is changing settings */ > if((int)exec("ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l") != 1 || $_POST['interface_array']) { > start_service("miniupnpd"); > } > 61c70 < ?> \ No newline at end of file --- > ?> -
diff -rub
-
diff -rub
Sorry here it is again.
--- miniupnpd.inc 2006-10-07 16:23:47.000000000 -0400 +++ miniupnpdnew.inc 2006-10-07 16:28:13.000000000 -0400 @@ -37,7 +37,9 @@ $start = "# Clear existing rules and rdr entries \n"; $start .= "/sbin/pfctl -aminiupnpd -Fr 2>&1 >/dev/null\n"; $start .= "/sbin/pfctl -aminiupnpd -Fn 2>&1 >/dev/null\n"; - $start .= "killall miniupnpd; sleep 3; /usr/local/sbin/miniupnpd -p 2869{$ifaces_final}"; + $start .= "/usr/bin/killall miniupnpd\n"; + $start .= "while [ `ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l` != 0 ]; do sleep 1; done\n"; + $start .= "/usr/local/sbin/miniupnpd -p 2869{$ifaces_final}"; /* override wan ip address, common for carp, etc */ if($overridewanip) @@ -54,7 +56,13 @@ ) ); } + + /* if not ONE instance running lets start */ + /* or if $_POST data as user is changing settings */ + if((int)exec("ps -A | grep /usr/local/sbin/miniupnpd | grep -v grep | wc -l") != 1 || $_POST['interface_array']) { start_service("miniupnpd"); + } + config_unlock(); conf_mount_ro(); } -
Commited. Thanks.
-
Excellent work everybody.
I've paid my $50 through bradenmcg. It was sent to the general project with the instructions to distribute it as seen fit.
I've yet to try the latest miniupnpd builds or even RC3 for that matter. At the moment my main PC and server/domain controller are in peices all over my living room floor being upgraded. Hopefully this weekend it'll be up and running and I can give the latest code a try.
Keep up the good work!!
UPnP support is going to be a huge feature for the DIY crowd.
Thanks!!
Riley -
I also donated another $50 as promised in the initial post… I sent both mine and Skud's to the project since I know there have been several people working on this now after databeestje did the initial stuff and I wanted to let you guys distribute it as you see fit. :)
It's still a pain in the ass to install on embedded though - that's the last thing I'd like to see resolved but I understand if it doesn't make it to 1.0 final. As long as there is some way (even unsupported) to make it work on embedded I stay happy. :D
-
i just used this script to update my miniupnp on my soekris to the 13 oct 18:30 uhr version
it will get the files from the pfsense packages server and move them to the correct maps/etc/rc.conf_mount_rw cd /tmp/ mkdir upnp cd upnp fetch http://pfsense.org/packages/config/miniupnpd/miniupnpd.inc mv -f miniupnpd.inc /usr/local/pkg/miniupnpd.inc chmod 755 /usr/local/pkg/miniupnpd.inc fetch http://pfsense.org/packages/config/miniupnpd/miniupnpd.xml mv -f miniupnpd.xml /usr/local/pkg/miniupnpd.xml chmod 755 /usr/local/pkg/miniupnpd.xml fetch http://pfsense.org/packages/config/miniupnpd/status_upnp.php mv -f status_upnp.php /usr/local/www/status_upnp.php chmod 755 /usr/local/www/status_upnp.php fetch http://pfsense.org/packages/config/miniupnpd/sbin/miniupnpd mv -f miniupnpd /usr/local/sbin/miniupnpd chmod 755 /usr/local/sbin/miniupnpd cd .. rmdir upnp /etc/rc.conf_mount_ro -
@bradenmcg:
It's still a pain in the ass to install on embedded though - that's the last thing I'd like to see resolved but I understand if it doesn't make it to 1.0 final. As long as there is some way (even unsupported) to make it work on embedded I stay happy. :D
I added the miniupnpd files to the 1.0-RELEASE image.
http://wgnrs.dynalias.com:81/pfsense/pfSense-Embedded-1.0-RELEASE-Miniupnpd.img.gz
I also updated the script sh-custom-image.sh for 1.0-RELEASE see
http://forum.pfsense.org/index.php/topic,1788.msg13972.html#msg13972
-
Very cool, thanks rsw686!
I'm guessing that from RC3 I can't upgrade to 1.0 final, right? Need to pull the CF out of the box again and flash?
-
@bradenmcg:
Very cool, thanks rsw686!
I'm guessing that from RC3 I can't upgrade to 1.0 final, right? Need to pull the CF out of the box again and flash?
I thought I saw an upgrade, but honestly since your going from prerelease to an actual release I would just flash it.
-
Upgrades are available at the mirrors too: http://pfsense.com/mirror.php?section=updates
-
I thought I saw an upgrade, but honestly since your going from prerelease to an actual release I would just flash it.
On your recommendation I reflashed with your pre-built embedded miniupnp image…
It's working, but I'm getting a couple odd behaviors on startup.
During boot, the synching packages/startup scripts runs miniupnp.sh twice in a row. Is this by design?
The other thing I'm seeing is that on the console, the menu system comes up and sits for a while, and then I see the message "Terminated" and the menu redisplays itself.
I imagine there's something going on behind the scenes but i'm not seeing anything in the syslog, at least not through the web.
-
@bradenmcg:
I thought I saw an upgrade, but honestly since your going from prerelease to an actual release I would just flash it.
On your recommendation I reflashed with your pre-built embedded miniupnp image…
It's working, but I'm getting a couple odd behaviors on startup.
During boot, the synching packages/startup scripts runs miniupnp.sh twice in a row. Is this by design?
The other thing I'm seeing is that on the console, the menu system comes up and sits for a while, and then I see the message "Terminated" and the menu redisplays itself.
I imagine there's something going on behind the scenes but i'm not seeing anything in the syslog, at least not through the web.
The two miniupnp.sh scripts starting is a bug in 1.0-RELEASE. See http://cvstrac.pfsense.com/tktview?tn=1124 It should say stopping miniupnpd.sh and then starting miniupnpd.sh. The stop / start code is right but the message displayed is wrong.
Looks like this right
Executing rc.d items…
Starting /usr/local/etc/rc.d/miniupnpd.sh...
done.
Starting /usr/local/etc/rc.d/miniupnpd.sh...
done.Not sure on the menu issue, but thats not from miniupnpd. Everything is the same as the 1.0-RELEASE image except for the miniupnpd files and the miniupnpd installed packages section in the config. The files don't modify the system files, they are just added to the proper directorys just as if you installed it from the package manager.
How long does it take to say terminated. I'm assuming this is on the serial console as its the embedded image. You using hyperterminal in windows or some other terminal program. I am actually curious if mine does that as well. I just never leave it open.
EDIT:
I just looked at status.php in DMESG. I am getting the terminated. Must be something changed in 1.0-RELEASE as I don't remember seeing that before.
Enter an option:
TerminatedThe Terminated is the /etc/rc.initial script being terminated and then restarted since it is in a loop. Something is killing the process.
-
You know the terminated on the console issue isn't a bug. Mine shows terminated 4 times in dmesg on the status.php page. However it looks to be linked to the dhcp renewal on the wan interface. Which makes sense as the menu shows the current ip address for the WAN interface so it gets termianted and restarted to reflect the current WAN IP.