Something on your mind? Want to give us feedback on something in particular or everything in general? Tell us how we are doing!
#12253 by Groundhound
Sun Jun 28, 2009 1:39 pm
WDS= Wireless Distribution System
My two extra WRT54G's are acting as wireless AP extenders and providing wired access to desktop PC's, networked printer, and DirecTv DVR. They each talk to the central router which is behind the hub, but don't talk to each other directly. The central router does the DHCP. It all works well now but was a bit of a challenge to set up correctly.

Life would be so much simpler if I had thought to pull CAT5 when we built the house 18 yrs. ago.
#12254 by scottlindner
Sun Jun 28, 2009 1:51 pm
Groundhound wrote:WDS= Wireless Distribution System
My two extra WRT54G's are acting as wireless AP extenders and providing wired access to desktop PC's, networked printer, and DirecTv DVR. They each talk to the central router which is behind the hub, but don't talk to each other directly. The central router does the DHCP. It all works well now but was a bit of a challenge to set up correctly.

Life would be so much simpler if I had thought to pull CAT5 when we built the house 18 yrs. ago.


My house is the same way, nothin'. So I have been running at least two Cat6 runs to each room as I have the opportunity.

As for your WDS situation. I don't believe there is a relationship between WAP, repeaters, the router that is being extended, and the NAT and DHCP functions of the router. Try saving off the configuration for your router as you have it now, and shut off DHCP and the WAN port (that is how most routers get shut off) and connect only one of the LAN ports into your Ooma Hub. That way you should be able to use the Ooma Hub for your QoS, NATing router, and DHCP while preserving the rest of your wireless configuration. If it doesn't work, just reload your saved off configuration file.

Scott
#12255 by Groundhound
Sun Jun 28, 2009 1:56 pm
Actually, my network behind the central router is running just fine, so I'll probably leave it the way it is. That way if I need to take the hub out of the system, nothing else needs to change.
#12259 by Groundhound
Sun Jun 28, 2009 2:14 pm
Thanks for the suggestions, Scott. I like having the hub handle the QoS for calls, because it takes care of both directions during a call and then steps aside with no QoS when no call is in progress. My original question really revolves around the hub's inbound QoS taking more of the download bandwidth pie than I expected.

There may be a way to provide conditional QoS in Tomato - that is only in effect when a call is made. But unless I can figure out how to do that I'll probably leave it the way it is.
#12261 by scottlindner
Sun Jun 28, 2009 2:30 pm
Groundhound wrote:Thanks for the suggestions, Scott. I like having the hub handle the QoS for calls, because it takes care of both directions during a call and then steps aside with no QoS when no call is in progress. My original question really revolves around the hub's inbound QoS taking more of the download bandwidth pie than I expected.

There may be a way to provide conditional QoS in Tomato - that is only in effect when a call is made. But unless I can figure out how to do that I'll probably leave it the way it is.


I would do the same. Even though your speeds would double, I'm sure what you have already is adequate performance for your needs. That is what I have concluded while watching Tomato's real time bandwidth meter while doing the most Internet intensive thing we've ever done here. Convinced me very quickly I have adequate ISP for my needs.

Scott
#12278 by Aveamantium
Sun Jun 28, 2009 8:26 pm
Groundhound wrote:There may be a way to provide conditional QoS in Tomato - that is only in effect when a call is made. But unless I can figure out how to do that I'll probably leave it the way it is.


I don't believe there is a way to set conditional inbound bandwidth allocation in Tomato (at least in the native QOS algorithms). Unfortunately, with tomato the inbound Qos (should you decide to use it at all) can only limit a percentage of the user set bandwidth based on classification so there is really no way to turn this off and on based on a call (if you set medium to get 70% of the set bandwidth that is all it will ever get regardless if VoIP is in use or not)... This would be a good suggestion for Jon at polarcloud.com. Maybe he could set up a conditional bandwidth reservation if a certain trigger is met (i.e., SIP initiation or RTP data stream)?
#12281 by scottlindner
Mon Jun 29, 2009 3:25 am
Aveamantium wrote:
Groundhound wrote:There may be a way to provide conditional QoS in Tomato - that is only in effect when a call is made. But unless I can figure out how to do that I'll probably leave it the way it is.


I don't believe there is a way to set conditional inbound bandwidth allocation in Tomato (at least in the native QOS algorithms). Unfortunately, with tomato the inbound Qos (should you decide to use it at all) can only limit a percentage of the user set bandwidth based on classification so there is really no way to turn this off and on based on a call (if you set medium to get 70% of the set bandwidth that is all it will ever get regardless if VoIP is in use or not)... This would be a good suggestion for Jon at polarcloud.com. Maybe he could set up a conditional bandwidth reservation if a certain trigger is met (i.e., SIP initiation or RTP data stream)?


I believe there is, but it is not going to be through the GUI. Behind the scenes it is using IPTABLES. You should be able to Telnet into the router as admin and do a couple of one liners. I have read about people doing something very similar on the DD-WRT forums using the same approach bypassing the GUI. One person wrote a four liner script that caps each IP to a monthly upload limit. Not bad for four lines.

Scott

Who is online

Users browsing this forum: No registered users and 7 guests