Intrusion detection central unit not dialing out...

[diekmanu]

Hi guys,

we have a Honeywell 561-MB24 alarm system with a build-in ISDN communiction device , which is connected to an OmniPCX 4400 using the Alcatel S0 terminal interface module. Everything worked fine for years, but after some altering of the subscriber devices (Teilnehmerapparate?) in Omnivista 4760 we can't get our 561-MB24 to contact the SMS gateway anymore. The entry for the alarm system wasn't changed though, but some other devices' physical address (because the admin was to lazy to patch...).

This is what the log says:

Code: Select all

06/02/11 09:15:15 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=65 type=19
06/02/11 09:15:18 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=65 type=19
06/02/11 09:15:18 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=146 type=19
06/02/11 09:15:48 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=146 type=19

07/02/11 05:43:21 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=40 type=19
07/02/11 05:43:24 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=40 type=19
07/02/11 05:43:24 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=117 type=19
07/02/11 05:43:54 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=117 type=19

This is the port where the alarm system is connected and we always get the 1279 incident when the system's build-in ISDN device tries to exchange information with the SMS gateway. The index=xxx varies, but it's always a type=19 error message. Is there anything we can do to solve this? Is there any possibility to restore the system state before those settings where made? Will it make sense to reboot the OmniPCX, change ports, etc.?? How can I test the functionality of the S0 terminal module??

Thanks for your help.

[diekmanu]

Code: Select all

INCIDENT NUMBER:     1279
Network indicator:   Alcatel 4400
OBJECT CLASS:        Dhs3Terminal
EVENT TYPE:          ProcessingErrorAlarm  (10)
PROBABLE CAUSE:      Unknown  (0)
SEVERITY:            Minor

"Not expected connection object type : index=P1 type=P2"
"P1 : object self index"
"P2 : object type"
"At the time of object connection function member call"
"type of this object is not expected in the switch case"
"Not any function is carried out and default status is returned"
"Use the following debug command tools (under mtch login) :"
"    - cnx object"
"    - cnx parameter1 index ( parameter1 according to object type )";

Should i debug this...?

[alex]

06/02/11 09:15:15 001001M|02/05/0/006|=3:1279=Not expected connection object type : index=65 type=19

Post "listerm 2 5" output

Is there anything we can do to solve this?

Try to find what has been changed and when with "maohist" command.

Will it make sense to reboot the OmniPCX, change ports, etc.?

If OXE configuration was altered there is no sense in rebooting - the system would start with the wrong configuration anyway.

Should i debug this...?

Sure, Just give it a try.

[diekmanu]

Code: Select all

  ------------------------------------------------------------------------- 
 | Coupler: 2  5 Logic type: CPL_UA    Board: UAI 8  State: IN SERVICE     |
 |-------------------------------------------------------------------------|
 | Cry:Cpl:ac:term|  neqt | typ term   |  dir nb   | Out of service cause  |
 |-------------------------------------------------------------------------|
 |  2   5   0   0 | 00585 |   IBS/3B+D |           |  . . . . . . . . . .  |
 |  2   5   0   1 | 00586 |   IBS/3B+D |           |  . . . . . . . . . .  |
 |  2   5   0   2 | 00587 |   IBS/3B+D |           |  . . . . . . . . . .  |
 |  2   5   0   3 | 00588 |   IBS/3B+D |           |  . . . . . . . . . .  |
 |  2   5   0   4 | 00589 |   IBS/3B+D |           |  . . . . . . . . . .  |
 |  2   5   0   5 | 00590 |   IBS/3B+D |           |  . . . . . . . . . .  |
 |  2   5   0   6 | 00591 |     TM_BOX |           |  . . . . . . . . . .  |
 |  2   5   0   6 | 00877 | FANTOMICT0 |           |  S . . . . . . . . .  |
 |  2   5   1   6 | 00878 |    TYUSGS0 |  295      |  . . . . . . . . . .  |
 |  2   5   2   6 | 00879 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   3   6 | 00880 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   4   6 | 00881 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   5   6 | 00882 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   6   6 | 00883 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   7   6 | 00884 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   8   6 | 00885 |     T_RESU |           |  A . I . . . . . . .  |
 |  2   5   0   7 | 00592 | 4035(MR2_3 |  297      |  A . . . . . . . . .  |
 |-------------------------------------------------------------------------|
 | (A: att_mserv|S: hs smooth), C: hs_defich, I: hs_isolauto, X: hs_isolman|
 | T: hs_terdef U: hs_usdef, P: hs_errparite, B: hs_bascul, Y: hs_cristisol|
  ------------------------------------------------------------------------- 
 |       Nombre total de terminaux hors service :        2                 |
 |       Nombre total de terminaux en service   :        8                 |
 |-------------------------------------------------------------------------|

So "2 5 1 6" is the S0 terminal module with MSN 295 which is correct, but the error occurs on "2 5 0 6".
I checked the mao database with checkinitrem and it seems to be fine. So i guess restoring the mao db doesn't make sense? According to maohist there were user updates, but nothing specific on 295.

[alex]

Code: Select all

  ------------------------------------------------------------------------- 
 |  2   5   0   6 | 00591 |     TM_BOX |           |  . . . . . . . . . .  |
 |  2   5   0   6 | 00877 | FANTOMICT0 |           |  S . . . . . . . . .  |
 |  2   5   1   6 | 00878 |    TYUSGS0 |  295      |  . . . . . . . . . .  |
 |  2   5   0   7 | 00592 | 4035(MR2_3 |  297      |  A . . . . . . . . .  |
 |-------------------------------------------------------------------------|
 [/quote]
It is just wierd output -  It is not supposed to be like that. So first try to reboot.
Check with [b][i]"incvisu"[/i][/b] when those errors appeared for the first time and check [b][i]"maohist"[/i][/b] at the same period.

[quote="diekmanu"]So i guess restoring the mao db doesn't make sense? [/quote]
It makes sense only if you sure that DB does not contain wrong configuration.

[diekmanu]

Code: Select all

====[/DHS3dyn/account/TAXASNLY.DAT : Ticket number 1/1/1]===
(02)      ChargedNumber = 295
(03)    ChargedUserName = S0 Alarm System
(01)       CalledNumber = 541202398xx
(16) TrunkGroupIdentity = 1
(15)      TrunkIdentity = 4
(39)      StartDateTime = 20110208 05:43:18
(11)        EndDateTime = 20110208 05:43:18
(14)           Duration = 0


====[/DHS3dyn/account/TAXASNLZ.DAT : Ticket number 1/1/2]===
(02)      ChargedNumber = 295
(03)    ChargedUserName = S0 Alarm System
(01)       CalledNumber = 541289xx
(16) TrunkGroupIdentity = 1
(15)      TrunkIdentity = 2
(39)      StartDateTime = 20110208 05:43:21
(11)        EndDateTime = 20110208 05:43:21
(14)           Duration = 0

I additionally looked inside the TAX files and noticed that the CalledNumber misses the "0". It's the only entry without the leading "0". Here is the last date, where the connection was made (0171xxx). After that date the alarm system never tries to reach that number again (Attachment)

[diekmanu]

Restart using swinst "Telephone stop/start" ?
Have to wait until the evening...too many people need their telephones right now

[vad]

In tax file you have calling number without 0 - but you can see trunk group 1 (0 was dialed).
If TG1 ISDN - check with "t3" trace - may be problem not in your 561-MB24 but the SMS gateway reject calls.

[alex]

Restart using swinst "Telephone stop/start" ?

You can use that procedure. More on that - check sytem docs - System Documentation/Maintenance/Call Server Stop/Restart Procedure
If you know the time the last call was done check incidents right after that time - may be you get some clue on what happened.

[diekmanu]

To test the funtionality of the S0 Terminal Module I plugged in an ISDN telephone instead of the 561-MB24 (with ext. power supply) and that worked for internal and external calls...

I will check out the t3 trace. t3 C=2 c=5 right? To end this correctly I need to...
tuner km
tuner all=off
tuner clear-traces
dhs3_init -R MTRACER
???