dynamic spans: /etc/zaptel/dynamic.conf ?

Hi

As some of you might have noticed, recently Brett Carrington
from
Redfone has submitted the driver for their TDMoE device. It
uses a
different protocol than the current ztd-eth driver, and
hence will be
added as an additional driver: ztd-ethmf.

http://bugs.digium.com/1
2241

While this one should get into Zaptel soon, it got me
looking into the
whole "dynamic spans" in Zaptel, and I didn't
really like what I saw.
Consider the following commet in the bug report:

  http://bugs.digium
.com/12241#84346

(How to make a change without crashign things)

This is not a regression from the new driver, because the
issues are
basically with the way dynamic spans work in Zaptel. 


A few words about dynamic spans: 

In zaptel.conf you can have:

 
dynamic=<driver>,<address>,<numchans>,<
timing>

Where <driver> is the name of the driver (e.g. eth),
<address> is the
driver specific address (like a MAC for eth),
<numchans> is the number
of channels, and <timing> is a timing priority, like
for a normal span.

The drivers we currently have are "loc" (a
loopback to a local span) and
"eth" (TDMoE). The patch adds "ethmf"
which is an improved TDMoE. 

I believe that part of the problem with dynamic spans is
that spas are
generated as part of the run of ztcfg. ztcfg's job is to
apply
configuration to spans. It should be safe to run twice (too
many people
use 'ztcfg -vv' as a debugging aid). It should be safe to
run it once
after a failure and then again in a successful run.

So my initial suggestion here is to move the
"dynamic" keyword to a
different configuration file. I propose to do that by the
way of
convension (at least first), not through code changes:

  # first load modules
  # then:
  if [ -r /etc/zaptel/dynamic.conf ]; then
    ztcfg -c /etc/zaptel/dynamic.conf
  fi
  
  # ...

  ztcfg

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohenxorcom.com
+972-50-7952406           mailto:tzafrir.cohenxorcom.com
http://www.xorcom.com 
iax:guestlocal.xorcom.com/tzafrir

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Fri, Mar 21, 2008 at 09:01:57AM -0400, Brett Carrington
wrote:
> Tzafrir,
>   I appreciate your commitment to improving the dynamic
span
> subsystem. I agree that over all the implementation is
clunky and in
> need of a lot of attention.
> 
>   Although separating the dynamic spans into separate
files will
> prevent accidental crashes in some cases it does not
fix the real
> issue. Instead it merely hides the underlying problem
and lulls the
> user into a false sense of security (woe be unto them
when they try to
> intentionally reconfigure ztdynamic spans without
following the
> procedure I outlined in the bug.) Based on this I am
not sure if
> changing the configuration file conventions is worth
the confusion it
> may create?

I'm not trying to ignore the problem. But I realise that I
can't just
change a form / interface and hope it will stick.

I speculatethat with my suggestion well-behaving utilities
(sticking
with very simple guidelines) will not be able to crash, and
I still
don't change any interface.

The guidelines are indeed very simple. I'm still not 100%
certain that
they make things crash-prone. Do they?

Are there any technical messures of enforcing them? At the
level of
ztcfg - easily - only process "dynamic" if an
extra command-line flag is
used. But this is still pretending. Anybody with write
access to
/dev/zap/ctl (and Asterisk is one - if you don't run
Asterisk as root.
And you don't run Asterisk as root, do you?).

Do we give /dev/zap/ctl different write permissions? Allow
only root to
write to it (but allow Asterisk to read from it). Asterisk's
chan_zap
uses ZT_SET_DIALPARAMS so this will break asterisk. I did
not check
further.

And yes - ztdynamic.c is buggy and ztd-eth.c is buggy. But
before
jumping up and fixing them, I'd like to have an idea at
where we're
heading.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohenxorcom.com
+972-50-7952406           mailto:tzafrir.cohenxorcom.com
http://www.xorcom.com 
iax:guestlocal.xorcom.com/tzafrir

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev