UPnP support
-
-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.
-
Ok, with the latest version, it works perfectly from MSN, but I cant see Internet Connection anymore as shown above.
-
package updated. it should install again.
Cheers,
Seth
-
package updated. it should install again.
Cheers,
Seth
Thanks for all the hard work on this package. I finally got around to making a custom image with the miniupnpd files and my config so I could just write it to the compact flash card and start the box up.
Happy to say that the miniupnpd package is outstanding. Azereus maps/unmaps ports correctly. I was even surprised that the Internet Connection Advaced Services tab in WinXP Network Connections is able to map/unmap ports as well. Really satisified.
Only minor thing I see is in the system logs
miniupnpd[787]: Unknown soap method
Also clicking on the miniupnpd on the pfsense admin pages shows the settings, would perfer it to show the status first as that will be used more than the settings for which interface its configured on. Also the tabs are missing on the status page.
Both those are minor issues.
–---
Note: I used the words attached files in writing the below. Well I can't attach files with extensions sh, xml, tar.gz. So instead I provided links to them at the end of the text. I would've renamed the extensions to txt but I thought that might get confusing.
For anybody else wanting to make a custom image to flash for the embedded platform its quite simple.
I use FreeSBIE in VMware. However you can use any freebsd platform of your choice.
Either use the attached miniupnpd.tar.gz file or follow the steps below to create one with the newest version of the files.
Grab the latest files from http://www.pfsense.com/packages/config/miniupnpd/. This should include miniupnpd, miniupnpd.inc, miniupnpd.xml, status_upnp.php.
Put the files above and the miniupnpd.sh file attached in a directory you create named miniupnpd. Tar the directory using
"tar cfz miniupnpd.tar.gz miniupnpd/"
Now use the attached script sh-add-miniupnpd.sh to add the miniupnpd files to the pfSense.img file (successfully used on snapshot 9-27-06). The script uses the miniupnpd.tar.gz file to extract and add those to the pfSense.img file. You will need to chmod +x sh-add-miniupnpd.sh to give it execute permissions.
Yes, you could modify the script so you wouldn't have to tar the files and just stick them all in the script directory. However, since I use this in VMware I find its easier to keep track of fewer files when copying them back and forth. Plus I can name the miniupnpd tar file so I know which one is the working version and which is the one containing the new files I just grabbed from the web. ;)
"chmod +x sh-add-miniupnpd.sh"
"./sh-add-miniupnpd.sh miniupnpd.tar.gz pfSense.img"Replace the <installedpackages>section in your personalized config you downloaded from your current pfsense box with the supplied <installedpackages>section in the attached cfg-add-miniupnpd.xml file.
Use the attached script sh-replace-config.sh to replace the default config in the pfSense.img file with the config you just created.
"chmod +x sh-replace-config.sh"
"./sh-replace-config.sh yourconfig.xml pfSense.img"Your image is ready. Flash it to the device and enjoy.
Thanks to Seth for helping me out getting this to work. He gave me the <installedpackages>section of the config along answering multiple questions I had about miniupnpd.
Files:
http://wgnrs.dynalias.com:81/pfsense/cfg-add-miniupnpd.xml
http://wgnrs.dynalias.com:81/pfsense/miniupnpd.sh
http://wgnrs.dynalias.com:81/pfsense/miniupnpd.tar.gz
http://wgnrs.dynalias.com:81/pfsense/sh-add-miniupnpd.sh
http://wgnrs.dynalias.com:81/pfsense/sh-replace-config.sh</installedpackages></installedpackages></installedpackages> -
I have just commited these changes.
-
Added -o WAN override option
-
Now defaults to status page
-
If not setup prior, redirects to settings tab
-
Removed Status entry. Now defaults to Services -> Miniupnpd
-
-
I have just commited these changes.
-
Added -o WAN override option
-
Now defaults to status page
-
If not setup prior, redirects to settings tab
What flags the page to know if its setup prior or not. I just grabbed the latest files again and reflashed my device. Now on the status page it shows the tabs and on the settings page I have the wan override box. However it still shows the settings page when clicking miniupnpd, even hitting change on the settings page.
I see this line
['installedpackages']['miniupnpd']['config']
Does that point to the config xml file? I'm almost positive it does. I just did a backup of the config file from the webgui and I have the miniupnpd config section sepcifing the interface_arry.
-