| Greg's Telstra line fault in Echunga |
|
||||||
|
|
|
|
|||||||||||
In the night of 11 to 12 July 2003, we had heavy rainfall, just the kind of weather that causes Telstra's old, flaky lines to fail. The first sign was:
Jul 12 12:00:35 echunga pppd[1076]: Modem hangup, connected for 44647 minutes Jul 12 12:01:08 echunga pppd[1076]: Serial connection established. Jul 12 12:01:09 echunga pppd[1076]: Using interface ppp0 Jul 12 12:01:09 echunga pppd[1076]: Connect: ppp0 <--> /dev/cuaa1 Jul 12 12:01:26 echunga pppd[1076]: Modem hangup, connected for 1 minutes Jul 12 12:02:35 echunga pppd[1076]: Serial connection established. Jul 12 12:02:36 echunga pppd[1076]: Using interface ppp0 Jul 12 12:02:36 echunga pppd[1076]: Connect: ppp0 <--> /dev/cuaa1 Jul 12 12:02:40 echunga pppd[1076]: local IP address 139.130.136.138 Jul 12 12:12:14 echunga pppd[1076]: Modem hangup, connected for 9 minutes Jul 12 12:14:27 echunga pppd[1076]: Modem hangup, connected for 1 minutes Jul 12 12:23:48 echunga pppd[1076]: Modem hangup, connected for 8 minutes Jul 12 12:24:18 echunga pppd[1076]: Serial connection established. Jul 12 12:24:19 echunga pppd[1076]: Using interface ppp0 Jul 12 12:24:19 echunga pppd[1076]: Connect: ppp0 <--> /dev/cuaa1 Jul 12 12:24:49 echunga pppd[1076]: LCP: timeout sending Config-Requests Jul 12 12:24:49 echunga pppd[1076]: Connection terminated, connected for 1 minutes Jul 12 12:42:19 echunga pppd[1076]: Modem hangup, connected for 16 minutes
The trouble was, the other lines were working fine. I connected to the spare line and everything worked again. Under those circumstances, it's difficult to report a fault.
The following morning I checked the logs: things were no longer so fine:
Jul 13 03:39:29 echunga pppd[1076]: Modem hangup, connected for 889 minutes Jul 13 04:09:04 echunga pppd[1076]: Modem hangup, connected for 29 minutes Jul 13 04:19:47 echunga pppd[1076]: Modem hangup, connected for 10 minutes Jul 13 10:20:18 echunga pppd[1076]: Modem hangup, connected for 359 minutes Jul 13 10:24:25 echunga pppd[1076]: Modem hangup, connected for 3 minutes Jul 13 10:36:54 echunga pppd[1076]: Modem hangup, connected for 11 minutes
After this, I decided to try the correct line again. The first hangup was the result of changing back:
Jul 13 11:02:58 echunga pppd[1076]: Modem hangup, connected for 25 minutes Jul 13 11:03:42 echunga pppd[1076]: Connect script failed Jul 13 11:04:47 echunga pppd[1076]: Serial connection established.
That second message means that, although a phone connection was established, the signal quality was too low to set up a connection. The second time round, a minute later, it succeeded.
I tried pinging the other end of the PPP link. There was no other traffic. This is what I got:
$ ping 139.130.136.129 64 bytes from 139.130.136.129: icmp_seq=0 ttl=255 time=11077.716 ms 64 bytes from 139.130.136.129: icmp_seq=1 ttl=255 time=11047.839 ms 64 bytes from 139.130.136.129: icmp_seq=2 ttl=255 time=13069.397 ms 64 bytes from 139.130.136.129: icmp_seq=3 ttl=255 time=12087.783 ms 64 bytes from 139.130.136.129: icmp_seq=4 ttl=255 time=11107.986 ms 64 bytes from 139.130.136.129: icmp_seq=5 ttl=255 time=10126.921 ms 64 bytes from 139.130.136.129: icmp_seq=6 ttl=255 time=9433.420 ms 64 bytes from 139.130.136.129: icmp_seq=7 ttl=255 time=10090.648 ms 64 bytes from 139.130.136.129: icmp_seq=8 ttl=255 time=9148.915 ms 64 bytes from 139.130.136.129: icmp_seq=9 ttl=255 time=8170.024 ms 64 bytes from 139.130.136.129: icmp_seq=10 ttl=255 time=7179.390 ms 64 bytes from 139.130.136.129: icmp_seq=11 ttl=255 time=6213.035 ms 64 bytes from 139.130.136.129: icmp_seq=12 ttl=255 time=5256.255 ms 64 bytes from 139.130.136.129: icmp_seq=13 ttl=255 time=4624.845 ms 64 bytes from 139.130.136.129: icmp_seq=14 ttl=255 time=3940.019 ms 64 bytes from 139.130.136.129: icmp_seq=15 ttl=255 time=2957.453 ms 64 bytes from 139.130.136.129: icmp_seq=16 ttl=255 time=5175.834 ms 64 bytes from 139.130.136.129: icmp_seq=17 ttl=255 time=4197.999 ms 64 bytes from 139.130.136.129: icmp_seq=18 ttl=255 time=3210.130 ms 64 bytes from 139.130.136.129: icmp_seq=19 ttl=255 time=2530.432 ms 64 bytes from 139.130.136.129: icmp_seq=20 ttl=255 time=1558.372 ms 64 bytes from 139.130.136.129: icmp_seq=21 ttl=255 time=559.806 ms 64 bytes from 139.130.136.129: icmp_seq=22 ttl=255 time=149.419 ms
This is backup due to the error correction of the modem: most of these messages came more or less at the same time. Clearly the line is in terrible shape, so I changed back to the spare line again. Then, on Sunday at 11:20 am, I called Telstra's line faults number and, spoke to Sarah Jane. She tested the line, confirmed that it was faulty, and promised to send somebody on Tuesday.
Telstra has a Customer Service Guarantee which requires that all faults be fixed within two working days. This is clearly a line fault which will require building work done. There's no way that Telstra can maintain this guarantee if they don't send anybody out until Tuesday. I asked her to get somebody out tomorrow, but she wasn't able to. Instead I got her to enter a complaint, which she did offline.
In the meantime, on the backup line I discovered:
$ ping 139.130.136.129 PING 139.130.136.129 (139.130.136.129): 56 data bytes 64 bytes from 139.130.136.129: icmp_seq=0 ttl=255 time=5337.033 ms 64 bytes from 139.130.136.129: icmp_seq=1 ttl=255 time=4365.525 ms 64 bytes from 139.130.136.129: icmp_seq=2 ttl=255 time=3389.505 ms
I connected to the fax line. Sarah Jane called back (with the complaint number 1412789) and I reported a fault on the backup line.
While writing up the problem, found the same syndrome on the fax line. Called faults again, at 11:45, and spoke to Tamira, who informed me that I should first check that it's not a fault in my equipment. I suppose they mean well.
Tamira called back and confirmed that there was a fault on the line, and that they would send a linesman out no later than close of business on Tuesday. I complained, saying that they would not be able to maintain their Customer Service Guarantee under those circumstances. She assured me that they would get it fixed by then. I asked he to put in another complaint, referring to my Telstra fault overview page, and expressing my opinion that I do not believe that Telstra has any intention of fulfilling its customer service guarantee. She gave me the complaint number 1412793.
After a while, the connection on all three lines was too bad. The only lines which still worked were the private and business phone numbers, which were both together on a pair gain system (ironically, the one that the Telstra linesman consider the worst for modem connections). I put the phones on them and continued.
In the evening, the pair gain system died:
Jul 13 19:52:13 echunga pppd[1076]: Modem hangup, connected for 362 minutes Jul 13 19:53:24 echunga pppd[1076]: LCP: timeout sending Config-Requests Jul 13 19:55:25 echunga pppd[1076]: Modem hangup, connected for 1 minutes Jul 13 19:56:45 echunga pppd[1076]: Modem hangup, connected for 1 minutes Jul 13 19:59:50 echunga pppd[1076]: Modem hangup, connected for 2 minutes Jul 13 20:00:34 echunga pppd[1076]: Connect script failed Jul 13 20:01:46 echunga pppd[1076]: Connect script failed Jul 13 20:02:59 echunga pppd[1076]: Connect script failed Jul 13 20:04:11 echunga pppd[1076]: Connect script failed Jul 13 20:05:24 echunga pppd[1076]: Connect script failed Jul 13 20:06:36 echunga pppd[1076]: Connect script failed Jul 13 20:07:49 echunga pppd[1076]: Connect script failed Jul 13 20:09:01 echunga pppd[1076]: Connect script failed Jul 13 20:10:14 echunga pppd[1076]: Connect script failed Jul 13 20:11:26 echunga pppd[1076]: Connect script failed Jul 13 20:12:39 echunga pppd[1076]: Connect script failed Jul 13 20:13:51 echunga pppd[1076]: Connect script failed Jul 13 20:15:04 echunga pppd[1076]: Connect script failed Jul 13 20:16:16 echunga pppd[1076]: Connect script failed Jul 13 20:17:29 echunga pppd[1076]: Connect script failed Jul 13 20:18:41 echunga pppd[1076]: Connect script failed
Listening to the line made it clear that it was in a much worse state than the others, so I changed back to the original line:
Jul 13 20:19:41 echunga pppd[1076]: Serial connection established. Jul 13 20:19:46 echunga root: PPP connection established from 139.130.136.138 -> 139.130.136.129 (if ppp0, tty /dev/cuaa1, 115200 bps), params
I'm writing this a few minutes after the connection. It's unlikely that I will have a network connection for much longer.
0:26:29.011778 139.130.136.138.1102 > 211.47.45.22.53: 61761 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:29.561651 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:30.571640 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:31.581424 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:32.057877 192.109.197.81.4232 > 203.248.240.141.53: 35660 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:32.591327 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:33.331617 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.396960 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.439744 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.503209 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.529410 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.621932 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.634618 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.647168 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.660330 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:33.732982 204.156.12.32.22 > 139.130.136.138.2744: . ack 478313657 win 58400 (DF) [tos 0x8] 20:26:33.733229 139.130.136.138.2744 > 204.156.12.32.22: . 10221:11681(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:34.244137 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:34.611064 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:34.642172 204.156.12.32.22 > 139.130.136.138.2744: . ack 1461 win 58400 (DF) [tos 0x8] 20:26:34.642400 139.130.136.138.2744 > 204.156.12.32.22: . 11681:13141(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:35.452396 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:35.620910 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:35.864255 204.156.12.32.22 > 139.130.136.138.2744: . ack 2921 win 58400 (DF) [tos 0x8] 20:26:35.864452 139.130.136.138.2744 > 204.156.12.32.22: . 13141:14601(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:36.182498 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.243545 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.291173 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.302084 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.396901 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.407265 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.418361 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:36.550971 204.156.12.32.22 > 139.130.136.138.2744: . ack 4381 win 58400 (DF) [tos 0x8] 20:26:36.551167 139.130.136.138.2744 > 204.156.12.32.22: . 14601:16061(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:36.630816 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:37.459870 204.156.12.32.22 > 139.130.136.138.2744: . ack 5841 win 58400 (DF) [tos 0x8] 20:26:37.460075 139.130.136.138.2744 > 204.156.12.32.22: . 16061:17521(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:37.640699 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:38.007526 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:38.414294 204.156.12.32.22 > 139.130.136.138.2744: . ack 7301 win 58400 (DF) [tos 0x8] 20:26:38.414510 139.130.136.138.2744 > 204.156.12.32.22: . 17521:18981(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:38.414601 139.130.136.138.2744 > 204.156.12.32.22: . 18981:20441(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:38.650561 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:38.762830 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:38.812638 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:38.831637 192.109.197.80.25 > 211.115.216.222.3945: S 2302443279:2302443279(0) ack 1503021733 win 65535 <mss 1460> (DF) 20:26:38.860803 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:38.913976 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:38.956437 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:39.159838 204.156.12.32.22 > 139.130.136.138.2744: . ack 8761 win 58400 (DF) [tos 0x8] 20:26:39.160089 139.130.136.138.2744 > 204.156.12.32.22: . 20441:21901(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:39.236074 192.109.197.81.1482 > 209.142.3.148.80: . ack 3887566279 win 17520 (DF) 20:26:39.236798 192.109.197.81.1482 > 209.142.3.148.80: . ack 2921 win 16060 (DF) 20:26:39.364200 192.109.197.81.4232 > 203.248.240.31.53: 50444 [1au] AAAA? nis.DACOM.CO.kr. (44) 20:26:39.364364 192.109.197.81.4232 > 203.248.240.31.53: 24684 [1au] A6? nis.DACOM.CO.kr. (44) 20:26:39.364535 192.109.197.81.4232 > 203.248.240.31.53: 8543 [1au] AAAA? ns2.DACOM.CO.kr. (44) 20:26:39.364706 192.109.197.81.4232 > 203.248.240.31.53: 55060 [1au] A6? ns2.DACOM.CO.kr. (44) 20:26:39.364963 192.109.197.81.4232 > 203.255.234.103.53: 44837 [1au] AAAA? ns.kornet.ne.kr. (44) 20:26:39.365219 192.109.197.81.4232 > 203.255.234.103.53: 21704 [1au] A6? ns.kornet.ne.kr. (44) 20:26:39.365515 192.109.197.81.4232 > 203.255.234.103.53: 8032 [1au] A? ns.kisti.re.kr. (43) 20:26:39.365665 192.109.197.81.4232 > 134.75.30.1.53: 26475 [1au] AAAA? ns.kreonet.re.kr. (45) 20:26:39.365828 192.109.197.81.4232 > 134.75.30.1.53: 21717 [1au] A6? ns.kreonet.re.kr. (45) 20:26:39.367006 192.109.197.81.4232 > 203.255.234.103.53: 7105 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:39.660523 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:39.665633 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:39.778084 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:39.822358 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:39.892393 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:39.901144 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:39.938786 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.008093 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.017211 192.109.197.81.1483 > 66.150.15.150.80: . ack 912705258 win 17520 (DF) 20:26:40.019118 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.019285 192.109.197.81.1483 > 66.150.15.150.80: . ack 2921 win 16060 (DF) 20:26:40.078868 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.187223 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.287050 192.109.197.81.4232 > 211.115.194.2.53: 56492 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:40.305514 211.216.50.130.53 > 139.130.136.138.1102: 61761- 0/2/3 (135) (DF) 20:26:40.306250 139.130.136.138.1102 > 211.115.194.2.53: 39109 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:40.307035 204.156.12.32.22 > 139.130.136.138.2744: . ack 10221 win 58400 (DF) [tos 0x8] 20:26:40.307316 139.130.136.138.2744 > 204.156.12.32.22: . 21901:23361(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:40.318647 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.329067 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.663134 134.75.30.1.53 > 139.130.136.138.1102: 61761- 0/13/14 (476) (DF) 20:26:40.670368 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:40.673841 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.728520 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:40.756703 211.47.45.22.53 > 139.130.136.138.1102: 61761- 0/2/1 (103) (DF) 20:26:40.869780 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:41.268718 204.156.12.32.22 > 139.130.136.138.2744: . ack 11681 win 58400 (DF) [tos 0x8] 20:26:41.268944 139.130.136.138.2744 > 204.156.12.32.22: . 23361:24821(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:41.602402 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:41.680259 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:42.009565 204.156.12.32.22 > 139.130.136.138.2744: . ack 13141 win 58400 (DF) [tos 0x8] 20:26:42.009764 139.130.136.138.2744 > 204.156.12.32.22: . 24821:26281(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:42.690101 139.130.136.138 > 139.130.136.129: icmp: echo request 20:26:42.760834 204.156.12.32.22 > 139.130.136.138.2744: . ack 14601 win 58400 (DF) [tos 0x8] 20:26:42.761021 139.130.136.138.2744 > 204.156.12.32.22: . 26281:27741(1460) ack 0 win 58400 (DF) [tos 0x8] 20:26:43.021458 192.109.197.80.49168 > 134.75.30.1.53: 53036 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:43.037296 139.130.136.129 > 139.130.136.138: icmp: echo reply 20:26:43.048020 192.109.197.81.4232 > 164.124.101.31.53: 50444 [1au] AAAA? nis.DACOM.CO.kr. (44) 20:26:43.048188 192.109.197.81.4232 > 134.75.30.1.53: 7105 [1au] PTR? 222.216.115.211.in-addr.arpa. (57) 20:26:43.048374 192.109.197.81.4232 > 134.75.30.1.53: 21717 A6? ns.kreonet.re.kr. (34) 20:26:43.048505 192.109.197.81.4232 > 134.75.30.1.53: 26475 AAAA? ns.kreonet.re.kr. (34) 20:26:43.048662 192.109.197.81.4232 > 134.75.30.1.53: 8032 [1au] A? ns.kisti.re.kr. (43) 20:26:43.048792 192.109.197.81.4232 > 134.75.30.1.53: 21704 [1au] A6? ns.kornet.ne.kr. (44)
20:30: Called Telstra's fault line again to report the two remaining phone numbers. Got a message: "If you hear <funny tone> it means that you have a message waiting from your message bank (Telstra speak for voice mail)". Presumably the line was so bad that the system was confused; I don't have any voice mail on this line.
After about the tenth time, got through and was put on hold. Finally I got on to Kathy, who told me that, due to privacy restrictions, she could not confirm the number I was calling on. I asked to speak to her supervisor, but, as seems to be the case so often, none was available. Based on the information she gave me, I must have been calling on the fax phone number. She went off to test the line, which was barely audible. When she came back, I couldn't understand what she was saying, and I asked her to call me back on the mobile number. When she did, she confirmed the fault (of course) and said that a linesman would appear by close of business on Tuesday. That makes the third complaint I've entered today. I asked her to state in the complaint that I do not believe that Telstra has any intention of maintaining their Customer Service Guarantee, and pointing to these pages. I wonder if she will. The fault report number is S 603 231 555, and the complaint number is 1412822.
Interestingly, the original modem line seems to have recovered a little. Maybe this problem won't be as bad. If this makes it to the net, there's hope yet. Sent off another fax to Alexander Downer. I wonder if they'll get involved any more this time.
I forgot to turn my mobile phone on early this morning. When I did, I had two voice mail messages from Telstra's complaints department, the first for complaint number 1412789 at 8:00 and the second for complaint number 1412793 at 9:56. Neither knew of the other, and both asked me to call back on a 1-800 number, which would cost me money on my mobile phone. Decided not to call back: the reason for the complaint was to ensure that they Customer Service Guarantee. They shouldn't need to talk to me for that.
Drove down the road in the afternoon and discovered some linesmen really working on the lines. Returned home, musing whether this was the result of my complaints or a coincidence, and got the third call from Telstra complaints, this time for complaint 1412822, promising to “investigate”.
I was called out of bed by a linesman called Dave this morning, wanting to check whether there was still noise on the line. There was: nothing seemed to have changed. I told him about the linesmen working on the road, and he said that he had spoken to them, and they were just doing maintenance work, not attending to the fault reports. It seems that the fault is marginal enough that they didn't coalesce the reports into a larger activity. Dave had only come to look at the third fault report, for the last two numbers.
Pretty soon, the two numbers Dave was looking at were disconnected, and they stayed that way all day. In the afternoon he came back and told me that he had been working all day with the linesmen who had already been there, and they had located a cable fault and were in the process of connecting a slave cable.
At about 18:30 I got a phone call from somebody trying to reach a different phone number, one unrelated to my own number. She managed it three times and confirmed that the number was also in the same cable, so it looked like a mistake in splicing the slave cable. Down to the trench to find another linesman, Roger, and told him what was going on. He promised to call me back when the lines were OK, but when he did call back, round 20:00, it was to say that they weren't able to complete it that evening, and that they'd contact me tomorrow when they had fixed things.
At 11:20, got a call from Kay at Alexander Downer's office. It seems that we have her to thank for the fact that people worked on the line fault all day yesterday. She was also complaining about the fact that Telstra never called her back to tell her what was going on.
At midday, I got a call from Angela from Telstra's complaints department. Unfortunately the phone connection was so bad that we were disconnected twice, after which she didn't bother to try calling again.
Still no calls from the complaints people. My suspicion that they had decided that the issue had closed itself was confirmed when, at 5 pm, I got a call from a Telstra complaints person, whom I could barely understand because of a badly adjusted headset. I told her how to fix the problem (“How do you know how I have my headset?”), but she barely moved it, and remained very difficult to understand. As it became clear that she didn't understand the issues, I asked for her name. Sam Stewart (female), with whom I already had an impossible time in March: then she had tried to explain how they were going to compensate me without even knowing how many phone lines we had.
This time she didn't know about the complaints I had put in (she had responded apparently to the complaint from Alexander Downer's office), so I gave them to her, after which she said she had known about them all the time. I asked her why I hadn't been compensated for the last outage, but she didn't know that and said she would get somebody to send me a letter explaining why. That would certainly be a novelty: I had the impression that Telstra doesn't put anything in writing. She also promised to escalate the issue and to find out why the complaints had been closed before they were addressed. I'll be interested to see if anything comes of it.
In the afternoon, got a call from Jo Holland (female), a SENIOR Customer Relations Manager from Telstra, to whom Sam Stewart (also female) had escalated her own inability to communicate. It had apparently taken ten days for her to do so. Jo placed great emphasis on the title SENIOR, but did nothing to justify it. She confirmed at great length, for example, that they had closed two of my complaints without even informing me because they were duplicates. I asked her if she thought it was good customer relationships to close things without informing the customer. She went back into a repetition of her long-winded description of how they were duplicates, and wouldn't be stopped. After four iterations, I finally got her attention long enough to ask her to escalate the issue further. She said there was no further escalation path (the same thing that Sam Stewart said a few months ago), and suggested I take it to the Telecommunications Industry Ombudsman, which sounds like a damn good idea. At least that way they will have to justify themselves in writing.a
| Greg's home page | Greg's diary | Greg's photos | Copyright |