In NBN troubleshooting, we all love a clean win. You find the fault, you fix the copper, the HLOG graph flattens out, and the client rides off into the sunset with zero packet loss.

But sometimes, FTTN isn't that simple. Sometimes, what looks like one fault is actually a dual fault.

This case study from a commercial retail shop in Halls Head, WA, is a perfect example of fixing the physical layer only to uncover a deeper network impairment—and the reality of fighting NBN’s automated ticketing system when it insists the line is "fine."

Figure 1 - The classic NBN Catch-22. The line is flagged as UNSTABLE, but the system says it is "performing within specification" and advises against logging a fault ticket because the raw speed is fast enough.

The Initial Presentation

The client was experiencing constant packet loss. Their ISP confirmed an impairment, but NBN’s automated system flagged the service as "performing within specification" because the raw download speed was fast enough.

To make matters more frustrating, while many other shop centres in the Halls Head area have been upgraded to FTTB (Fibre to the Building), this specific centre is stuck on FTTN (Fibre to the Node).

Because this is a busy retail store, we could not take them offline during trade hours to run a pre-test. We had to rely on the ISP's initial AVC test results (which showed an active 8-metre bridge tap at the 775m mark and 3% packet loss) and get straight to work.

Figure 2 - The ISP's initial test confirmed an active 8-metre bridge tap at the 775m mark.

Fault #1: The Bridge Tap & Internal Wiring

Upon arrival, we inspected the internal cabling. To ensure a clean connection from the NBN network to the customer's equipment, we replaced the wall socket and re-terminated the jumpering in the shop's IDF (located approx. 3m away).

Figure 3 - The original jumpering in the shop's IDF part way through remediation.

Figure 4 - Cleaned up connections in the IDF ensuring a solid physical layer to the wall socket.

We then had the ISP verbally confirm the bridge tap was physically removed from the external network. We hooked up our tester to get a post-fix baseline. No before results to minimise shop downtime (sorry!)

Figure 5 -The tester gives a "Pass" because it synced perfectly on a VDSL2-17a profile at 30/11 Mbps with a solid 22.60 dB Downstream SNR. On the surface, it looked fixed.

Figure 6- The Hlog graph shows a smooth downward curve. The "notches" and impedance mismatches typical of a bridge tap are gone, visually proving the physical fix.(If you want a deep dive into how to read these graphs, check out our previous case study on how we diagnosed a split pair at Eaton Fair.)

Figure 7 -The Estimated Wire Length (EWL) dropped from the ISP's initial 775m down to 687m, proving the 8m tap is gone. Sync loss is 0, and CRC/HEC/SES errors are perfectly clean.

Despite the physical line now being solid, the client was still dropping packets.

Fault #2: The Remaining Impairment (The Dual Fault)

Verbal confirmation from the ISP came through: they were still seeing packet loss!

When we looked at the deep line stats from our test, the physical copper looked healthy on the surface, but the higher frequencies told a different story.

Figure 8 - Look at the high-frequency bands. The signal-to-noise ratio drops off a cliff because the line is drowning in noise at the higher frequencies.

Looking back at Figure 7 (DSL Statistics), the smoking gun was the performance counters:

• FEC Errors: 27,455 local Forward Error Correction errors. The modem was constantly fighting noise.

• G.INP RTX_UC: The line had over 2.1 million uncorrectable retransmissions.

For the techs playing along at home: If your modem is showing massive RTX_UC numbers but zero CRC errors, it means the retransmission buffer is getting slammed by bursts of noise. The line is technically syncing, but data packets are being corrupted before they can be corrected.

The Diagnosis: Why is it still failing?

The remaining fault is external. This shop is on FTTN, meaning it relies on 687 metres of ageing copper running out to the street. We measured the distance from the shop to the MDF at 120 metres and confirmed that end is all good. Most shopping centres have FTTB (Fibre To The Building) which we find is far more reliable.

NBN's automated system sees the sync speed and says, "Looks good to me!" (See Figure 2). But the physical layer is bleeding noise.

The Bigger Issue: Why NBN Needs to Stop Auto-Rejecting Bridge Tap Faults

While this case study involves a commercial retail shop on FTTN, we see this exact same scenario play out constantly in residential homes, especially in areas awaiting fibre upgrades.

Too often, we are called out to a residential property because the internet is dropping out. The customer has been told by their ISP that NBN has rejected the fault ticket because an automated test detected a bridge tap on the line. NBN essentially points the finger at the customer's internal wiring and closes the ticket. This is rare nowadays with the free Fibre Optic upgrade available across Perth. Check your address at www.nbnco.com.au.

So, we go out, remove the bridge tap, or test the line coming directly into the house. What do we find? The line is barely working. The bridge tap might have been present, but the actual root cause of the dropouts is a failing NBN copper line or severe external crosstalk.

This Halls Head case study is the perfect example of why NBN’s automated rejection policy is broken.

A bridge tap is an easy scapegoat for an automated algorithm to find. But as we proved here, a bridge tap does not exclude the presence of a simultaneous external network impairment.

When NBN detects a bridge tap, it shouldn't automatically reject the fault ticket and blame the customer. It should be treated as a prompt for further investigation. By auto-rejecting these tickets, NBN is forcing customers to pay for private techs to fix their internal wiring, only to leave them with a line that still drops packets because the NBN copper is failing.