UPnP support

rsw686

I have just commited these changes.

Added -o WAN override option

Now defaults to status page

If not setup prior, redirects to settings tab

What flags the page to know if its setup prior or not. I just grabbed the latest files again and reflashed my device. Now on the status page it shows the tabs and on the settings page I have the wan override box. However it still shows the settings page when clicking miniupnpd, even hitting change on the settings page.

I see this line

['installedpackages']['miniupnpd']['config']

Does that point to the config xml file? I'm almost positive it does. I just did a backup of the config file from the webgui and I have the miniupnpd config section sepcifing the interface_arry.

sullrich

Go to System -> Packages -> Installed -> Click reinstall for miniupnpd.

I just commited something a few minutes ago.

rsw686

Okay will do that. Is there a way to kill the firewall log entries for the upnp mapped ports. Azereus fills up the log real quick.

sullrich

Looks like the logging flag is being enabled in the rule. It should be trivial to turn off but the binary will need to be recompiled, etc.

pass in log quick on fxp0 inet proto udp from any to any port = 30492 keep state label "Azureus UPnP 30492 UDP"

Seth, is this something you want to handle?

rsw686

@sullrich:

Looks like the logging flag is being enabled in the rule. It should be trivial to turn off but the binary will need to be recompiled, etc.

pass in log quick on fxp0 inet proto udp from any to any port = 30492 keep state label "Azureus UPnP 30492 UDP"

Seth, is this something you want to handle?

While your recompiling the binary the other issue is that no nat reflection rules are being created eventhough i have the disable nat reflection box unchecked. This would be really nice to have fixed. As with Azereus if I want to host trackers I can't check them from my house. It also makes Azereus think its behind a "firewall" due to it not being able to see itself.

sullrich

@rsw686:

While your recompiling the binary the other issue is that no nat reflection rules are being created eventhough i have the disable nat reflection box unchecked. This would be really nice to have fixed. As with Azereus if I want to host trackers I can't check them from my house. It also makes Azereus think its behind a "firewall" due to it not being able to see itself.

Really sorry but this will not be fixed. Reflection is a mess as it is and I am not adding that complexity to something like this since we are on the road to being released.

rsw686

@sullrich:

@rsw686:

While your recompiling the binary the other issue is that no nat reflection rules are being created eventhough i have the disable nat reflection box unchecked. This would be really nice to have fixed. As with Azereus if I want to host trackers I can't check them from my house. It also makes Azereus think its behind a "firewall" due to it not being able to see itself.

Really sorry but this will not be fixed. Reflection is a mess as it is and I am not adding that complexity to something like this since we are on the road to being released.

I understand the focus is on clearing up whatever bugs are left. Let me ask this though, if nat reflection was to be added to upnp it would be in the miniupnpd binary, correct? Since I have some free time (college student) I would like to attempt to make the modifications my self for my own learning. Is the source available for this binary and where? Thanks for your help.

sullrich

No, that would be in the pfSense code which is frozen. The only reason your even seeing this package is because its a package and doesnt touch the main code besides a simple table.

databeestje

That's weird. Cause it works for me.

sullrich

There definately is some race conditions present in miniupnpd:

82817 root 1 130 0 1892K 416K RUN 544:53 44.78% miniupnpd

I should note that nothing is even using it right now!

Superman

I just happened to be quickly browsing the miniupnpd homepage, and noticed that this updated source is now available: miniupnpd20060930.tar.gz.

Here's the changelog since 20060919:

2006/09/29:
  Improved compliance of the XML Descriptions
  pretty print for testupnpdescgen

2006/09/25:
  improved the Error 404 response.
  Better serviceType and serviceId for dummy service...

2006/09/24:
  updating the XML description generator

Just in case anyone needed this info.

I would like to compile the binary and try it out myself, but not being a developer I don't know exactly how to go about it. I tried the few things I know but I couldn't get it to compile properly.

rsw686

Well miniupnpd is broken in RC3 now. I installed it clean and the package and I get this error in the log.

Oct 2 22:11:51 miniupnpd[977]: Failed to open socket for SSDP. EXITING
Oct 2 22:11:51 miniupnpd[977]: bind(udp): Address already in use
Oct 2 22:11:49 php: : Resyncing configuration for all packages.

Anything changed that would affect this between the 09-27-06 snapshot and RC3. It worked then just fine.

ollopa

@rsw686:

Oct 2 22:11:51 miniupnpd[977]: Failed to open socket for SSDP. EXITING
Oct 2 22:11:51 miniupnpd[977]: bind(udp): Address already in use
Oct 2 22:11:49 php: : Resyncing configuration for all packages.

That looks like you still had a copy of miniupnpd running in memory when you installed the package.

Did you try rebooting the router yet?

sullrich

@rsw686:

Oct 2 22:11:51 miniupnpd[977]: bind(udp): Address already in use

It's already running, I bet. Kill it before starting it again.

Either that or our code is not killing it correctly.

rsw686

@sullrich:

@rsw686:

Oct 2 22:11:51 miniupnpd[977]: bind(udp): Address already in use

It's already running, I bet. Kill it before starting it again.

Either that or our code is not killing it correctly.

I tried rebooting the system. Played around with this some more in VMware installing RC3 and then the package. Same thing happens. Only thing that comes to mind is that it runs the rc.d startup script before it syncs the package and then runs it again.

Not only that but now when I run Azereus it still talks to miniupnpd and sets up the port forwarding but it doesn't actually open them up in the firewall. Azereus shows DHT firewalled and before the firewall logs would fill with accepted packets and now it doesn't.

rsw686

When I run

pfctl -aminiupnpd -sn
rdr on fxp1 inet proto udp from any to any port = 6881 label "Azureus UPnP 6881 UDP" -> 10.10.1.150 port 6881
rdr on fxp1 inet proto tcp from any to any port = 6881 label "Azureus UPnP 6881 TCP" -> 10.10.1.150 port 6881

pfctl -aminiupnpd -sr
pass in log quick on fxp1 inet proto udp from any to any port = 6881 keep state label "Azureus UPnP 6881 UDP"
pass in log quick on fxp1 inet proto tcp from any to any port = 6881 keep state label "Azureus UPnP 6881 TCP"

However status.php only shows

pfctl -sn
rdr-anchor "miniupnpd" all

pfctl -sr
anchor "miniupnpd" all
block drop in quick all label "Default block all just to be sure."
block drop out quick all label "Default block all just to be sure."

Jonb

I did have this problem with RC3 as well but I did an uninstall reboot and install then a reboot and that has seemed to wrok

databeestje

I have not researched it yet, but it does seem like it is starting the package twice. It's probably not checking if it is started allready. or something along those lines.

With regards to the port mapping missing, I have no clue whatsoever.

rsw686

@databeestje:

I have not researched it yet, but it does seem like it is starting the package twice. It's probably not checking if it is started allready. or something along those lines.

With regards to the port mapping missing, I have no clue whatsoever.

Okay wanted to give some more information on this. Miniupnpd works now. I had to click change on the miniupnpd settings page and then clear and the status page. This seemed to kill both processes and get it started correctly. The rules are working and Azereus passes the firewall test. The firewall log fills with accepted packets. As you can see below both running instances closed out.

Oct 4 02:24:42 miniupnpd[1319]: Unknown soap method
Oct 4 02:24:38 miniupnpd[1298]: received signal 15, exiting
Oct 4 02:24:35 miniupnpd[804]: received signal 15, exiting

There is defiantly 2 instances of minupnpd being started. Happens everytime I reboot. Looks at the log below. It resyncs the package configuration twice and on the 2nd time miniupnpd fails because it is already started. Not only does it do the package resync twice but the RRD graphs and some other items as well. This all appeared after the 09-27-06 snapshot. First showed up in RC3 and still around in RC3b, which is what I'm running.

Oct 4 02:23:11 check_reload_status: reloading filter
Oct 4 02:23:11 miniupnpd[1010]: Failed to open socket for SSDP. EXITING
Oct 4 02:23:11 miniupnpd[1010]: bind(udp): Address already in use
Oct 4 02:23:10 php: : Resyncing configuration for all packages.
Oct 4 02:23:05 php: : Creating rrd graph index
Oct 4 02:23:05 php: : Creating rrd update script
Oct 4 02:23:05 php: : Informational: DHClient spawned /etc/rc.newwanip and the new ip is wan - 68.100.53.135.
Oct 4 02:22:58 login: login on console as root
Oct 4 02:22:48 sshlockout[840]: sshlockout starting up
Oct 4 02:22:48 sshlockout[840]: sshlockout starting up
Oct 4 02:22:48 login: login on console as root
Oct 4 02:22:39 dnsmasq[579]: reading /var/dhcpd/var/db/dhcpd.leases
Oct 4 02:22:37 check_reload_status: rc.newwanip starting
Oct 4 02:22:37 check_reload_status: check_reload_status is starting
Oct 4 02:22:37 last message repeated 4 times
Oct 4 02:22:36 miniupnpd[804]: Unknown soap method
Oct 4 02:22:34 php: : Resyncing configuration for all packages.
Oct 4 02:22:30 dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Oct 4 02:22:30 dhcpd: All rights reserved.
Oct 4 02:22:30 dhcpd: Copyright 2004-2006 Internet Systems Consortium.
Oct 4 02:22:30 dhcpd: Internet Systems Consortium DHCP Server V3.0.4
Oct 4 06:22:29 php: : Creating rrd graph index
Oct 4 06:22:29 php: : Creating rrd update script
Oct 4 06:22:29 php: : Create RRD database /var/db/rrd/wan-quality.rrd
Oct 4 06:22:29 php: : Create RRD database /var/db/rrd/wan-packets.rrd
Oct 4 06:22:29 php: : Create RRD database /var/db/rrd/wan-traffic.rrd
Oct 4 06:22:28 php: : Create RRD database /var/db/rrd/lan-packets.rrd
Oct 4 06:22:28 php: : Create RRD database /var/db/rrd/lan-traffic.rrd
Oct 4 02:22:28 dnsmasq[579]: reading /var/dhcpd/var/db/dhcpd.leases

rsw686

I dug into this further. Due to the following added changelogs miniupnpd starts three times.

[14721] Add rc.start_packages file
[14722] Use /etc/rc.start_packages

Firstly, the packages are being synced twice evident in dmesg and the logs where RRD is starting twice and then the below code in miniupnpd.inc starts the package. Then the rc.start_packages files starts it a third time.

start_service("miniupnpd");
restart_service("miniupnpd");

In my previous posts look at the process ids. There are three different ones.

Oct 4 02:24:38 miniupnpd[1298]: received signal 15, exiting
Oct 4 02:24:35 miniupnpd[804]: received signal 15, exiting
Oct 4 02:23:11 miniupnpd[1010]: bind(udp): Address already in use
Oct 4 02:22:36 miniupnpd[804]: Unknown soap method