UPnP support
-
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?
-
Yep, I have seen it go into 100% myself as well. Not sure what causes it. Only has happened once however.
-
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 -snLook 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 7002You 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.
-
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?
-
I am not running your version. So the race condition is not in your code…
-
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. -
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 ;)
-
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?
-
Yeah, I don't see why not. Its a gigantic state machine?
-
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. -
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.
-
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.
-
So has the package been updated to take the latest updates to the files.
-
Yes, it appears so.
-
OK no prob I will test it out tonght and see how it goes. I has installed better on the new snap shot
-
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
-
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.
-
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… ;)
-
There is a very easy way of getting this working on embedded, however we are currently still discussing how to go about this.
The good news is that I got it working with minimal effort within 5 minutes.
-
Well that's great news. I checked it out and my code was mostly merged. I think there's a bug that will prevent the -u option from working. Looks like he doesn't copy the UUID to the XML schema, so don't use that option as some devices will fail to work. I'll tell the original author.
He also didn't merge my XML schema changes yet which is too bad.
I want to talk about making this work on wireless.
Basically the socket that listens for multicast messages binds to whatever interface(s) have the -a IP address.The problem is that for wireless guys, the LAN and the WLAN interface are bridged, but only the LAN interface gets an IP address.
The quick fix for this is just a patch in the interfaces.inc file that sets an ip address on every interface in a bridge.
Just to put it another way, to get UPnP working on bridged interfaces, set the same IP address on every interface in the bridge before starting miniupnpd.