Ticket #2062 (closed Bugs: fixed)

Opened 5 years ago

Last modified 4 years ago

iax trunk config fails to respect order of directives, restricting use of permit and deny

Reported by: ma_clanger Assigned to:
Priority: minor Milestone: 2.4
Component: Core - Trunks/Routing Version: SVN-HEAD
Keywords: iax permit deny order Cc:
Confirmation: Confirmed SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

On the 'Edit IAX Trunk' page the 'PEER Details' and 'USER Details' sections do not respect the order of directives entered. After a 'Submit' the order presented may be different to that supplied by the user, and is the reverse of the order written to iax_additional.conf. This may not matter for the majority of directives, but for 'permit' and 'deny' it is crucial as the last one to appear takes precedence. Take for example:

deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.0

In this order connections are denied from everywhere except the 192.168.1.x subnet. Reverse the order and all connections are denied. Manual changes to the order in iax_additional.conf confirm this behaviour in asterisk 1.2.19. Both FreePBX 2.2.1 and 2.3beta1 with online updates applied 09 July 2007 consistently put the deny after the permit in iax_additional.conf irrespective of the order entered.

Change History

07/12/07 20:59:01 changed by p_lindheimer

notes on this bug:
the issue is that the values are all stored in the tables which currently only have the 4 fields: id, keyword, data, flags meaning there is no notion of ordering retained so when the keys are read back, We would have to add a sequence number field if we want to address this now vs. waiting for our new structure when routing/trunks are redone.

08/01/07 18:59:16 changed by p_lindheimer

  • version changed from 2.3-branch to SVN-HEAD.
  • milestone changed from 2.3 to 3.0.

moving to svn head. This will be addressed when trunks and routing are addressed. We realized it is a real bug, but understand it is also effect a very very small portion of the population since the problem has existed since the begining of AMP.

12/04/07 23:13:23 changed by p_lindheimer

  • confirmation set to Confirmed.

r5345

some solutions are simple when you let enough time go by. The flags field is currently set to 1 for disabled, but everything else is ok, so starting a sequence of 2 to retain order. It's a 1 byte field but that allows 125 possible settings before it overflows so it should be fine.

12/04/07 23:16:55 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to fixed.