Kernel: Dahdi: Master Changed To TE2/0/2 — Is A Normal Message

Home » Asterisk Users » Kernel: Dahdi: Master Changed To TE2/0/2 — Is A Normal Message
Asterisk Users 20 Comments

I have a server with an asterisk ss7 link connected to a Siemens working well for over a year. A few days ago I started having problems with signaling. I found the following logs in / var / log / messages

Sep 12 11:49:25 call3 kernel: [1018427.030959] dahdi: Master changed to TE2/0/2
Sep 12 11:49:25 call3 kernel: [1018427.120740] dahdi: Master changed to TE2/0/1
Sep 12 11:49:26 call3 kernel: [1018427.789173] dahdi: Master changed to TE2/0/2
Sep 12 11:49:26 call3 kernel: [1018427.884828] dahdi: Master changed to TE2/0/1
Sep 12 11:49:29 call3 kernel: [1018431.209621] dahdi: Master changed to TE2/0/2
Sep 12 11:49:29 call3 kernel: [1018431.300289] dahdi: Master changed to TE2/0/1
Sep 12 11:49:33 call3 kernel: [1018434.763742] dahdi: Master changed to TE2/0/2

If I stop the asterisk and dahdi driver just let the messages continue to appear.

Any ideas??

20 thoughts on - Kernel: Dahdi: Master Changed To TE2/0/2 — Is A Normal Message

  • Sorry, in the last line I try to say … With asterisk stopped, and only driver dahdi up, messages still appear…

  • My guess is you have a cabling problem and that span TE2/0/1 is going into and out of alarm.

    Each time it goes into alarm the core of DAHDI will look for a new span to use as a timing source for asterisk. If TE2/0/1 is the
    “preferred” timing source, when it comes out of alarm, DAHDI will switch the timing back to it.

  • Have you done loopback testing with your telco to make sure your line is clean? I’d point fingers there before blaming the Digium card or a cable.

  • I would still consider the cable. They are funny things and they make nice meters to check them without putting your communications at risk.

    —–Original Message—

  • My ultimate intention is to blame the board, but we have changed teh cable and the LTG in the central and the problem continues, while the same LTG with another server works fine. Is too strange!!

  • I don’t quite understand this comment. Is it possible to reword it?

    Is the LTG the line interface card? Are both these test servers using the same provider drop?

  • It could be nothing more than a dry solder joint on one of the RJ45s. For the sake of five minutes’ work with a soldering iron, that’s got to be worth eliminating.

  • [snip]

    Wouldn’t that void your warranty? I would take it up with Digium support and let them sort it out.

    Regards, Patrick

  • My test were…

    SIEMENS -> LTG1 < --- cable1 - SS7 ---> IVR1 (have errors)
    |-> LTG2 < --- cable2 - SS7 ---> IVR2 (OK)

    minutes later…

    SIEMENS -> LTG1 < --- cable1 - SS7 ---> IVR2 (OK)
    |-> LTG2 < --- cable2 - SS7 ---> IVR1 (have same errors)

    Errors:
    Sep 12 11:49:42 call3 kernel: [1018444.069418] dahdi: Master changed to TE2/0/1
    Sep 12 11:49:48 call3 kernel: [1018449.724411] dahdi: Master changed to TE2/0/2
    Sep 12 11:49:48 call3 kernel: [1018449.823093] dahdi: Master changed to TE2/0/1
    Sep 12 11:49:52 call3 kernel: [1018454.175277] dahdi: Master changed to TE2/0/2
    Sep 12 11:49:52 call3 kernel: [1018454.198138] dahdi: Master changed to TE2/0/1
    Sep 12 11:49:53 call3 kernel: [1018455.493002] dahdi: Master changed to TE2/0/2
    Sep 12 11:49:53 call3 kernel: [1018455.593648] dahdi: Master changed to TE2/0/1

  • No, those committs were to address an issue that only existed between 2.6.0 and 2.6.1. It’s not present in your version of the firmware. However, I would recommend you update to 2.6.1 when you get the chance.

  • Took 3 days without errors like “dahdi: Master changed to TE2/0/2”
    having installed the dahdi 2.6.1
    But I have warnings that I copy below

    [Sep 17 09:25:27] WARNING[24233] mtp.c: MTP2 timer T3 timeout (failed to receive ‘N’, or ‘E’ after sending ‘O’), initial alignment failed on link
    ‘i1’.
    [Sep 17 09:25:28] NOTICE[24233] mtp.c: Got event on link ‘i1’: 5 (0/500).
    [Sep 17 09:25:28] NOTICE[2872] l4isup.c: Unhandled zaptel event 0x5 on CIC0.
    [Sep 17 09:25:28] NOTICE[2872] l4isup.c: Unhandled zaptel event 0x4 on CIC0.
    [Sep 17 09:25:28] NOTICE[24233] mtp.c: Got event on link ‘i1’: 4 (0/11).
    [Sep 17 09:25:29] NOTICE[2872] l4isup.c: Unhandled zaptel event 0x5 on CIC0.
    [Sep 17 09:25:29] NOTICE[24233] mtp.c: Got event on link ‘i1’: 5 (0/500).
    [Sep 17 09:25:29] NOTICE[24233] l4isup.c: T1 timeout (waiting for RLC)
    CIC .
    [Sep 17 09:25:29] WARNING[24233] mtp.c: No signalling links inservice and no cluster receivers alive, dropping packet!
    [Sep 17 09:25:29] WARNING[24233] chan_ss7.c: MTP is now UP on link ‘i1’.
    [Sep 17 09:25:29] NOTICE[24233] mtp.c: Sending TRA to peer on link ‘i1’….
    [Sep 17 09:25:29] WARNING[24233] mtp.c: Got SLTM with unexpected sls=1, OPC152 DPC

  • Shaun, here is the last test that I made.

    Time 0:
    IVR1 (with digiumA) have erros (Master changed to TE2/0/1)
    IVR2 (with digiumB) OK

    Time 1: (just swap spams)
    IVR1 (with digiumB) OK
    IVR2 (with digiumA) have erros (Master changed to TE2/0/1)

    I’m seriously thinking that the problem is in the digiumA

    What you think?

  • Honestly, it’s hard to say without really looking at your complete configuration. At this point it might be quickest if you contact Digium technical support since they are in a position to collect complete information about your setup.

    Cheers, Shaun