UPnP support

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

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.

sullrich

@ollopa:

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.

No problem, just didn't want you to waste your time ;)

ollopa

@sullrich:

No problem, just didn't want you to waste your time ;)

I might try profiling the code. Never done profiling before. Do you think it's appropriate for this situation?

sullrich

Yeah, I don't see why not. Its a gigantic state machine?

ollopa

I don't think so…
I haven't looked closely at all the code but I don't think it keeps track of any particular states at all.
It's pretty much just query-and-answer.

Jonb

I have had the CPU lock at 100% a few times when no traffic has been going through and that was without the Upnp being installed.

databeestje

Current miniupnpd 20060919 checking in from the maintainer. Assuming this also includes the fixes by ollopa.
Have not checked that yet.

On a clean snapshot (1.0-SNAPSHOT-09-18-06) I install the package, I then go to diagnostics miniupnd (might need to refresh for it too show up) and select the LAN interface and press save.

Immediately Azureus pops up reporting UPNP mappings. Something must be working then.
Miniupnp status page also works and looks fine.

So the package works for me atleast. Or it does now.

Jonb

So has the package been updated to take the latest updates to the files.

sullrich

Yes, it appears so.

Jonb

OK no prob I will test it out tonght and see how it goes. I has installed better on the new snap shot

Jonb

Good news guys. With the latest package it seems to work much better now. I have tested this on Windows Vista and it sees the Upnp and I can add, delete and modify entrys through the router in network devices. MSN picks it up as a symetrical Upnp router and azerues seems to see the service fine. So far I haven't found any issues.

Well done to ollopa and databeestje

rsw686

Is upnp going to be included into the base image at some point? Right now its in package form which makes it hard to install on the embedded images. Plus that means when updating the embedded box I have to set it up manually. Not complainig just curious. Thanks.

hoba

Atm it will remain a package. Doubt that it will become integrated into the base systems. It's more likely that at some point (in a universe far far away) suitable packages like these will become available for embeddeds. No promise, no date, don't ask… ;)