18 meters of air, ~12 meters of glass, ~36 meters of going through glass instead of air, and a lot of meters for going through faster glass rather than slower glass when connection is tightened (and don't think of the signal bouncing at an angle and arriving slower, that's not how fibre optics works). If they have a long glass cable, you can be certain that delay has to be actually measured because speed is temperature dependent.
And in terms of the actual change in how far the light travels - quite possibly 0 meters.
The point of the conversion from nanoseconds to meters is to have some sort of intuitive reference just how much behind the signal must get via lousy connection.
It's a recipe for intuitive confusion. We know there is a hardware fault of some kind due to connection difficulties. We don't know the precise nature of the error introduced by the connection problem. There is more than one way a messed up connection could result in an electronic device giving input too slowly, few due to introducing more actual distance traveled and many giving absurd distance reading in the km for reasons entirely unrelated to the speed of light.
If you absolutely must use a distance metric to measure a fault with time reporting then I recommend adopting the unit "nano lightseconds".
And I outlined those other ways - involving the packet loss and re-sending of old data.
The intuition here is hundred percent correct in ruling out any simple mechanistic explanations such as the gap introducing extra distance, the light bouncing off at angle, et cetera. Look what we achieved by converting to meters. We narrowed down the problem to connection protocol. Something has to be re-sending old packets, to introduce that kind of delay. Or, if they send pulses on every tick, which is probably not what they are doing - they must be counting pulses w...
A mundane cause for a surprising result. Consider this unconfirmed for now, however unsurprising it sounds.
Source: Science/AAAS