Topic: Prevent endless loops in inbound routes [Comments: 8]
gb_delti

Mon, 08/02/2010 - 05:50 | Prevent endless loops in inbound routes

With our version of PBXManager ( 6.0.1.71) it is possible to select "Go to Menu" as action, but leave the menu choice empty, select "None" or select multiple menus. If the menu is empty, the called macro "tl-menu", will run in an endless loop, producing thousands of log file entries (with verbose logging turned on) and finally bringing the server down because the log file partition is full. I have two proposals:

  1. Change the GUI in all places where a menu can be selected to a required list wjhere one and only one item must be selected
  2. Change tl-menu to check for the first argument, jumping to a fixed "Invalid configuration" macro in case of missing first argument.
eeman

Mon, 08/02/2010 - 14:12 | #1 .. just like every

#1 .. just like every development site on the internet ... DO NOT POST BUGS ON OUT-OF-DATE SOFTWARE! 6.0.1.71 is over a year old. You have no idea if this is even fixed yet or not.

#2 invalid handlers DO EXIST on newer versions of PBX Manager

But I have to warn you... This software will not run on Windows For Workgroups 3.1.1

Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com

thirdlane

Wed, 08/04/2010 - 04:11 | Prevent endless loops in inbound routes

The problem does exist - and is broader than just menus - and fixing it is not going to be very simple - this may require adding additional attributes (required/optional, multiple/single, etc) to script arguments and possibly some extra checks to the scripts and will proliferate throughout PBX Manager. I will look into this to find a reasonable solution - in the meantime please just be careful when specifying script arguments.

Alex Epshteyn
Third Lane Technologies
Multi-tenant Asterisk PBX

George

Thu, 08/12/2010 - 06:15 | Alex this is what we talked

Alex this is what we talked about earlier today. This is a MAJOR problem, the loops caused by a selection of NONE WILL crash the server and should be removed ASAP.!

Also as discussed is a field have a * next to it a value MUST be entered rather then a warning, this will also prevent this same kind of problem.

gb_delti you might be talking about an older version of TL but the problem is still there is the most current version.. thanks for bring it up..

George

eeman

Thu, 08/12/2010 - 11:38 | George, in your asterisk.conf

George, in your asterisk.conf you should set maxcalls to something reasonable so should you experience a loop (however a loop gets started) it will stop at a point well before a crash occurs. I watched a customer experience two employees decide they were going to forward their phones to each other in dialplan just to see if they could crash the system. GUI checks can help some of these problem areas but there's other ways to cause an infinite loop.

Any loop that occurs within a single call (ie not via chan_local which generates new call uniqueid's) needs to be bugged with digium. Asterisk code is responsible to check for loops in the dialplan within a single call leg. Most of these loops occur because (as example of forwarding to each other) they invoke a new Dial command that creates a new call.

Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com

George

Fri, 08/13/2010 - 15:15 | Hey Erik, >> GUI checks can

Hey Erik,

>> GUI checks can help some of these problem areas but there's other ways to cause an infinite loop.

while setting a limit in the Asterisk.conf file is all well and good its a patch to a bigger problem. As you and I have both stated this needs to be done in the GUI and needs to force a VALID selection and NONE when it will cause a loop is never a valid selection and should be removed from those areas..

and yes we have a customer do the same thing with forwarding an extension to another and back again. NOT FUNNY!! right know we see it in the inbound routes. So its a global problem and anywhere and everywhere were NONE can be selected that would cause a loop NONE should be removed.

George

eeman

Fri, 08/13/2010 - 15:51 | if you think thats bad I

if you think thats bad I recently had a consulting customer have one of his customers forward their main # to another office.. and that office (somewhere on the PSTN) was set up to forward to back to their main # on the MTE. Fortunately their carrier set the max number of calls on their trunk to 100 so the per-minute cost was limited, but for ever call there was a Callerid name lookup charge of $0.01 added to the roughly $0.008/min rate of the 100 concurrent calls. I think his damage was limited to $11 every time it happened, but I think it did happen a few times (20) that day before it was discovered.

Erik Smith
CTO
BluegrassNet Voice
dCAP
Thirdlane Support by BluegrassNet Voice
eeman at bluegrassnetvoice dot com

George

Fri, 08/13/2010 - 17:33 | OUCH!! so who needs to fix

OUCH!!

so who needs to fix this..? Alex :)

thirdlane

Mon, 08/23/2010 - 09:25 | Ouch!

I wish I could :). User a forwards to b, b to c, c to his cellphone, and his cellphone to a DID that is associated with b, or another tenant's b, etc - a very long loop :). I hope your customers won't try this, or at least you can charge them for doing it :). While there are ways to prevent this kind of problems (to some extent), they are far from perfect - so watch your log files.

That said, we are considering building some basic sanity checks into PBX Manager - but it it would be quite difficult and probably not very efficient to make a PBX do all the checking - at best we could report on potential problems - or we should be working on a different "very expensive" product called "PBX Validator". Would you like to buy it? :). i am not joking - perhaps some monitoring tool needs to be developed (is Munin not useful?), but we have to keep our focus.

Somehow we are getting pushed into the situation where we are becoming responsible for configuration and performance (voice, email, database, directories, etc), tuning, validating, etc) - while as a company we are not focused on that and are simply trying to offer innovative, cost effective solid products for managing single and multi tenant hosted PBXs.

The topic is complex, ideas and suggestions are very welcome.

Alex Epshteyn
Third Lane Technologies
Multi-tenant Asterisk PBX