UPnP support

ollopa

I did send a patch back to the original author but I'm not sure how much of it he's going to accept or when he'll get it merged and posted online.

I'll give up my source and the latest compiled binary (for 486 and up) here: http://www.sloservers.com/miniupnp
(note the lack of a d on miniupnp this time).

The source is is in a tgz. Compile on *BSD with gmake or just link the object files by hand…

Paypal contributions to rick@sloservers.com would be appreciated. I will continue work on the daemon if there are any bugs, features, etc.

ZPrime

FWIW, it's still not perfect as when the Xbox 360 starts, miniupnpd is confused by something and it logs a few "unknown packet" errors. However, it's implementing enough of the protocol to satisfy the xbox so it will map ports OK… If you want pcap-style network dumps of the conversation between the 360 and your current build of miniupnpd i can provide... also if you want to give me a debug version of the daemon that spits out more on the log that is cool too.

ollopa

Actually I saw the startup capture you posted previously.

What's going on is that the Xbox is announcing its presense and miniupnpd is ignoring the packet and logging that it received something other than an M-SEARCH.

miniupnpd doesn't need to act on this information but it also shouldn't give an error message.
I will patch miniupnpd to handle notifies from other devices without giving an error message.

~~Look back here in 10 minutes.~~

Done.

Try the version that is in this folder: http://www.sloservers.com/miniupnp
Right-click miniupnpd and save-as.

sullrich

Thanks for your work on this. the pfSense team will be sending 25$ as promised.

databeestje

if all is well the author of miniupnp will get back to you. I see that his version was update the 9th september, I'll see if I can break something tomorrow and get the upnp package for pfSense current with both codebases.

Some merging to do at least. I know that at least our -o option for a external IP did not make it.

Furthermore, the package include a status_upnp.php so you can see if ports are being forwarded.

On the broken client side, I found that the current Hamachi 1.0 beta only adds ports and does not remove them.
I have about 60 of those now. 2 added after each reboot.

Note that pressing save on the interface configuration page will reset all port forwards. Most upnp devices will readd your port within 10 minutes. They poll every 5 minutes or so if it is still valid.

I'll resume work tomorrow, i've been gone for a few weeks and needed some time.

KiaN

I did upload the latest miniupnpd file to /usr/local/sbin, the service is running, but Windows Live Messenger still says I am using a "symetrical NAT non-UPNP network".

nsumner

For me, Windows live messenger (installed for 5 minutes then uninstalled) says I am connected through a UPnP symetric NAT.

ollopa

MSN messenger 7.5 says symmetric UPnP NAT for me.

MSN Live Messenger also say UPnP symmetric NAT.

Download this UPnP tester here http://noeld.com/programs.asp?cat=dstools#upnptest and look for root devices.
The latest version should show up as miniupnp daemon. If not, then you have a problem with your firewall settings or your miniupnpd installation.

billm

@hshh:

Will upnp break traffic shape?

Depending on where the anchor for miniupnp is placed you'll probably see all traffic that matches your upnp rule(s) fall into the default queue.

–Bill

hshh

If there are 2 router with UPNP, will clients get wrong gateway upnp ip? Not all client are using same gateway.

ollopa

It will likely depend upon your client's implementation.

It's up to your client to determine which UPnP device to use.

Jonb

Just out of interest what is happening in regards to the UPNP support. Will it be in the next release as a switch on function??? I have tested wail databeestje was programing and it did work with some apps. ollopa seems to of done some good updates to make the Upnp function more.

sullrich

It will remain a package.

We ar waiting on ollopa to finish up and we will merge his changes back into the package.

KiaN

@ollopa:

Download this UPnP tester here http://noeld.com/programs.asp?cat=dstools#upnptest and look for root devices.
The latest version should show up as miniupnp daemon. If not, then you have a problem with your firewall settings or your miniupnpd installation.

It says :

Microsoft Windows XP Professional Service Pack 2
Version: 5.01.2600

UPnPTest V2.06 (Build 35.5)

ERROR: Universal Plug and Play Device Host service not running

20:34:22 - Filter: .All Root Devices
20:34:22 - Monitoring started
20:34:22 - Device added: MiniUPnP daemon [uuid:00000000-0000-0000-0000-000000000000]
20:34:22 - Device external IP address: 82.xxx.xxx.179
20:34:22 - Device external IP address: 82.xxx.xxx.179
20:34:31 - Search complete

In my Network Connections, I have Internet Connection which means that it at least works a bit, but when I want to see it's status, it show for a second, saying what's on the following screenshot and then disapears.

ollopa

@sullrich:

It will remain a package.

We ar waiting on ollopa to finish up and we will merge his changes back into the package.

I've stopped working on it for the moment. The author of miniupnpd is merging my changes into the official release and making some changes to make sure it works on OpenBSD as well as FBSD. After that, I will probably snag his latest release and work on the final updates.

I have a problem where miniupnpd sometimes goes into a race condition and uses 100% cpu. Has anyone else seen this behavior?

sullrich

Yep, I have seen it go into 100% myself as well. Not sure what causes it. Only has happened once however.

ollopa

@KiaN:

In my Network Connections, I have Internet Connection which means that it at least works a bit, but when I want to see it's status, it show for a second, saying what's on the following screenshot and then disapears.

Here's a thought: How many network cards are in your computer? Do you have any VPN tunnels or any other interfaces with an IP address on your windows workstation?

It is possible that it's telling miniupnpd to map to the wrong address.

Fire up MSN messenger, go on the router, and execute this command:
pfctl -a miniupnpd -sn

Look for a rule similar to this:
rdr on xl0 inet proto udp from any to any port = 32977 label "msnmsgr (192.168.10.114:7002) 32977 UDP" -> 192.168.10.114 port 7002

You want to make sure the part that says "xl0" for my example matches your WAN interface. If you're using PPPoE, this should be ng0.

Make sure the ip address (192.168.10.114 in my example) matches your workstation's IP address.

ollopa

@sullrich:

Yep, I have seen it go into 100% myself as well. Not sure what causes it. Only has happened once however.

Well some shortcuts were taken with the code I wrote. I'll take a closer look in the next version and take more care. Hopefully I'll get to the root of that problem.

I've seen it more than once on my wrap box.

Anybody know of a good technique to narrow down the section of code that's causing the high CPU usage?

sullrich

I am not running your version. So the race condition is not in your code…

ollopa

@sullrich:

I am not running your version. So the race condition is not in your code…

Actually that helps, thanks for the tip. I'll go through it and see if I can find what the problem is.
It might be in the SOAP/HTTP server code. I had some problems with undersized buffers with the author's original SSDP code. Perhaps there's a similar condition in the SOAP code.