Documentation

Connection Problems

Use this page when OsprioView cannot see the hardware you expect, shows a device as unavailable, or loses a live session unexpectedly.

This guide is written so you can work through the common failure paths without source-code access or direct technical support.

Troubleshooting order ​

The fastest way to debug OsprioView connection issues is to work from the outside in:

  1. confirm the runtime and permission model
  2. confirm the operating system can actually see the USB device
  3. confirm Linux USB permissions if applicable
  4. confirm the device is visible in the correct workspace
  5. confirm the device is available and not leased elsewhere
  6. confirm the device is running the right app role
  7. use diagnostics before retrying repeatedly

Step 1: Confirm how you are running OsprioView ​

Hardware access depends on the runtime:

  • browser build: uses WebUSB and requires a supported browser plus browser authorization
  • desktop build: uses native USB access through the installed app runtime

If you are in the browser build, use a Chromium-based browser such as Chrome or Edge. Safari and Firefox do not provide the WebUSB support OsprioView depends on.

If you are in the desktop build, browser pairing is not required, but Linux USB permissions still matter.

Step 2: Confirm the operating system sees the device ​

Before debugging OsprioView itself, verify the device is visible to the OS.

On Linux, run:

lsusb | grep 1209:

Expected Osprio USB IDs currently include:

  • 1209:f70e for monitor-mode hardware
  • 1209:f70f for monitor-mode Osprio Pro hardware
  • 1209:f70d for emulator-mode hardware

If none of these appear:

  • reconnect the cable
  • try a different USB port
  • avoid passive hubs while debugging
  • confirm the device is powered and fully booted
  • confirm the cable supports data, not only charging

If the device appears in lsusb but not in OsprioView, continue with the permission and workspace checks below.

Step 3: Linux udev setup ​

On Linux, non-root USB access requires a udev rule. This applies to both the browser build and the desktop build.

Create the rules file:

sudo tee /etc/udev/rules.d/99-osprio-view.rules >/dev/null <<'RULES_EOF'
SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="f70e", MODE="0666", TAG+="uaccess"
SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="f70f", MODE="0666", TAG+="uaccess"
SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="f70d", MODE="0666", TAG+="uaccess"
RULES_EOF

Then reload the rules:

sudo udevadm control --reload-rules
sudo udevadm trigger

After reloading, unplug and reconnect the device.

What these rules cover ​

  • 1209:f70e: Osprio monitor-mode device
  • 1209:f70f: Osprio Pro monitor-mode device
  • 1209:f70d: Osprio emulator-mode device

If you only add monitor-mode rules, emulator-mode hardware can still fail to appear or fail to open correctly.

How to verify the rules were applied ​

After reconnecting the device, rerun:

lsusb | grep 1209:

Then retry OsprioView.

If the device is still visible to the OS but unusable in the app, rebooting the machine once after adding fresh rules is a reasonable next step.

Step 4: Browser pairing and authorization ​

This step applies only to the browser build.

If the OS sees the device but OsprioView still shows an empty device list:

  1. open the target workspace
  2. click PAIR NEW
  3. select the device in the browser chooser
  4. click Rescan
  5. try Connect again

If the browser chooser never appears or the device is not offered there:

  • confirm you are using Chrome or Edge
  • confirm the device was replugged after udev changes on Linux
  • disconnect other software that may already have claimed the device

If the device was previously paired but no longer opens cleanly, remove the browser USB permission for that device and pair it again.

Step 5: Confirm the correct workspace ​

OsprioView filters devices by workspace intent:

  • Capture only shows devices ready for monitoring work; reviewing a saved .ovb capture needs no live device
  • Emulator only shows devices ready for emulation work
  • App Switcher is used when the device must change role before another workspace can use it

A device appearing in one workspace but not another is not automatically a discovery bug. It may simply be in the wrong role for the selected workflow.

Step 6: Check availability and session ownership ​

A visible device can still be unavailable.

Common reasons include:

  • another tab already owns the device lease
  • the workspace is still connecting or probing the device
  • a firmware or app-switch operation is in progress
  • the device is visible but not ready for the requested capability

If OsprioView shows In Use, release or close the other session first. Device ownership is exclusive across tabs.

If you are not sure which tab holds the device:

  • look for another open Capture, Emulator, or App Switcher tab
  • stop any active capture or emulation session
  • close stale tabs that may still own the device
  • rescan from the workspace you actually want to use

Step 7: Check app-role and firmware state ​

This is especially important on Osprio Mini.

If the device is connected but the workspace still cannot use it, confirm the hardware is running the correct app:

  • monitor app for Capture
  • emulator app for Emulator

If the role is wrong, use App Switcher Workspace instead of repeatedly rescanning.

Firmware operations ​

If a firmware or app-switch operation appears stuck:

  1. keep the device connected until the operation finishes or fails clearly
  2. reconnect the device
  3. rescan from the target workspace
  4. retry only after the device has settled into a known state

Do not treat an in-progress firmware transition as a normal connection failure.

Step 8: Recover from disconnects and orphaned sessions ​

If a device disconnects during capture or emulation, OsprioView does not necessarily throw the session away.

Instead, the tab can stay open in an orphaned or read-only state so you keep:

  • collected packet history
  • current selection and filters
  • visible runtime context and logs

The expected recovery path is:

  1. reconnect the hardware
  2. rescan or reconnect from the workspace
  3. start a new live session if needed

Do not assume the old device lease resumes automatically.

Step 9: Use diagnostics before filing an issue ​

The diagnostics drawer is the shared troubleshooting surface for the whole shell.

Use it to:

  • inspect runtime and device-operation logs
  • enable debug logging for a more verbose trace
  • copy logs together with environment details
  • capture evidence before reproducing the issue again

Quick decision guide ​

Use this short version when you need the fastest next step.

Device does not show in lsusb​

The problem is outside OsprioView.

Check cable, port, power, hub, and whether the device has finished booting.

Device shows in lsusb but not in browser pairing ​

The usual causes are:

  • unsupported browser
  • missing or stale Linux udev rules
  • another process already using the device

Device shows in OsprioView but is unavailable ​

The usual causes are:

  • another tab owns it
  • the wrong workspace is open
  • the wrong app role is running on the device
  • a firmware or app-switch operation is still active

Device worked before but stopped after switching modes ​

The device likely changed app role or re-enumerated on USB.

Unplug and reconnect it, then rescan in the intended workspace.

Reporting a useful issue ​

When reporting a problem, collect evidence in this order:

  1. reproduce the issue once
  2. open diagnostics
  3. click Copy
  4. paste the copied output into the report
  5. include your OS and whether you are using browser or desktop mode
  6. include the output of lsusb | grep 1209: if you are on Linux
  7. attach a .ovb file or emulator profile JSON if it helps explain the failure

That gives enough context to distinguish OS-level USB failures, permission problems, session-lock issues, archive problems, and workspace-specific behavior.