UPnP support
-
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.
-
We can most likely patch it further to work in conjunction with my -o option.
-
Sounds good. Are you or Seth going to do that then?
-
Well I have tested the Upnp with a few other OS/programs and I haven't found any probs is the Upnp pakage. I am running the snap shot 09-20-06. LimeWire seems to be fine.
-
Sounds good. Are you or Seth going to do that then?
Yeah, most likely. However I dont use xbox so my version has been fine so the motivation is unfortunately not there. ;)
-
Are we talking about the same thing? I was talking about the patch to assign an IP address to all interfaces in a bridge so that the daemon will bind to all interfaces.
For wireless really, doesn't have anything to do with Xbox… or did you mean that you don't have a need for UPnP in general?
-
-o allows you to tell it to use an ip address that is not bound to an interface directly, such as carp.
-o XX.XX.1.1 would tell it to use XX.XX.1.1 as the external UpnP wan interface ip.
-
Separate issues here…
-o is for the external, WAN interface. The multicast LISTENER doesn't bind to that interface. It binds to whatever interface(s) is/are attached the the -a (listen) IP address. We want this to be the wired LAN interface AND the wireless LAN interface.
When an application wants to use UPnP, it broadcasts a multicast SSDP message that miniupnpd has to hear in order to send a reply. In the case of bridged LAN interfaces, some quirky things happen under FBSD.
Let's say for example we've bridged two interfaces, ath0 and sis0 to make bridge0. Now there are three interfaces for the LAN (sis0, ath0, bridge0). If we assign the IP address to bridge0 and then set up a multicast listener socket, it will (as I recall) hear multicasts from both ath0 and sis0.
If, however, we assign an IP address to sis0 only, and nothing to bridge0 or ath0, then the listener will only hear multicasts arriving on the sis0 interface. It is unaware of multicasts sent from ath0, even though they are bridged.
Alternatively, if we assign the same IP address to ath0 and sis0 (and optionally bridge0) then the listener will bind to both physical interfaces and hear multicasts arriving on either interface.
So the easy, quick fix is just to assign the same IP address to every interface in a bridge.
The other fix is to abstract the bridge interface and assign a single IP address only to it, but it's a lot more difficult and I don't think there's any reason to do that instead of just assigning an IP address to the wireless LAN interface.
So right now, if your LAN address is 192.168.1.1 then this is how it will look:
bridge0 (no ip address)
ath0 (no ip address, UPnP will not work for wireless clients)
sis0 (192.168.1.1 UPnP does work for wired clients)and I propose this:
bridge0 (192.168.1.1 or no IP address, doesn't matter)
ath0 (192.168.1.1 UPnP will work for wireless clients)
sis0 (192.168.1.1 UPnP will work for wired clients)Does that clear up what I'm talking about?
-
is there a very specific reason to include the XML fixes? Would it allow for functionality which is otherwise not available?
Otherwise I would rather track the mainline branch from Nanard
-
I think the XML stuff may be in there now…here's the Changelog.txt from the latest source code (miniupnpd20060924.tar.gz):
$Id: Changelog.txt,v 1.12 2006/09/24 01:22:08 nanard Exp $ 2006/09/24: updating the XML description generator 2006/09/18: Thanks to Rick Richard, support for SSDP "alive" and "byebye" notifications was added. The -u options was also added. The SSDP response are now improved. The -o option is now working (to force a specific external IP address). The Soap Methods errors are correctly responded (401 Invalid Action) 2006/09/09: Added code to handle filter rules. Thanks to Seth Mos (pfsense.com) storing the descriptions in the label of the rule 2006/09/02: improved the generation of the XML descriptions. I still need to add allowed values to variables. 2006/07/29: filtering SSDP requests and responding with same ST: field 2006/07/25: Added a dummy description for the WANDevice 2006/07/20: Command line arguments processing Added possibility to listen internally on several interfaces