[asterisk-ss7] Bug in libss7 with CGB handling
Gregory Massel
greg at csurf.co.za
Tue Oct 9 19:19:10 CDT 2012
I've picked up a bug in libss7.
The remote end is sending me two CGB messages, the first to block CICs
1-15 and the second to block CICs 17-31.
My end is responding correctly with CGBA messages, however, only CICs
1-15 show a remote block, despite it acknowledging the block for CICs 17-31.
Herewith the debug:
[1] Len = 17 [ 86 85 0e c5 08 03 62 11 01 00 18 01 01 03 0e ff 7f ]
[1] FSN: 5 FIB 1
[1] BSN: 6 BIB 1
[1] <[1] MSU
[1] [ 86 85 0e ]
[1] Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[1] [ c5 ]
[1] OPC 1416 DPC 776 SLS 1
[1] [ 08 03 62 11 ]
[1] CIC: 1
[1] [ 01 00 ]
[1] Message Type: CGB
[1] [ 18 ]
[1] --FIXED LENGTH PARMS[1]--
[1] Circuit Group Supervision Indicator:
[1] Type indicator: Hardware Failure oriented
[1] [ 01 ]
[1] --VARIABLE LENGTH PARMS[1]--
[1] Range and status:
[1] Range: 14
[1] [ 03 0e ff 7f ]
[1]
Linkset 1: Processing event: Unknown Event
[1] Len = 17 [ 85 87 0e c5 88 05 c2 40 01 00 1a 01 01 03 0e ff 7f ]
[1] FSN: 7 FIB 1
[1] BSN: 5 BIB 1
[1] >[1] MSU
[1] [ 85 87 0e ]
[1] Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[1] [ c5 ]
[1] OPC 776 DPC 1416 SLS 4
[1] [ 88 05 c2 40 ]
[1] CIC: 1
[1] [ 01 00 ]
[1] Message Type: CGBA
[1] [ 1a ]
[1] --FIXED LENGTH PARMS[1]--
[1] Circuit Group Supervision Indicator:
[1] Type indicator: Hardware Failure oriented
[1] [ 01 ]
[1] --VARIABLE LENGTH PARMS[1]--
[1] Range and status:
[1] Range: 14
[1] [ 03 0e ff 7f ]
[1]
[1] Len = 17 [ 87 86 0e c5 08 03 62 11 11 00 18 01 01 03 0e ff 7f ]
[1] FSN: 6 FIB 1
[1] BSN: 7 BIB 1
[1] <[1] MSU
[1] [ 87 86 0e ]
[1] Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[1] [ c5 ]
[1] OPC 1416 DPC 776 SLS 1
[1] [ 08 03 62 11 ]
[1] CIC: 17
[1] [ 11 00 ]
[1] Message Type: CGB
[1] [ 18 ]
[1] --FIXED LENGTH PARMS[1]--
[1] Circuit Group Supervision Indicator:
[1] Type indicator: Hardware Failure oriented
[1] [ 01 ]
[1] --VARIABLE LENGTH PARMS[1]--
[1] Range and status:
[1] Range: 14
[1] [ 03 0e ff 7f ]
[1]
Linkset 1: Processing event: Unknown Event
[1] Len = 17 [ 86 88 0e c5 88 05 c2 40 11 00 1a 01 01 03 0e ff 7f ]
[1] FSN: 8 FIB 1
[1] BSN: 6 BIB 1
[1] >[1] MSU
[1] [ 86 88 0e ]
[1] Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[1] [ c5 ]
[1] OPC 776 DPC 1416 SLS 4
[1] [ 88 05 c2 40 ]
[1] CIC: 17
[1] [ 11 00 ]
[1] Message Type: CGBA
[1] [ 1a ]
[1] --FIXED LENGTH PARMS[1]--
[1] Circuit Group Supervision Indicator:
[1] Type indicator: Hardware Failure oriented
[1] [ 01 ]
[1] --VARIABLE LENGTH PARMS[1]--
[1] Range and status:
[1] Range: 14
[1] [ 03 0e ff 7f ]
[1]
Now, this part doesn't make sense. The block only shows on CICs 1 to 15:
rba2*CLI> ss7 show channels
link Chan Lcl Rem Call SS7 Channel
set Chan Idle Blk Blk Level Call Name
1 1 No No Yes Idle No
1 2 No No Yes Idle No
1 3 No No Yes Idle No
1 4 No No Yes Idle No
1 5 No No Yes Idle No
1 6 No No Yes Idle No
1 7 No No Yes Idle No
1 8 No No Yes Idle No
1 9 No No Yes Idle No
1 10 No No Yes Idle No
1 11 No No Yes Idle No
1 12 No No Yes Idle No
1 13 No No Yes Idle No
1 14 No No Yes Idle No
1 15 No No Yes Idle No
1 17 Yes No No Idle No
1 18 Yes No No Idle No
1 19 Yes No No Idle No
1 20 Yes No No Idle No
1 21 Yes No No Idle No
1 22 Yes No No Idle No
1 23 Yes No No Idle No
1 24 Yes No No Idle No
1 25 Yes No No Idle No
1 26 Yes No No Idle No
1 27 Yes No No Idle No
1 28 Yes No No Idle No
1 29 Yes No No Idle No
1 30 Yes No No Idle No
1 31 Yes No No Idle No
(unrelated additional channels not shown but none of them have
inadvertently blocked)
rba2*CLI> dahdi show channels group 1
Chan Extension Context Language MOH Interpret Blocked
State Description
1 incoming-vodaco default R In Service
2 incoming-vodaco default R In Service
3 incoming-vodaco default R In Service
4 incoming-vodaco default R In Service
5 incoming-vodaco default R In Service
6 incoming-vodaco default R In Service
7 incoming-vodaco default R In Service
8 incoming-vodaco default R In Service
9 incoming-vodaco default R In Service
10 incoming-vodaco default R In Service
11 incoming-vodaco default R In Service
12 incoming-vodaco default R In Service
13 incoming-vodaco default R In Service
14 incoming-vodaco default R In Service
15 incoming-vodaco default R In Service
17 incoming-vodaco default In
Service
18 incoming-vodaco default In
Service
19 incoming-vodaco default In
Service
20 incoming-vodaco default In
Service
21 incoming-vodaco default In
Service
22 incoming-vodaco default In
Service
23 incoming-vodaco default In
Service
24 incoming-vodaco default In
Service
25 incoming-vodaco default In
Service
26 incoming-vodaco default In
Service
27 incoming-vodaco default In
Service
28 incoming-vodaco default In
Service
29 incoming-vodaco default In
Service
30 incoming-vodaco default In
Service
31 incoming-vodaco default In
Service
(unrelated additional channels not shown but none of them have
inadvertently blocked)
I'm not sure if this has anything to do with the fact that both CGB
messages come in close succession, but, at an SS7 level, the response it
correct. Perhaps there is a problem with the way libss7 is feeding this
back to chan_dahdi?
The really annoying part of this is that I cannot locally block the CICs
because the command "ss7 block cic 1 17" because that command doesn't
let one specify which link within the linkset to apply to. I have
redundant links within the linkset but that command blocks both CIC 17
on link 1 of linkset 1 as well as CIC 17 on link 2 of linkset 1. We
really need the syntax to be something link "ss7 block cic <linkset>
<dpc>/<cic>" so that it can deal with identical CIC numbers to different
defaultdpc's within the same redundant linkset.
All of this also highlights another major shortcoming of
libss7/chan_dahdi; they do not automatically issue CGB messages to the
other side and block CICs when the E1 goes into an alarm state. Now
we're relying on the remote end to detect the alarm and block the CICs
but that doesn't work properly because of a bug in the CGB processing...
--Greg
More information about the asterisk-ss7
mailing list