UPnP support
-
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
-
What we need now is a way to tell miniupnpd to attach a queue to it's rules.
Seth?
-
Current 20060924 upstream merged. This should have the XML fixes.
If you want the latest, reinstall the package.
The queues is just simply a pain. Although I am pretty sure you can attach a queue to it I think it's a bit of a problem.
We can not assume it's a p2p either. If you have a XBOX you want the game to have a higher priority. Making a choice in the shaper configuration to dump it into either p2p or games or skype or voipbuster or MSN.
pondering…
For now it is as it is. The good thing is that rules ahead of it match. So stick your p2p thingie in a normal user rule and it will apply to the right queue. All the rest of the random ports for MSN skype and Xbox would "just work" although no specific priority would be applied. Which would still be above p2p.
-
Current 20060924 upstream merged. This should have the XML fixes.
If you want the latest, reinstall the package.
The queues is just simply a pain. Although I am pretty sure you can attach a queue to it I think it's a bit of a problem.
We can not assume it's a p2p either. If you have a XBOX you want the game to have a higher priority. Making a choice in the shaper configuration to dump it into either p2p or games or skype or voipbuster or MSN.
pondering…
For now it is as it is. The good thing is that rules ahead of it match. So stick your p2p thingie in a normal user rule and it will apply to the right queue. All the rest of the random ports for MSN skype and Xbox would "just work" although no specific priority would be applied. Which would still be above p2p.
Yep. I think you have to know what queue number the queue is to add it. You can't just call SIOCADDRULE (or whatever the ioctl is…don't recall the exact name) with the character array representation of the queue, it's gotta be whatever pfctl numbered it.
--Bill
-
I'd be nice to have a page showing the current upnp forwarded ports and the ability to close them off. When I was testing out upnp I had a case were the application didn't close the port due to a crash and then when the app was opened and closed again since the port was already forwarded it wouldn't close it.
-
There is a page that does this, IIRC.