IssueTracker

I'm pretty far from being a C++ expert, but I think this may be due to holding a reference to the Config beyond it's lifetime?

See StartDiscovery(): https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/adb/client/transport_mdns.cpp;drc=2c73f5abdf31943e12c68e75f8148c10d2abbf6a;l=154?q=transport_mdns.cpp&ss=android

void StartDiscovery() {
    ...

    g_state->task_runner->PostTask([]() {
        //  optional<Config> created here
        auto config = GetConfigForAllInterfaces();
        if (!config) {
            return;
        }

        // long-lived reference of config given to OpenScreen
        g_state->service = discovery::CreateDnsSdService(g_state->task_runner.get(),
                                                         g_state->reporting_client.get(), *config);

        for (int i = 0; i < kNumADBDNSServices; ++i) {
            auto receiver = std::make_unique<ServiceReceiver>(
                    g_state->service.get(), kADBDNSServices[i], OnServiceReceiverResult);
            receiver->StartDiscovery();
            
            ...
        }

       ...

       // config destructed here
    });
}

A word on impact:

• We rely on WiFi debugging because we use the USB port for additional devices.
• This has made WiFi based debugging unreliable and painful to use because when ADB crashes the connection is lost and is not automatically re-created. Often it can required manually toggling WiFi debugging on the tablet.

I've left Wireshark running over the weekend to detect truncated MDNS queries and can confirm they are killing ADB. The truncated messages seem like valid network traffic, so it shouldn't be killing ADB.

Attached are wireshark records in a screenshot which line up with the ADB logs (timezone is Adelaide +10:30):

daniel@RES-0128:/ressys/maxedge$ cat /tmp/adb.5005.log | grep -ie Bridge -e OSP | tail
01-15 00:02:38.265 37828 37828 F adb     : logging.cpp:39 OSP_CHECK((max_allowed_messages_) > (0)) failed: 0 vs. 0: 
01-15 00:02:41.413 37846 37846 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41
01-15 07:58:02.786 37846 37846 F adb     : logging.cpp:39 OSP_CHECK((max_allowed_messages_) > (0)) failed: 0 vs. 0: 
01-15 07:58:05.928 40026 40026 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41
01-15 08:02:46.408 40026 40026 F adb     : logging.cpp:39 OSP_CHECK((max_allowed_messages_) > (0)) failed: 0 vs. 0: 
01-15 08:02:48.548 40054 40054 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41
01-15 08:11:55.906 40054 40054 F adb     : logging.cpp:39 OSP_CHECK((max_allowed_messages_) > (0)) failed: 0 vs. 0: 
01-15 08:11:59.048 40092 40092 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41
01-15 08:48:03.117 40092 40092 F adb     : logging.cpp:39 OSP_CHECK((max_allowed_messages_) > (0)) failed: 0 vs. 0: 
01-15 08:48:06.280 41928 41928 I adb     : main.cpp:63 Android Debug Bridge version 1.0.41

Have made a PR: https://android-review.googlesource.com/c/platform/packages/modules/adb/+/2909778

My previous comment giving the steps to replicate the issue appears to have been deleted. I have since forgotten the specifics of the steps, but can share the broad outlines.

1. Attached is a PCAP containing a truncated message.
2. Replay this PCAP over UDP (using a tool like https://github.com/ska-sa/udpreplay)

I am able to repro. I can reply with tcpreplay.

tcpreplay -i en0 ~/Downloads/truncated\ mDNS\ packets.pcapng

It looks like we are not using openscreen properly. Config should live as long as the Service is alive. The docs of MdnsResponder and MdnsServiceImpl are explicit.

MdnsResponder:

 // |record_handler|, |sender|, |receiver|, |task_runner|, |random_delay|, and
  // |config| are expected to persist for the duration of this instance's
  // lifetime.

MdnsServiceImpl

  // |task_runner|, |reporting_client|, and |config| must exist for the duration
  // of this instance's life.

Fixed in aosp/2909778

Eihafmryelhafmaree@gmail.com

Eihafmryelhafmaree@gmail.com

Mine has an error with ui nit just the I, not sure how literal this verbose problem is...please keep us updated.....64 arm correct?

bugreport-X692-GL-QP1A.190711.020-2024-10-18-14-13-07.zip

navarretesergio404@gmail.com

Reda

https://drive.google.com/open?id=1AaFQQv5BQwDTOFOnTjGr1OBpyMbwJ0Mw

https://issuetracker.google.com/294120933#attachment46070672

Bardzo dobre

Zadowolony

Scan hacking

Please update my best practice

Excelente inicio

Please update

Done

tnx

Brigadao

Add a comment

.

Dnnddndn

https://www.earntp.com/m/h1jze

حل المشكلات

fastboot version 33.0.3 Model Name: MacBook Pro Chip: Apple M1 Pro

I'm experiencing the same issue. Fastboot doesn't work unless any USB-A hub is connected. After connecting the hub, the device can also be accessed with a MacBook USB-C in fastboot mode. Otherwise, it hangs.

Start