UPnP support
-
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 -
Excellent. The -o option made it in :)
-
I still owe ~$50 of bounty money. Should I just send it to the project and you guys can distribute from there? Also, I'd appreciate if any instructions to make this work for embedded get posted in this thread (i.e. when you go 1.0 gold or another RC, please make sure the new binaries work and that we can still just dump them in the right spots with RW mode enabled). I don't have the luxury of being able to run non-embedded yet…
Oh, and FWIW, having UPnP enabled seems to break the traffic shaper entirely. OR at least, the web GUI for the shaper thinks that it has never been configured and tries to run me through the initial setup again. I'm still running RC2e on embedded though, is there something newer I should update to?
-
embedded install instructions on request by direct email. It has a feature I do not want to make public in the forums.
regarding the traffic shaper. Resetting the traffic shaper is probably a problem strictly on the version you are running. The 22-09-2006 snap I am running does not exhibit that problem.
In later snapshots the miniupnp firewall "anchors" have been moved to the rear of the queue so it should properly honor the queues now instead of bypassing them. You still need to set up correct port forwarding for the port so it creates correct queue rules. That or the p2pcatchall would work.
Regarding the payment, since Rick has done a bit of grunt work on the miniupnp source code it seems only fair he should be sent a part of the money.
I will merge the 20060924 release into CVS shortly.
-
In later snapshots the miniupnp firewall "anchors" have been moved to the rear of the queue so it should properly honor the queues now instead of bypassing them. You still need to set up correct port forwarding for the port so it creates correct queue rules. That or the p2pcatchall would work.
Unless the rules miniupnp creates explicitly set the queue, this is untrue. If no queue is set on a rule, the default queue is used.
–Bill
-
that clarifies things. p2pcatchall it is then.
-
that clarifies things. p2pcatchall it is then.
Yep…although I think this has the same issue ;-P Since the anchor for miniupnpd doesn't specify a queue, the default queue is used. p2pcatchall doesn't work the way you think it does - it doesn't make the default queue p2p, it drops everything that isn't matched by another more explicit policy into the p2p queue. And the rules dropping it into the p2p queue are evaluated before the miniupnpd anchor; so it's already going to be allowed (or denied) by user rules before reaching the miniupnpd anchor (assuming it does since user rules are 'quick'). If it does eventually reach miniupnpd, the queue will change based on the last rule it matches...if no queue is specified on that rule, it will use the 'default' queue.
In other words. miniupnpd and shaper are incompatible in the sense that shaping will work, it just won't work as expected. You can still limit bandwidth, just don't expect anything that isn't prioritized above default to work worth a damn.
--Bill