Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP

Home » Asterisk Users » Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
Asterisk Users 11 Comments

Hi,

After an upgrade, I discovered yesterday strange things I would like
to share here.

Basically, I’me comparing platforms:
The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk
1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3
and 2.5, I think).
The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk
10.5.1, Libpri 1.4.12, Dahdi 2.6.1.
Both are connected to telco BRI lines in TE/PtmP mode through a
Junghanns QuadBRI board (wcb4xxp driver).
Both handle incoming and outgoing calls correctly, as far as I can tell.

But on the second one, though working fine, Dahdi keeps showing alarm
messages such as:
[71765.784120] wcb4xxp 0000:01:0e.0: new card sync source: port 1
[71767.484151] wcb4xxp 0000:01:0e.0: new card sync source: port 1
[71771.184119] wcb4xxp 0000:01:0e.0: new card sync source: port 2
[71794.184164] wcb4xxp 0000:01:0e.0: new card sync source: port 1

and “pri show spans” mostly (but not always) report worrying status:
PRI span 1/0: Down, Active
PRI span 2/0: In Alarm, Down, Active

On the first box “pri show spans” constantly reports the line is up.

On thing to note is I had to forbid hfcmulti in modprobe.d in the
second box to comply with a warning from dahdi. Without that, I could
see this line in the output of lsmod:
mISDN-core

11 thoughts on - Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP

  • My previous message was incomplete.

    On thing to note is I had to forbid hfcmulti in modprobe.d in the
    second box to comply with a warning from dahdi. Without that, I could
    see this line in the output of lsmod:
    mISDN-core hfcmulti

    1. What is the root cause that makes a board change its sync source ?
    How can I check this ?
    2. How can I get rid of these alarms ?
    3. Shall I report this ?
    4. Waht would you suggest ?

    Regards

    2012/6/21, Olivier :

  • I would think layer 1 going down. Many European telcos for BRI PTMP lines
    drop layer 2 and then layer 1 to conserve power.

    Is the switching of clock sources causing a problem?

    See the chan_dahdi.conf.sample file about the following options.

    You could use the layer1_presence option to make Asterisk ignore those
    alarms.

    You could use the layer2_persistence option to keep layer 2 up. To use
    this option however, requires using libpri SVN 1.4 branch code as current
    released versions do not support the option. Using the layer2_persistence
    option restores behavior that was removed for better Q.921 conformance for
    PTMP after libpri v1.4.10.2 and is why you are seeing a behavior difference
    between versions.

    It is normal with BRI PTMP lines. It is also the reason for the
    layer1_presence and layer2_persistence options.

    Both mISDN and DAHDI have drivers for your BRI card. Only one of them
    should be loaded. Since you are using DAHDI and not mISDN, you should
    load the DAHDI version.

    Richard

  • Have a look at the latest blacklist sample in dahdi trunk
    http://svnview.digium.com/svn/dahdi/tools/trunk/blacklist.sample?view=log

    file: blacklist.sample

    # Some mISDN drivers may try to attach to cards supported by DAHDI. If you
    # have a card which is *not* supported by DAHDI but supported by one of the
    # below drivers you should feel free to remove it from the blacklist below.
    blacklist hfcmulti
    blacklist netjet
    blacklist hfcpci

    I had a similar issue after upgrading from lenny to squeeze 🙁
    System wouldn’t boot as udev tried to launch both wcb4xxp and hfcmulti, as I
    didn’t have wcb4xxp blacklisted as well as the others.
    Only would boot after physically removing BRI card.

    Alec

  • 2012/6/21, Richard Mudgett :
    I’m aware of this energy save mode.
    What surprises me a bit is the frequency with which this happens: a
    rough estimee is 60s or less before the line going down.

    Is there a practical way to double check that ? Using pri debug ?
    “core set debug” ?

    Fortunately, beside having the log files cluttered with Alarm
    messages, the system is working ok.

    This is the option I will try.
    I’ll report my findings here.
    I was aware of this improvement and I can’t wait to see it published.

    So, in a way, a better confiormance to Q.921 introduced the
    requirement to “explicitely ignore Layer1 status changes (in
    BRI/TE/PtmP) in chan_dahdi.conf”.

    Though these layer1 and layer2 settings belongs to Asterisk’s
    chan_dahdi.conf file, maybe an UPGRADE.txt file inside libpri
    directory would be useful to let sysadmins access to this information.

    What about adding an UPGRADE.txt in libpri ?

  • 2012/6/22, Alec Davis :

    I didn’t know about the later two : thanks for sharing this.
    May I add that Linux automatically “allocates” hfc4s8s_l1 driver to
    Junghanns OctoBRI cards which are supported by Dahdi, so I add to
    blacklist them in the past.

    This shows me I should learn :
    – how Linux 2.6.32 (and above) detects PCI boards and “allocates” them
    to mISDN (the one included, I think, in the kernel itself)
    supported by Dahdi or mISDN

    I was a bit luckier thanks to default dahdi.blacklist.conf file.

  • May collide with wcb4xxp

    May collide with wctdm and some other older drivers.

    May collide with zaphfc.

  • 2012/6/22, Olivier :

    My findings, after setting layer1_presence=ignore in chan_dahdi.conf are :

    == Starting D-Channel on span 1
    == Starting D-Channel on span 2
    == Primary D-Channel on span 1 up
    == Primary D-Channel on span 2 up
    foo*CLI> pri show spans
    PRI span 1/0: Up, Active
    PRI span 2/0: In Alarm, Down, Active
    foo*CLI> pri show spans
    PRI span 1/0: In Alarm, Down, Active
    PRI span 2/0: Down, Active
    foo*CLI> pri show spans
    PRI span 1/0: Down, Active
    PRI span 2/0: Down, Active
    foo*CLI> pri show spans
    PRI span 1/0: Down, Active
    PRI span 2/0: Down, Active

    So basically, “pri show spans” still reports lines being down, though
    they are not.
    So, my next option is to downgrade libpri to 1.4.10.2 and hope for a
    better reporting.

  • As basically Asterisk 1.8 requires libpri1.4.11 and up, I had to
    downgrade Asterisk to 1.6 and libpri to 1.4.10.2 to get “pri show
    spans” working back again.

    Having a 1.4.13 published with complete PtmP support will be much appreciated.

    Regards

  • 2012/6/26, Richard Mudgett :

    Do you imply that instead of being afraid of the word “Down” presence,
    I should stand assured by
    the word “Active” presence, the later one meaning “this line can be
    back up on demand” ?

    What would the wording for such situation in 1.4.13, with these layer
    1 and 2 features ?
    Still something like “Down, Active” ?
    And what about using something more specific like “Energy save, Active” ?

    What surprised me a lot is the speed with which each line is put in
    energy save mode : a line remainded up during 20s or so and then put
    down for a while.