How I Troubleshot ADB Wireless Pairing on Linux: Protocol Faults, Network Isolation, and scrcpy

If you've ever tried pairing your Android device wirelessly with ADB on Linux and encountered this frustrating error:

error: protocol fault (couldn't read status message): Success

You're not alone.

I encountered this while setting up my React Native development environment. What initially looked like an ADB problem eventually led me to investigate my local network configuration.

Here's what I tried, what I discovered, and the workaround I used.

The Setup

I was building a React Native application and wanted to test it on a physical Android device without constantly connecting a USB cable.

Android 11 introduced native Wireless Debugging, which allows developers to pair devices using a pairing code.

The process should be straightforward:

Enable Wireless Debugging.
Get the IP address and pairing port.
Run adb pair.
Enter the pairing code.

Simple enough, right?

Unfortunately, it wasn't.

Attempt 1: Pairing with ADB

I opened Wireless Debugging on my Android device and ran:

adb pair 192.168.0.174:40793

After entering the pairing code, I received:

error: protocol fault (couldn't read status message): Success

The confusing part was the word Success at the end.

I expected a more descriptive error explaining what had gone wrong.

Things I tried

Before investigating further, I tried several basic troubleshooting steps:

adb kill-server adb start-server

I also tried:

Running ADB with sudo.
Generating a fresh pairing code.
Pairing another Android device.
Checking my Linux firewall.

My firewall was inactive, and the problem persisted across two different phones.

That made me suspect something common to both attempts: my development machine, ADB installation, or network.

Investigating the Network

I decided to test whether my laptop could actually communicate with my phone.

I ran:

ping 192.168.0.174

The result was:

PING 192.168.0.174 (192.168.0.174) 56(84) bytes of data. From 192.168.0.180 icmp_seq=1 Destination Host Unreachable From 192.168.0.180 icmp_seq=2 Destination Host Unreachable

This was an important clue.

Both devices were connected to the same Wi-Fi network, but my laptop couldn't reach the phone.

At this point, I shifted my investigation from ADB itself to network connectivity.

Understanding AP Isolation

One possible explanation was AP Isolation, also known as Client Isolation.

AP Isolation is a router security feature that prevents wireless clients connected to the same access point from communicating directly with each other.

For example:

Your laptop connects to the router.
Your Android phone connects to the same router.
Both devices can access the internet.
However, the router prevents them from communicating with each other.

This can interfere with development workflows that depend on local network communication, including ADB Wireless Debugging.

My MTN mobile router became a major suspect.

How to investigate this:

Start by checking whether both devices:

Are connected to the same Wi-Fi network.
Have compatible IP addresses and subnet configurations.
Can communicate with each other over the local network.

If they cannot, investigate client isolation, guest-network restrictions, VLANs, and router firewall settings.

A failed ping alone doesn't prove AP Isolation, but it is a useful starting point.

The USB-Assisted TCP/IP Workaround

Since I couldn't immediately resolve the network problem, I explored another way to use ADB.

Instead of pairing wirelessly, I connected my Android device through USB and enabled ADB's TCP/IP mode.

Step 1: Enable USB Debugging

On your Android device:

Settings → Developer Options → USB Debugging → ON.

Step 2: Connect your phone

Connect your phone to your Linux machine and run:

adb devices

Your device should appear in the list.

If it shows unauthorized, check your phone for the USB debugging authorization prompt.

Step 3: Get your phone's Wi-Fi IP address

Run:

adb shell ip addr show wlan0

Look for the inet entry.

For example:

inet 192.168.0.174/24

Step 4: Enable TCP/IP debugging

Run:

adb tcpip 5555

Expected output:

restarting in TCP mode port: 5555

Step 5: Connect using the network

Disconnect the USB cable and run:

adb connect 192.168.0.174:5555

If successful, ADB should report that it connected to the device.

Important: This method still depends on local network communication. If your router blocks communication between wireless clients, adb connect may fail too.

The USB connection itself remains available as a reliable development option.

Also, TCP/IP debugging on port 5555 is different from Android 11's native Wireless Debugging pairing mechanism. Use it only on a trusted network and disable it when you no longer need it.

Why the ADB Protocol Fault Can Be Misleading

Android's native wireless debugging uses a pairing protocol involving TLS and SPAKE2-based authentication.

The error:

error: protocol fault (couldn't read status message): Success

doesn't tell you exactly which part of the process failed.

Possible causes include:

Network connectivity problems.
A connection being dropped during pairing.
Incorrect or expired pairing details.
ADB client implementation issues.
Problems with the pairing endpoint.

The important lesson is not to assume every ADB protocol fault is an ADB installation problem.

Check the underlying network connection before spending too much time reinstalling tools.

Also verify your installed ADB version:

which adb adb version

If you have Android Studio installed, make sure you're using the intended Android SDK Platform Tools installation and consider updating it.

Bonus: Mirroring Android with scrcpy

While working on this setup, I also explored scrcpy.

Scrcpy is an excellent tool for Android developers because it allows you to mirror and control an Android device directly from your computer.

It supports:

Screen mirroring.
Keyboard and mouse control.
Audio forwarding on supported Android versions.
Screen recording.
Wireless connections.

Official project: https://github.com/Genymobile/scrcpy

For Linux, follow the official installation instructions rather than relying on an outdated Snap package.

Once installed, run:

scrcpy

Some useful commands:

# Turn off the device screen while mirroring scrcpy -S # Limit frame rate scrcpy --max-fps 60 # Set video bitrate scrcpy -b 8M # Record your session scrcpy --record=demo.mp4 # Disable audio forwarding scrcpy --no-audio

This makes testing, debugging, and demonstrating React Native applications much more convenient.

Lessons from This Debugging Session

A few things stood out to me:

Don't immediately blame the tool. An error from ADB doesn't necessarily mean ADB itself is broken.
Test network connectivity first. When working with wireless debugging, the network is part of your development environment.
Understand your router. Features such as AP Isolation can interfere with local development.
Keep USB debugging as a fallback. Wireless development is convenient, but having a reliable alternative matters.
Use the right debugging tools. Tools like scrcpy can make physical-device testing significantly easier.