How to Sync a Device pcap File with Network-Side Data (And Why It’s Harder Than It Looks)

A scan gun drops its session in the middle of a pick. Someone pulls a device pcap file off the unit with RxLogger, opens it in Wireshark, and expects the answer to be sitting there.

It isn’t. Not because the capture is bad, but because it is one side of a two-sided conversation.

The short answer: you cannot fully diagnose an RF or scan gun issue from a device-side capture alone. It only records what the device experienced. To reach a root cause, you have to correlate that capture against network-side data from the access point or switch, correct for clock drift between the two, confirm you are looking at the right device on the right AP, and tie the result back to the specific user complaint and timestamp. Four steps, all manual, all done under ticket pressure.

This piece is a hands-on walkthrough of that process. For the bigger-picture case on why RxLogger alone leaves gaps, see Understanding the Limitations of Standalone RxLogger Analysis. For background on where slowness and drops actually originate, see The Origins of Mobile Connectivity Issues.

What is a pcap file, and what does RxLogger capture?

A pcap file, short for packet capture, is a record of network traffic collected at one specific point. In this case, that point is the mobile device’s radio interface.

RxLogger is Zebra’s built-in diagnostic utility. It runs on the device and collects several log types at once: logcat, syslogs, tombstones, snapshots, and a tcpdump module that produces the packet capture itself. That tcpdump output is the capture in question.

What it shows is exact and useful. What the device sent. What it received. When each frame arrived. Retries, timeouts, resets.

What it does not show is anything that happened anywhere else at the same moment. Not the access point. Not the switch port. Not the host application. Not the roam decision the controller made two seconds before the session dropped.

Why isn’t a device-side capture enough on its own?

Because the device only knows its own experience.

When a picker says the gun froze, there are three general places that freeze could have originated: the device, the wireless infrastructure, or the host application and network path behind it. A device-side capture gives you a clear view of one of those three, and inference about the other two.

Inference is where troubleshooting goes wrong. A gap in the capture might mean the device stopped transmitting, or it might mean the AP stopped hearing it. Those are different problems with different fixes and different owners. The packet capture alone cannot tell you which one happened, and neither can the person reading it, no matter how good they are.

That ambiguity is what turns a two-hour ticket into a three-week investigation with four vendors on the call. Each vendor reads the same capture, finds nothing that implicates their own layer, and passes it along. Nobody is lying. Everyone is working from partial evidence, and partial evidence is remarkably good at exonerating whoever holds it.

The device vendor sees clean radio behavior. The network team sees healthy AP statistics. The application team sees no server-side errors. All three are correct about their own layer, and the picker is still standing there waiting for a screen to refresh.

How do you pull a pcap file from RxLogger?

Getting the capture off the device is the easy part. Five steps:

• Start logging. Open RxLogger on the device and begin a session with the tcpdump module enabled.
• Reproduce the issue. Either trigger it deliberately or wait for it to occur naturally, and write down the exact time it happened. Not “around 2pm.” The actual minute.
• Stop logging. End the session once the event is captured.
• Run BackupNow. From the RxLogger menu, compress the session into a single zip file.
• Pull the zip. Retrieve it from the device’s RxLogger folder over USB or ADB.

You now have the device’s half of the story. The harder half comes next.

How do you sync a device pcap file with network-side data?

Four steps, in order. Each one is individually straightforward. Together, under time pressure, they are why this work takes days.

1. Capture the network side at the same moment

Identify which access point or switch port the device was associated with during the failure window, then get a matching capture from that infrastructure. On most controllers this means running a wireless sniffer trace on the correct channel, which Cisco documents in detail in its guide to 802.11 wireless sniffing.

The catch is timing. Intermittent issues do not schedule themselves. If you were not already capturing on the network side when the problem occurred, you are waiting for it to happen again.

2. Correct for timestamp drift

Device clocks and network infrastructure clocks run independently. Unless something is actively keeping them in step, they drift, and you have no way to know by how much until you check.

Align them manually before you compare anything. This step gets skipped more than any other, and skipping it is how teams “find” a correlation that is pure coincidence. Two events that look simultaneous in unaligned captures may be four seconds apart in reality, which changes the causal story entirely.

3. Match MAC address to IP address to access point

Confirm you are looking at the right device, on the right AP, during the right window. In a facility with hundreds of devices roaming across dozens of access points, this is not a formality. Devices roam mid-session. The AP the device started on is frequently not the AP it was on when the session dropped.

4. Tie the packet data back to the user complaint

Neither capture contains the sentence “the operator said the gun froze at 2:14pm.” That link exists only in the ticket, or in someone’s memory, or in nothing at all.

This is the step with no technical shortcut. Someone has to sit down with the original complaint and manually connect a human report to a packet-level event. If the complaint was vague, and most are, the connection is a guess wearing a lab coat.

Why does this take days in practice?

Because each step depends on the one before it, and any error propagates.

Drift correction depends on having both captures. MAC-to-AP matching depends on correct timestamps. The complaint correlation depends on all three. Get step two wrong and steps three and four produce a confident, wrong answer.

Then add the conditions this work actually happens under. The issue is intermittent. The operator has moved on. Production is running. Three vendors are on a call asking for an update. And the reason a device pcap file was pulled in the first place is that someone escalated hard enough to force an investigation.

That last point matters more than it looks. Fewer than 10% of frontline issues ever reach a trouble ticket. The captures you are analyzing represent the small fraction of problems that got loud enough to be noticed, not the steady background of degradation that never gets reported at all.

The cost adds up in ways that show up on a budget line. A single vendor investigation runs $7,000 to $25,000. A wireless survey runs $5,000 to $10,000 and still measures coverage rather than user experience, which is why wireless surveys so often fail to fix warehouse mobile device problems. Meanwhile the manual correlation work above consumes roughly 2.4 hours of skilled IT time per diagnostic, every time.

Put plainly: the four-step process is engineers rebuilding, by hand, a data layer that does not exist yet.

What should you do before the next incident?

A short checklist that saves hours later:

• Decide now which APs you would capture from. Map your high-traffic zones to specific access points before an incident, not during one.
• Sync your clocks. NTP on the infrastructure and the devices removes the single most error-prone step in the whole process.
• Capture the complaint properly. Train supervisors to log the device ID, the exact time, and what the operator was doing. Workers perceive delays as small as 600ms, so “it was slow” is real data poorly recorded.
• Preserve the whole RxLogger session, not just the pcap. The syslogs and logcat often explain what the packets only imply.

How does MSI close the gap?

Mobile Systems Intelligence from Connect Inc. captures end-to-end transaction data continuously across the device, RF, and application layers, rather than as a one-time investigation after someone escalates.

When the Connect Virtual Appliance detects an issue or one is reported via MSI’s user reporting tools, it triggers RxLogger capture on the device automatically, retrieves it, and synchronizes it against data it already holds: which access point, at what time, what the user was doing, and what the network side was doing at that same moment.

The four manual steps above are already complete before a ticket is opened. The question shifts from “can we reconstruct what happened” to “here is what happened, and here is who owns the fix.”

FAQ

Can I diagnose an RF issue with only a device pcap file? Rarely. You can often narrow the possibilities and rule things out, but confirming root cause requires network-side data captured at the same moment and aligned to the same clock.

How far off can device and infrastructure clocks be? Enough to matter, and unpredictably so. Without NTP running on both sides there is no guarantee the two clocks agree at all, and even a small gap is enough to invert the apparent order of two related events. Assume they are out of sync until you have confirmed otherwise.

What if I did not capture the network side when the issue happened? Then you wait for a recurrence, or you accept an inconclusive result. This is the core limitation of investigation-triggered capture, and the reason continuous monitoring exists.

Does RxLogger do any of this correlation automatically? No. RxLogger is a collection tool. It gathers device-side logs thoroughly and leaves correlation, alignment, and interpretation to whoever opens the zip file.

Next in this series: Three Ways to Use tcpdump from RxLogger to Solve RF, Scan Gun, and Mobile Device Issues.

Sources

• Zebra Technologies, “Collecting Debug Logs Using RxLogger Utility,” Zebra Knowledge Center, 2024. https://support.zebra.com/article/000026240
• Zebra Technologies, “RxLogger Modules,” Zebra TechDocs. https://techdocs.zebra.com/rxlogger/
• Cisco, “Fundamentals of 802.11 Wireless Sniffing,” Cisco Support Documentation. https://www.cisco.com/c/en/us/support/docs/wireless-mobility/80211/200527-Fundamentals-of-802-11-Wireless-Sniffing.html
• Connect Inc. first-party data from more than 50,000 captured and resolved warehouse mobility issues.