When something goes wrong with a connected device, the fault could sit anywhere along a chain that runs from the device firmware, through the modem, and into the operator’s core network. Without packet-level visibility, no one can prove which side the issue is on — so no one takes ownership, and the customer carries the cost.
That’s the blame game, and it’s really two problems wearing one root cause: nobody can see the evidence, and every route to it runs through someone else’s support queue. Together they make up one of the nine reasons IoT fleets switch connectivity providers.
Here’s how the ping-pong works, why providers don’t show you the logs, and what breaks the loop.
How does the blame game play out?
This is a single, repeated issue: when something goes wrong with a connected device, no one takes ownership — and when fleet managers try to dig deeper and assign ownership, there’s no evidence to settle it, because there’s rarely any packet-level visibility.
Fleet managers describe spending weeks swapping out hardware, rewriting firmware, and replacing devices across entire fleets, only to discover that the root cause was a network-level configuration that could have been fixed in minutes. A wrong MTU setting; a TCP handshake quirk; a modem caching a bad network after a rejection. These are small, fixable things, but pinpointing them requires visibility most providers simply won’t share.
So the ping-pong starts. When devices misbehave, the connectivity provider blames the hardware, the hardware vendor blames the firmware, and the customer is left in the middle with no way to prove either side wrong. Several prospects know exactly what would resolve the question — a packet capture, a signaling log, a network-side trace — but since they can’t get at that data themselves, they have to request it from the provider, sometimes after days waiting on support tickets. Meanwhile SLAs slip, customers complain, and the engineering team burns time on a problem that was never theirs to solve.
“Devices get stuck on a single network and the modem never recovers; our current vendor just points at us. We need a provider who can show signaling logs and PCAPs so we can isolate device vs network.”
The cost of troubleshooting blind
While the blame gets passed around, the meter keeps running. Fleet managers describe long outages, devices on the bench for weeks, and engineering time wasted trying to troubleshoot through a chain of support tickets while the time-to-fix drags on. And because the connectivity is still billed throughout, they end up paying for problems they can’t solve.
One executive told us the pain got bad enough that they took on the enormous task of physically changing the SIMs across their devices — just to earn the chance at network visibility.
“We were blind to what was happening on the network; the MNO just gives a log dump after multiple escalations, which kills time. We lose customers while waiting for carrier responses. In the end, we had to physically swap SIMs because the operator wouldn’t provide the diagnostics we needed; field fixes cost us thousands.”
Why won’t providers just show you the logs?
The root cause splits into routes depending on the provider — but every route ends in the same place: gatekept or escalated access.
Providers that own and operate their core network do have access to signaling logs. They just choose not to make them directly accessible, especially without the gatekeeping of a support department in between.
MNOs are a second case. If the device sits on the MNO’s own network, the MNO can pull the signaling logs and give the customer what they need. But if the device is roaming on a partner network, the MNO has no direct access to that partner’s core — so the MNO has to request the logs, escalating the very ticket the customer is waiting on, and stretching the downtime further.
And then there are providers that don’t own a core network at all but rent access to someone else’s. They inherit the same opacity: the diagnostic data lives on infrastructure they don’t control, so the customer’s request becomes their request to a third party, with every delay that implies.
What breaks the loop: packet captures and signaling logs
Without visibility, the device and network teams each point at the other, neither can prove its claim, and the customer carries the cost. Packet captures and signaling logs are what break that loop — and their absence is exactly what turns a simple configuration fix into weeks of unnecessary troubleshooting.
That’s why fleet managers who’ve been through it know what they need: network logs, and providers with packet capture, packet-level visibility, and troubleshooting tools. Above all, they look for direct access to the network, to network events, and to signaling logs — so they can debug and troubleshoot independently and cut the time to fix. For the device-side half of that debugging, see our IoT device troubleshooting guide.
How Onomondo ends the ping-pong
Onomondo owns and operates its own core network — which means the diagnostic data isn’t on someone else’s infrastructure, and it isn’t behind a support queue. It’s exposed to you directly, self-service, in Onomondo’s Traffic Monitor: SIM usage, SMS, network logs, signaling logs, and a real-time traffic monitor where you can download traffic as a PCAP.
That changes what a bad day looks like. Instead of opening a ticket and waiting to be told it’s your firmware, you pull the packet capture, look at the signaling, and isolate device vs network yourself — in minutes, with evidence. No escalation, no ping-pong, no paying for downtime nobody can diagnose.
And if what the logs reveal is a device trapped on a weak network, that’s a related but different problem — see the hidden cost of network steering.
Frequently asked questions
How do you tell if an IoT problem is the device or the network?
With packet-level evidence: a packet capture, a signaling log, or a network-side trace will quickly show which side the issue is on. Without that visibility, the fault could sit anywhere along the chain from firmware through the modem into the core network — which is why the blame game exists.
Can you get a packet capture from an IoT SIM?
Only if your provider exposes it. Most won’t share packet-level data, or only release it through support tickets and escalations. Onomondo’s Traffic Monitor lets you watch traffic in real time and download it as a PCAP, self-service.
What are signaling logs?
The record of the network-level exchange between a device and the network — the evidence that settles whether a connection problem is the device, the modem, or the network. Most providers keep them out of customers’ reach, either by policy or because the data lives on a core network they don’t control.
Why does IoT troubleshooting take weeks?
Because without direct access to logs, every question routes through support tickets and escalations — sometimes across multiple companies. Fleet managers describe weeks spent swapping hardware and rewriting firmware for problems that turned out to be network-level configurations fixable in minutes.
