UPnP and multiple Xbox 360s (4-8)
-
Does the "upnp bypassing the traffic shaper problem" still happen in 1.2 final? If so is this in the works for 1.3?
There is a way to compile miniupnpd to use an ALTQ queue. I'm not sure how this would tie in with the traffic shaper.
-
Well what i recommend is to add an option to tag packets that match the miniupnp nat/rdr/filter rules and not make them terminating ie not use quick.
This is the same at what ftp-proxy on latest openbsd does and it helps a lot catching things up queueing them and so on.
Please suggest to the author of miniupnpd to make this change and be done with it.
One pfSense 1.3 you can match tags from the filter rules created in the gui.This is the best design and would make miniupnd compeletely standalone and not watching at other information it does not need to.
I do not know if PNP protocol supports classes but if it does it would be nice to allow the option to specify one tag to be applied to specific traffic served by this daemon and then matched by tag from the user so to shape or not allow it at all.
I hope this helps you somewhat.
As for the change iirc it is just ~10 lines of changes max. -
@ermal:
Well what i recommend is to add an option to tag packets that match the miniupnp nat/rdr/filter rules and not make them terminating ie not use quick.
Miniupnpd was using rdr pass on, but I have recompiled it so that it is creating an rdr and a pass rule. I have also disabled the quick setting. So now I have rules that are looking like this
jellyfish:/tmp# pfctl -aminiupnpd -sn
rdr on fxp2 inet proto udp from any to any port = 46678 label "Azureus UPnP 46678 UDP" -> 10.10.1.150 port 46678
rdr on fxp2 inet proto tcp from any to any port = 46678 label "Azureus UPnP 46678 TCP" -> 10.10.1.150 port 46678
jellyfish:/tmp# pfctl -aminiupnpd -sr
pass in on fxp2 inet proto udp from any to any port = 46678 flags S/SA keep state label "Azureus UPnP 46678 UDP"
pass in on fxp2 inet proto tcp from any to any port = 46678 flags S/SA keep state label "Azureus UPnP 46678 TCP"Your saying I need to tag it as well. So at the end of the rule it should have a tag UPNP or something of that sort like the below?
pass in on fxp2 inet proto udp from any to any port = 46678 flags S/SA keep state label "Azureus UPnP 46678 UDP" tag UPNP
The option already in the upnpn daemon can append queue SOMENAME to the rule. I could easily add in the tag option like above if that is better.
-
Yeah a tag option is better and get rid of the queue option compeletly.
It is not needed and is cumbersome.Please add the tag to the rdr rule so it produces
rdr ….blabla.... tag MYTAG label "whatever" -> to $whateverit is better in the rdr since it is the first thing that takes a look at the packet ;)
I would also like to see the rdr being generated for multiple interfaces so the PNP traffic can be loadbalanced with the help of tags.
But that is more homework i guess. -
So I could do rdr pass….blabla.... tag MYTAG label "whatever" -> to $whatever and skip the separate pas rule?
The additional features can come once I get the basic thing working in 1.3 with the traffic shaper. ;)
-
So I could do rdr pass….blabla.... tag MYTAG label "whatever" -> to $whatever and skip the separate pas rule?
No since that extra "pass" might bypass the ruleset.
Just add the tag on the rdr that is my suggestion, you still need the separate rules to pass traffic. -
Sounds good. I just wanted to make sure it was implemeted the best way. 1.2 upnp just uses one rdr pass rule and I wasn't sure what was more efficient. Thanks.
-
Is it that uPnP bypasses the traffic shaper all together or does it's traffic just get automatically sent to the default queue? I'm on 1.2 Final and it looks like the upstream traffic from utorrent using a random port via upnp is being "picked up" in the "qwandef" queue status graph.
So… if I design my shaper solution around this fact, I might be able to make it work, correct? (and not have to wait until 2009 for 1.3)
For instance: I know Xbox 360 traffic will be uPnP and so will be in the default queue automatically. I can make my P2P stuff go to another queue of lower priority and saturate it completely. Then I'll see if my ping times are OK. If they are OK, or at least less than with no shaping, then I'm headed in the right direction!I'm going to test this when I get home.
Also the 1.2 final release has a working version of upnp which DOES NOT, from my experience, need the script/patch provided by RSW686 for the older version(I believe this patch is already included in the recent PFsense releases). I'm back to using a residential ISP with 1 dynamic address and we have 8 Xbox 360s here (all upnp, all open NAT status) as well as a PS3(uPnP as well) all playing nicely online. My pfsense uptime has been around 72 days and I haven't restarted miniupnpd in about 2 weeks. The only reason it has restarted is because of the troublesome power outages. My last issue in the traffic shaper
Thanks again for your help.
-
Yes your assumtion is correct.
-
I tested it all this weekend. It is true, the uPnP traffic gets sent to the default queue automatically. So I was able to play around with the shaper to make it work! There is a ton of tweaking I need to do still(default queue is showing drops while the P2P queue is not). All in all I would say it's a great success for me! I was able to completely saturate my upstream and play online games for many hours with only a few tiny hiccups(like I said I need to tweak). It's a great thing!
What I've been attempting is to treat my default queue like my highest priority queue which can work since I don't use voip and 90% of traffic that I couldn't classify(and send to a lower priority queue) would be high priority online gaming traffic anyway.
I'm researching the traffic shaper now. -
The shaper seems to be working very well now! UPnP is working great as well. I've attached a screenshot of what my uPnP status page looks like. I don't think there are too many routers out there that can handle this kind of usage. Thank you PFsense devs for making the ultimate gaming router / firewall!
