____________________________________________________ o \__ \_ _ \_________ \_ O . _/ \_/ _/ __________/ | __/ +----\ | \ | \ | \----+ : \_______l_______/\________________/\_______________/ : + -------------------------+ Psyclone '96 +------------------------- + þ M M þ | E Trashed Print-out Interpretation E | þ D D þ + ----------------------------- LONDON ----------------------------- + This is for you first time trashers who run up to the bin, stuff all the papers into a bag and then run home yelping with joy. All those computer printouts that are produced by the TXE exchange equipment and then promptly discarded by bt, despite being of interest to most phreakers cannot be fully understood without a certain key knowledge. This knowledge is now in your possesion. Introduction ============ This file contains information on how to "decode" the letters and numbers found on the most common of TXE exchange printouts, for me these are : PRINT RECORD, SOFTWARE REPORT, DATA FOR SYMPTOM and some printed lists of archives. There are probably others floating around, but the majority of it is dealt with in here. The following information also involves other files, so if you wanna find out more about these systems (and the TXE4 exchange) then look out for other MED releases. Main abbreviations used are as follows: TXE4 : Telephone Exchange Electronic 4. Replaced the TXS/TXK/TXE2/TXE3 exchanges and was replaced by the TXD exchanges. TXEE : Telephone Exchange Electronic Enhanced. TXE4 with Enhancement upgrage. MMI : Man Machine Interface. Equipment interface for engineers. Driven by Man Machine Language (MML) commands. FP : Functional Processor. SMF : System Manager Facility. CMH : Call Monitoring Handler. SCH : Set-up Call Handler. CDF : Charge Determination Facility. In the TXE exchange the SMF initiates all the printouts via each of the system printers, these are controlled by either MMI options or they are automatically triggered by the system status, so basically they constantly spawn reams of paper. The only reason they are printed out is to get a hard copy of the data for reference, after a brief storage period they are discarded. The data which is automatically printed is as follows : -Provision/cessation bulk meter readings -Print record -Software report -Hardware fault -Archiving of data Provision/Cessation Bulk Meter Reading :- ====================================== Whenever a customers line is provided or ceased, a printout is initiated from the particular SMF currently being used for the MMI transaction. This is printed out, and then disposed of, thus reincarnating it as trash. Example printout for a normal line : 11/06/95 WED 11:34:14 SEQ NO: 218 PROVISION BULK METER READINGS Directory number : 9991234 PBX suffix : 0 Non-item count : 351 Non-item units : 5952 Item count : 1351 Item units : 346951 END OF REPORT Example printout for a PBX line : 11/06/95 WED 11:47:05 SEQ: 223 CESSATION BULK METER READINGS Directory number : 9991235 PBX suffix : 2 Non-item count : 2398 Non-item units : 609144 Item count : 2374 Item units : 609148 END OF REPORT Explanation :- For both the examples, the figures in the first line show the date, time, and sequence number. The sequence number is incremented on each provision or cessation or any other MMI transaction. Directory number - is the combined exchange code and customer's number. PBX suffix - is shown as 0 for non-pbx customers or the line number for pbx customers. Non-item count - is the number of calls not requiring itemisation that have been made from the directory number. Non-item units - is the number of units accrued from the non-itemised call count for the directory number. Item count - is the number of calls requiring itemisation that have been made from the directory number. Item units - is the number of units accrued from the itemisation call count for the directory number. Print Record :- ============ A print record can be generated for a number of reasons. It is not a fault printout but is used to record specific incidents. If the system detects one of the following things then it automatically prints :- -Printer meter check -Calling line indication failure -Invalid/unidentified number dialled -Ineffective call -Extra long call -Call made from spare line -Nominated outgoing number call -Nominated line indication Incorporated within the print record is some info on the following :- -Any reasons for itemisation (1-6) -Qualifier status (1-6) -Subs category (1-3) -Call type group (1) -Local print reasons (1-10) The numbers next to the conditions are the number of options (different reasons). In the print record to show which of the options are relevant the character Y is printed, and to show which of the options are not relevant a + is printed. You can see this in the example... Typical printout : PRINT RECORD NNI xxxxxxx 09/96 00:40:53 NN 16700661 /000 DIALLED DIGITS 6708170 REVENUE GROUP 101 START 09/06 00:40:40 DURATION 00:00:12.58 LINKED Unlinked FREEPHONE N HANDLING CHARGE 000 DURATION CHARGE 0000001 BULK NON-ITEM N TARIFF GROUP 01 CHARGE BAND 01 ITEMISATION REASONS +++Y++ QUALIFIER ++++++ SUBS CATG ++Y CALL TYPE GP 0 LOCAL PRINT REASONS +++++++++Y END Explanation :- NNI : Network Node Identity } 09/06 : day/month } Line 1 00:40:53 : Time - middle of night !? } NN1816700661 : National Number (01816700661) } PBX Suffix (000=not applicable) } Dialled digits : Dialled digits from 6700661 } Line 2 (670 8170) } Revenue group 101 : Revenue number for a local call } Duration : How long the call was, measured in } hours minutes, seconds and milliseconds. } Linked/Unlinked : Tells you if the charge records for a } Line 3 call are linked (first linking and last) } or unlinked. } Freephone N : if costing cash or not. } Handling charge 000 : Shows the call handling charge } in units. } Duration charge : shows the length of the call in } units. } Line 4 Bulk non-item N : Used to show if the calls are } itemised or not. Strangely 'nuff } Y = not itemised and } N = itemised ... } Tariff group : Shows calling line's tariff group } Line 5 Show variable information dependant on type of call, } customer and system requirements. The active options } Lines 6 are shown by the character Y. } and 7 In the print records where it has +++Y+++ or +Y++++ or sumthing like that it is just telling you which options are in use. If there is no Y in the line of +'s then none of the options have been used. I have made this nice little table to make it nice and easy to decode all the +'s and Y's for ya. ITEMISATION REASONS Y+++++ : Nominated outgoing number call ITEMISATION REASONS +Y++++ : Part bill required ITEMISATION REASONS ++Y+++ : Long duration ITEMISATION REASONS +++Y++ : Customer requested ITEMISATION REASONS ++++Y+ : Admin requested ITEMISATION REASONS +++++Y : Admin requested for all customers / designated cicuits QUALIFIER Y+++++ : Ineffective calls QUALIFIER +Y++++ : Incoming calls QUALIFIER ++Y+++ : Invalid dialled digits QUALIFIER +++Y++ : CLI failure QUALIFIER ++++Y+ : Printer meter check QUALIFIER +++++Y : No CSA pulse SUBS CATG Y++ : White meter active SUBS CATG +Y+ : Itemisation billing levels SUBS CATG ++Y : All calls itemised LOCAL PRINT REASONS Y+++++++++ : White meter LOCAL PRINT REASONS +Y++++++++ : No CSA LOCAL PRINT REASONS ++Y+++++++ : Printer meter check LOCAL PRINT REASONS +++Y++++++ : CLI failure LOCAL PRINT REASONS ++++Y+++++ : Invalid dialled digits LOCAL PRINT REASONS +++++Y++++ : Ineffective calls LOCAL PRINT REASONS ++++++Y+++ : Long duration LOCAL PRINT REASONS +++++++Y++ : Calls made on a spare line LOCAL PRINT REASONS ++++++++Y+ : Nominated outgoing number LOCAL PRINT REASONS +++++++++Y : Monitored line indication So there! Now you can see what the useless piles of paper mean! Sofware reports :- =============== In every FP, an area of software is specially dedicated to fault detection, classification, and interfacing with it's alarm card. Processors can detect a fault in either of these :- -FP and any of it's dependants (eg. CMH/CEL) -Any associated FP (eg. SCH) In the first case FP, detects a fault in its own program/data or that of its dependants. The software within FP can detect the fault and then convert it into a symptom. The fault symptom is passed on to the classification software which classifies the fault type and, if possible, reconfigures the hardware eg OS Faulty. In the case of most software detected faults, a reload of the program is requested from SMF. The FP will always signal the fault symptom to the SMF for possible printout (software report or hardware fault printout). A functional processor can also detect, via the software routines, a fault in the program/data of an associated FP. As its own symptom handling software will be unable to classify this type of fault, the symptom is passed on to the SMF for symptom processing. The software also interfaces with its associated alarm card to allow hardware detected faults to be registered. Software Fault printout format is as follows: SOFTWARE REPORT (A) NNI 9991234 18/09 11:13:55 SOURCE SMF_A STATUS CATEGORY 004 ALARM DEFERRED SYMPTOM ID 183 CL CL 5.7 item.pas 478 Call originated from a spare line 09 12 0B 0D 26 41 23 03 07 FF FF 00 00 34 02 03 F3 FF FF FF FF FF FF END Explaination :- SOFTWARE REPORT : Report title } (A) : Printer (A or B) } NNI : Seven digit number identifying the } network node } Line 1 18/09 : Date on which fault is detected } (day/month) } 11:13:55 : Time of day (24 hour clock) } (hours:mins:secs) } SOURCE : Reporting FP identity (ie SMF A) } STATUS CATEGORY : System error code (a number between } 0 and 255) } ALARM : Alarm level (ie prompt, deferred or } no alarm) } Line 2 SYMPTOM ID : A number between 0 and 65535 used } with the system error code to } determine the details required on } the fault report. } TASK IDENTIFIER : Up to 30 characters which may } identify the software task which is } Line 3 the source of the fault report. } EXPLAINATORY TEXTS : This line of text wlil indicate the } cause of the detected fault. In the } case of the example a call has been } Line 4 made from a line which the } enhancement equipment has shown to } be spare. } HEXADECIMAL DATA : Up to 26 bytes of data in hexadecimal } code. If more than 26 bytes are } produced by the software routine which } Line 5 generated the symptom, the extra bytes } are printed out after line 8. } END : end of report. } Line 6 For the example used in this text, to find the identity of the calling line which made the call it will be necessary to decode part of the line of hexadecimal data. The source of this software report is the SMF and the symptom identity number is 183. The symptom number lists the hexadecimal bytes of the message in order. Bytes 0 to 4 Date and time of seizure (month day hrs mins secs) Bytes 5 to 10 National Number (with each byte reversed) Bytes 11 and 12 PBX suffix (will be 00 if not a PBX line) Bytes 13 to 22 Dialled digits (followed by FF empty bytes) The most important items are the national number and the PBX suffix. The national number is quoted as being formatted in accordance with ES10, as are the dialled digits. Put simply, this means that the bytes must be read by reversing the order of the digits in each byte. Also, the prefix of 0 will be missing from the number. From the printout, bytes 5 to 10 are: 41 23 03 07 FF FF. Therefore the originator of the call was 014-32-3070, the character F being used to fill spaces not required. Although not specified, any PBX suffix will be encoded in hexadecimal and must be read in reverse byte order. So if the printout showed the suffix to be: 0C 00, this would be line 12 of the PBX. Not all printout analysis can be carried out in this way. In some cases, it will be necessary to refer to a fault dictionary. Here is another example of a software report:- Analysis of Software Report using the Fault Dictionary SOFTWARE REPORT (A) NNI 9991234 23/09 09:35:43 SOURCE SCH1A STATUS CATEGORY 005 ALARM DEFERRED SYMPTOM ID 74 SCH_FSM_TASK Calling Line Identification Failure FF FF 01 0F 73 00 00 01 5A 02 0B 16 00 00 14 12 83 67 91 31 00 5A 5A 5A END DATA FOR SYMPTOM 74 FF FF 01 0F 73 00 00 01 5A 02 0B 16 00 00 14 12 83 67 91 31 00 5A 5A 5A 07 04 03 02 04 07 06 03 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 01 04 D3 99 00 00 5A 04 00 0A 0F 0F 00 00 0F 06 A2 07 10 21 53 FF AA 01 FF FF 00 00 00 00 5A 5A 5A 5A To find more information on the faults, reference can be made to the Faults Dictionary document, this provides explanatory text on various details such as the symptom id's. In the above case, the engineer would refer to symptom identity 74, under the SCH section of the fault dictionary. Having established that the enhancement equipment has been unable to identify the calling line you may consult the fault dictionary for further information on the fault. For example, byte 6 tells us this is an own exchange call and bytes 14 to 16 contain the identity of the line from which the call was made (EN 121384). Nearly all software reports will be dealt with in one of these two ways. The fault dictionary will list the information required either under the symptom identity number for the relevant section or in an appendix to that section. SOFTWARE REPORT (A) NNI 9999032 23/08 16:59:36 SOURCE CMH1B STATUS CATEGORY 013 ALARM PROMPT SYMPTOM ID 180 cmh_cel: one_sec_cel_check voting error in CEL error word 01 00 48 02 00 END Referring to the CMH section of the fault dictionary, symptom identity 180, the bytes of the message are listed. Byte 0 CEL identity Byte 1 Exchange type (see Appendix R) Bytes 3 & 2 Error Word 1 (see Appendix H) Byte 4 Error Word 2 (see Appendix H) From the printout, byte 0 is 01 (CEL number 1) and byte 1 is 00 (RD exchange). Bytes 3 and 2 need to be changed into a bit format: Byte 3 = 02 Byte 2 = 48, therefore the bits are : 0000 0010 0100 1000 The bits number from right to left, starting at bit number 0. So bits 3, 6 and 9 are at logic 1. To evaluate these bits you must look in Appendix H of the faults dictionary, where it can be read that they indicate an LBa error, a PKa error and a PS13Sa error. In this example it is reasonable to assume that a fault exists on plane 1 of the U value connected to CEL 1. Error codes are also listed. Sometimes when a fault symptom is classified within the symptom handling software, more than one fault option may be a possibility. If this happens then more than one hardware/software fault report is printed but all printouts are given the same time and are printed consecutively. Hardware Fault Printout ======================= Hardware fault printouts can be instigated by the Alarm Card associated with each FP and also by software reload requests. The printouts take the following format: HARDWARE FAULT (A) NNI 9998031 29/07 15:28:17 SOURCE CMH1A STATUS CATEGORY 011 ALARM PROMPT SYMPTOM ID 8 RESOURCE NAME FAN NUMBER 001 PARENT _____ NUMBER __ OLD STATUS IN_SERVICE NEW STATUS OS_FAULTY RACK SCH CMH 1 SHELF D POSITION 023 FAN failure detected by hardware END Interpretation:- HARDWARE FAULT : Report title } (A) : Printer (A or B) } NNI : Seven digit number identifying the } Line 1 network node } 29/07 : Date (day/month) } 15:28:17 : Time (hrs:mins:secs in 24 hr clock) } SOURCE : FP identity (ie CMH 1A) } STATUS CATEGORY : System error code (between 0 and 255) } ALARM : Alarm level (prompt, deferred or no } alarm } Line 2 SYMPTOM ID : A number between 0 and 65535 used by } the SMF to determine details required } on the fault report. } RESOURCE NAME : Six character name of faulty unit } NUMBER 001 : Resource number of faulty unit } Line 3 PARENT : Identity of parent resource } NUMBER : Number of parent resource } OLD STATUS : Unit status prior to detection of the } fault } Line 4 NEW STATUS : Current status (after detection) } RACK : SCH CMH 1 } SHELF : D } Line 5 POSITION : 023 } EXPLANATORY TEXT : Each symptom is unique to a particular } event within the TXEE and has a line } of explanatory text associated with } it. The text is significant as a } Line 6 detected fault may have been caused in } one of several ways - how it was } detected may help in fault diagnosis. } HEXADECIMAL DATA : Up to 26 bytes of data can be printed, } if more than 26 are produced by the } software routine which generated the } symptom, extra bytes are printed out } Line 7 after line 8 (END). As in this case, a } hardware fault will not always result } in any bytes of data being produced. } END : End of report } Line 8 Generation of printouts: In the event of the alarm card detecting a hardware fault, an error word is sent from the alarm card to the FP. The error word signals the status of the peripheral hardware to the FP ie fans, temperature sensors, DC-DC converters etc. The FP sends fault symptom to the SMF which controls the hardware fault printout. When the fault is cleared the new status is signalled as before and another printout is generated to indicate the new status. See examples below: HARDWARE FAULT (A) NNI 9998031 29/07 15:12:04 SOURCE CMH1A STATUS CATEGORY 011 ALARM, PROMPT SYMPTOM ID 8 RESOURCE NAME FAN NUMBER 001 PARENT _____ NUMBER __ OLD STATUS IN_SERVICE NEW STATUS OS_FAULTY RACK SCH CMH 1 SHELF D POSITION 023 FAN failure detected by hardware END HARDWARE FAULT (A) NNI 9998031 29/07 15:12:07 SOURCE CMH1A STATUS CATEGORY 012 ALARM NO ALARM SYMPTOM ID 9 RESOURCE NAME FAN NUMBER 011 PARENT _____ NUMBER __ OLD STATUS OS_FAULTY NEW STATUS IN_SERVICE RACK SCH CMH 1 SHELF D POSITION 023 FAN recovery detected by hardware END A hardware fault can be produced to inform users of the status of a particular FP if a reload has been requested. This forms part of a reload printout sequence, as shown below. Note that in practise other printouts may occur to interupt the sequence. HARDWARE FAULT (A) NNI 9998031 29/07 14:35:40 SOURCE SMF_A STATUS CATEGORY 013 ALARM NO_ALARM SYMPTOM ID 219 RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __ OLD STATUS OS_RELOAD NEW STATUS OS_RELOAD RACK SCH CMH 1 SHELF D POSITION 035 Functional Processor has requested a reload 00 48 00 00 00 50 50 50 50 50 C7 C7 C7 C7 C7 C7 C7 C7 C7 C7 END HARDWARE FAULT (A) NNI 9998031 29/07 14:35:46 SOURCE SMF_A STATUS CATEGORY 014 ALARM NO_ALARM SYMPTOM ID 220 RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __ OLD STATUS OS_RELOAD NEW STATUS OS_RELOAD RACK SCH CMH 1 SHELF D POSITION 035 Functional Processor reload commencing 00 79 00 00 END HARDWARE FAULT (A) NNI 9998031 29/07 14:46:40 SOURCE SMF_A STATUS CATEGORY 013 ALARM NO_ALARM SYMPTOM ID 336 RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __ OLD STATUS OS_STARTUP NEW STATUS IN_SERVICE RACK SCH CMH 1 SHELF D POSITION 035 Reload of Functional Processor completed 00 3D 00 00 END HARDWARE FAULT (A) NNI 9998031 29/07 14:46:43 SOURCE SMF_A STATUS CATEGORY 013 ALARM NO_ALARM SYMPTOM ID 25 RESOURCE NAME CMH1A NUMBER __ PARENT _____ NUMBER __ OLD STATUS IN_SERVICE NEW STATUS IN_SERVICE RACK SCH CMH 1 SHELF D POSITION 035 An FP completed alignment 00 3F 00 00 END BSEACH Reports ============== BSEARCH is a nightly routine, comparing the TXEE exchange line data base with the TXE4 Cyclic Store using the associated equipment number in the TXEE exchange Line Data base as the search data. This is basically to check that all the line states are ok, if a fault is detected printouts will be triggered. There follows 6 examples of different types of BSEARCH printouts. 1. This report shows the first DN used in the BSEARCH period. 13/08 THU 00:35:06 SEQ NO: 2013 BSEARCH ------- First DN of the search period : 4321234 suffix 0 End of report 2. This report tells us that in X time slot of EN 151413, the TXEE Exchange Line Data does not compare with the TXE4 C/S data 9314 56700. 13/08 THU 00:35:29 SEQ NO: 2013 BSEARCH ------- EN 151413 X slot routine check failed. TXEE data is DN 4321234 suffix 0 C/S data is 9314 567000 End of report 3. This report tells us that X time slot of EN 141312 was not found in the TXE4 C/S data. 13/08 THU 00:35:41 SEQ NO: 2013 BSEARCH ------- EN 141312 X slot routine check failed. TXEE data is DN 4321234 suffix 0 End of report 4. The above BSEARCH report (3) is normally followed by Software Report No 498. This states that the EN held by the TXEE Exchage Line Data base is out of range for the TXE4 exchange. SOFTWARE REPORT (B) NNI 9998031 13/08 00:35:41 SOURCE SMF_B STATUS CATEGORY 014 ALARM NO_ALARM SYMPTOM ID 498 MMI 5.28 dsrch.pas 4131 MCU failed to find EN that TXEE holds 01 00 END 5. Stop Reports tell us what the last DN in the BSEARCH period is. 13/08 THU 00:36:56 SEQ NO: 2013 BSEARCH ------- Last DN of the search period : 4327123 suffix 0 End of report 6. When the number of BSEARCH failures exceeds the theshold set in the "BSEARCH Menu General Maintenance" a deferred alarm is raised and the following printout is triggered. SOFTWARE REPORT (B) NNI 9998031 13/08 00:36:57 SOURCE SMF_B STATUS CATEGORY 014 ALARM DEFERRED SYMPTOM ID 500 MMI 5.28 dsrch.pas 2726 No of TXE/MCU misalignment errors exceeded threshold. 0A 00 END