esp_tinyusb 2.2.0: explicit `tinyusb_config_t.descriptor.*` pointers stored in `s_desc_cfg` but defaults served on the wire (IEC-537)

[ff4415]

Summary

When passing explicit descriptors (device, full_speed_config, string) via tinyusb_config_t.descriptor to tinyusb_driver_install() for an NCM-only target, the chassis-side state confirms the pointers correctly reach s_desc_cfg (verified by tinyusb_descriptors_set's own boot-summary log), yet the host receives esp_tinyusb's default descriptors (idProduct=0x4001, "Espressif Device", "Espressif CDC Device", CDC-ACM subclass=2) on the wire.

The bug appears specific to this device + full_speed_config + string-all-non-NULL path with CONFIG_TINYUSB_CDC_ENABLED=n. Reproduces on both Linux (6.12) and macOS hosts.

Environment

• ESP-IDF: v6.0
• esp_tinyusb: pinned ^2.2.0 (resolved by IDF Component Manager)
• Target: ESP32-S3 (native USB-OTG)
• Hosts tested: Linux 6.12 (Debian Trixie, cdc_ncm module available) + macOS Big Sur+ — both see defaults
• sdkconfig.defaults:

  CONFIG_TINYUSB_NET_MODE_NCM=y
  CONFIG_TINYUSB_CDC_ENABLED=n
  

  No unknown kconfig symbol warnings during build — both keys recognized in 2.2.0.

Minimal reproducer

#include \"tinyusb.h\"
#include \"tinyusb_default_config.h\"   /* TINYUSB_TASK_DEFAULT() */
#include \"tusb.h\"
#include \"class/net/net_device.h\"     /* CFG_TUD_NET_MTU */

enum { STRID_LANGID, STRID_MFG, STRID_PROD, STRID_SER, STRID_IF, STRID_MAC };
enum { ITF_NUM_CDC, ITF_NUM_CDC_DATA, ITF_NUM_TOTAL };
#define EPNUM_NOTIF 0x81
#define EPNUM_OUT   0x02
#define EPNUM_IN    0x82
#define NCM_TOTAL_LEN  (TUD_CONFIG_DESC_LEN + TUD_CDC_NCM_DESC_LEN)

static const tusb_desc_device_t my_device_desc = {
    .bLength            = sizeof(tusb_desc_device_t),
    .bDescriptorType    = TUSB_DESC_DEVICE,
    .bcdUSB             = 0x0201,
    .bDeviceClass       = TUSB_CLASS_MISC,
    .bDeviceSubClass    = MISC_SUBCLASS_COMMON,
    .bDeviceProtocol    = MISC_PROTOCOL_IAD,
    .bMaxPacketSize0    = CFG_TUD_ENDPOINT0_SIZE,
    .idVendor           = 0x303A,
    .idProduct          = 0x4022,    /* unique magic to distinguish our descriptor from default 0x4001 */
    .bcdDevice          = 0x0100,
    .iManufacturer      = STRID_MFG,
    .iProduct           = STRID_PROD,
    .iSerialNumber      = STRID_SER,
    .bNumConfigurations = 1,
};

static const uint8_t my_ncm_config_desc[] = {
    TUD_CONFIG_DESCRIPTOR(1, ITF_NUM_TOTAL, 0, NCM_TOTAL_LEN, 0, 100),
    /* 9-arg form (no trailing bInterval) — what 2.2.0's TinyUSB fork accepts */
    TUD_CDC_NCM_DESCRIPTOR(ITF_NUM_CDC, STRID_IF, STRID_MAC,
                           EPNUM_NOTIF, 64,
                           EPNUM_IN, EPNUM_OUT,
                           64, CFG_TUD_NET_MTU),
};

static char mac_str[13] = \"020000000001\";

static const char *string_desc[] = {
    (const char[]) {0x09, 0x04},   /* 0: LANGID English (US) */
    \"MyVendor\",                    /* 1: Manufacturer */
    \"MyProduct (NCM)\",             /* 2: Product */
    \"0001\",                        /* 3: Serial */
    \"MyNCMInterface\",              /* 4: Interface */
    mac_str,                       /* 5: MAC */
};

void app_main(void)
{
    /* (NVS / esp_netif / WiFi-STA setup omitted for brevity) */

    const tinyusb_config_t tusb_cfg = {
        .port = TINYUSB_PORT_FULL_SPEED_0,
        .phy = { .skip_setup = false, .self_powered = false, .vbus_monitor_io = -1 },
        .task = TINYUSB_TASK_DEFAULT(),
        .descriptor = {
            .device             = &my_device_desc,
            .qualifier          = NULL,
            .string             = string_desc,
            .string_count       = sizeof(string_desc) / sizeof(string_desc[0]),
            .full_speed_config  = my_ncm_config_desc,
            .high_speed_config  = NULL,
        },
        .event_cb  = NULL,
        .event_arg = NULL,
    };
    ESP_ERROR_CHECK(tinyusb_driver_install(&tusb_cfg));

    /* Then tinyusb_net_init(&net_cfg) for NCM. */
}

idf_component.yml:

dependencies:
  espressif/esp_tinyusb:
    version: \"^2.2.0\"
  idf: \">=5.0\"

Expected

Host enumerates with our descriptor: idProduct=0x4022, Product=\"MyProduct (NCM)\", bInterfaceClass=2 / bInterfaceSubClass=13 (CDC-NCM). Linux loads cdc_ncm and a usb0 virtual NIC appears.

Actual

Chassis-side: pointers correctly reach s_desc_cfg (no using default warnings)

tinyusb_descriptors_set in descriptors_control.c logs its summary table with our values:

I (545) tusb_desc:
┌─────────────────────────────────┐
│  USB Device Descriptor Summary  │
├───────────────────┬─────────────┤
│bDeviceClass       │ 239         │
│bDeviceSubClass    │ 2           │
│bDeviceProtocol    │ 1           │
│bMaxPacketSize0    │ 64          │
│idVendor           │ 0x303a      │
│idProduct          │ 0x4022      │  ← OUR value (default would be 0x4001)
│bcdDevice          │ 0x100       │
│iManufacturer      │ 0x1         │
│iProduct           │ 0x2         │
│iSerialNumber      │ 0x3         │
│bNumConfigurations │ 0x1         │
└───────────────────┴─────────────┘
I (710) TinyUSB: TinyUSB Driver installed on port 0

No No Device descriptor provided, using default / No Full-speed configuration descriptor provided, using default / No String descriptors provided, using default warnings — all three of our pointers reach tinyusb_descriptors_set non-NULL and get assigned to s_desc_cfg.{dev, fs_cfg, str}.

Host-side: defaults on the wire (Linux `lsusb -v`, fresh enumeration)

After a true physical USB disconnect+reconnect (kernel logs usb 3-2: USB disconnect, device number 5 followed by usb 3-2: new full-speed USB device number 7 — confirming no caching):

Bus 003 Device 007: ID 303a:4001 Espressif Systems Espressif Device
Device Descriptor:
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  bDeviceProtocol         1 Interface Association
  idVendor           0x303a Espressif Systems
  idProduct          0x4001 Espressif Device       ← default, NOT 0x4022
  iManufacturer           1 Espressif Systems
  iProduct                2 Espressif Device        ← default, NOT \"MyProduct (NCM)\"
  iSerial                 3 123456                  ← default, NOT \"0001\"
  Configuration Descriptor:
    wTotalLength       0x004b                       ← 75 bytes (default ACM); ours would be ~94
    Interface Descriptor:
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)    ← CDC-ACM (default), NOT NCM (subclass 13)
      iInterface              4 Espressif CDC Device  ← default, NOT \"MyNCMInterface\"

Linux kernel binds cdc_acm 3-2:1.0: ttyACM2: USB ACM device. macOS binds AppleUSBACMControl similarly. No usb0 / enX virtual NIC enumerates on either OS.

What we ruled out

• Host-side USB caching: kernel saw a true disconnect with new device-number assignment; lsusb -v reads raw GET_DEVICE_DESCRIPTOR + GET_CONFIGURATION_DESCRIPTOR bytes off the wire (no kernel cache).
• OS-specific bug: identical wrong descriptor on macOS Big Sur+ AND Linux 6.12.
• Kconfig silent-no-op: CONFIG_TINYUSB_CDC_ENABLED=n is accepted in 2.2.0 (no unknown kconfig symbol warning during build), but the wire behavior is unchanged whether it's set or not.
• Stale chassis flash: rebuilt fresh + flashed via UART; chassis's own boot-summary log shows our idProduct=0x4022 value being stored, proving our pointer was received.
• NULL pointer slipping in: no using default warnings logged by tinyusb_descriptors_set, so all three of our pointers are received non-NULL.

Question

When CONFIG_TINYUSB_CDC_ENABLED=n and we provide explicit tinyusb_config_t.descriptor.{device, full_speed_config, string} pointers, where does esp_tinyusb actually source the bytes it serves to tud_descriptor_device_cb() / tud_descriptor_configuration_cb() / tud_descriptor_string_cb()?

descriptors_control.c::tud_descriptor_device_cb() returns (uint8_t const *)s_desc_cfg.dev, which (per the chassis-side summary log) holds our pointer. Yet lsusb -v shows defaults.

• Is there a runtime override path that bypasses s_desc_cfg.{dev, fs_cfg, str} and serves descriptor_*_default directly?
• Is there a call-order or flag we're missing for the NCM-only-target case?
• Is the device + full_speed_config + string-all-non-NULL path expected to work, or is it implicitly tied to CONFIG_TINYUSB_CDC_ENABLED=y?

Happy to provide additional traces (full boot log, agent build log with all warnings, dmesg from the Linux host) if helpful.

[github-actions]

Hi @ff4415! Please be aware that the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

I'm sorry, but the knowledge sources provided do not contain enough information to definitively diagnose this specific bug or answer the detailed questions about the internal descriptor-serving path in esp_tinyusb 2.2.0.

What the knowledge sources confirm:

• esp_tinyusb uses tinyusb_config_t.descriptor.* fields, and if any field is NULL, a default descriptor is used instead. [Component esp_tinyusb]
• The component's source is hosted at github.com/espressif/esp-usb, and the relevant implementation files (descriptors_control.c) are there.

---

What I can suggest based on the available information

1. Check for a second tinyusb_driver_install() call or re-initialization

Your chassis log shows our descriptor at boot, but if anything calls tinyusb_driver_install() again (e.g., inside tinyusb_net_init() or a network reconnect path), it might reinstall with a default config.

2. Verify CONFIG_TINYUSB_CDC_ENABLED=n actually suppresses the CDC-ACM default config descriptor

The wire shows a CDC-ACM configuration descriptor (wTotalLength=75, bInterfaceSubClass=2). This strongly suggests the configuration descriptor being served is the built-in CDC-ACM default, not your NCM one. Even though s_desc_cfg.fs_cfg holds your pointer per the log, there may be a compile-time path in tud_descriptor_configuration_cb() that conditionally returns a hardcoded default when CONFIG_TINYUSB_CDC_ENABLED=y is detected at build time — or conversely, when NCM is enabled, a different callback path is active.

3. File a bug directly on the esp-usb repository

Since this issue is already opened at github.com/espressif/esp-usb/issues/491, the Espressif maintainers of esp_tinyusb are the right people to answer the internal question:

"Is there a runtime override path that bypasses s_desc_cfg and serves descriptor_*_default directly when CONFIG_TINYUSB_NET_MODE_NCM=y + CONFIG_TINYUSB_CDC_ENABLED=n?"

The key files to request review of from maintainers are:

• device/esp_tinyusb/descriptors_control.c — specifically tud_descriptor_configuration_cb() and tud_descriptor_string_cb()
• Any Kconfig-guarded #if blocks that might select a default config descriptor at compile time regardless of the runtime pointer

4. Workaround to try

As a workaround, you can bypass esp_tinyusb's descriptor management entirely by using the standalone TinyUSB option and providing your own usb_descriptors.c with the standard TinyUSB weak callbacks: [Espressif TinyUSB]

uint8_t const *tud_descriptor_device_cb(void) { return (uint8_t const *)&my_device_desc; }
uint8_t const *tud_descriptor_configuration_cb(uint8_t index) { return my_ncm_config_desc; }
uint16_t const *tud_descriptor_string_cb(uint8_t index, uint16_t langid) { /* ... */ }

This completely sidesteps s_desc_cfg and any potential override path in descriptors_control.c. [usb_descriptors.c File]

---

I'd strongly recommend following up directly on the GitHub issue with a request for a maintainer to trace through tud_descriptor_configuration_cb() under the CONFIG_TINYUSB_NET_MODE_NCM=y + CONFIG_TINYUSB_CDC_ENABLED=n Kconfig combination, as the knowledge sources available to me do not include the full source of descriptors_control.c needed to give a definitive answer.

[ff4415]

Update — workaround attempt with bare espressif/tinyusb also fails identically

Took the bot's reply suggestion and dropped espressif/esp_tinyusb entirely. Switched to bare espressif/tinyusb 0.19.0~3 with our own tud_descriptor_*_cb + tud_network_*_cb strong-symbol overrides. Same outcome — host still receives default descriptors that aren't even in our compiled binary.

What changed since the original issue

• Dropped the espressif/esp_tinyusb dependency entirely.
• Added espressif/tinyusb ^0.19.0 + espressif/usb * (latter for esp_private/usb_phy.h).
• New tusb_config.h next to main.c with CFG_TUD_NCM=1, all other classes (CDC, ECM/RNDIS, MSC, HID, etc.) explicitly 0.
• Hand-rolled USB stack init in wifi_forwarder_init(): usb_new_phy() for OTG PHY → tud_init(0) → FreeRTOS task driving tud_task().
• Provided strong-symbol tud_descriptor_{device,configuration,string}_cb in main.c (with __attribute__((used)) to prevent --gc-sections from stripping them).
• Provided tud_network_{recv,xmit,init}_cb + the required tud_network_mac_address[6] symbol in our forwarder source (also __attribute__((used))).
• Single-slot xmit pattern with a binary semaphore for the upstream→host direction.

Chassis-side evidence (proves our code IS running)

Boot log:

I (282) app_init: Compile time:     May  8 2026 10:39:55
I (537) sidecar-fw: WiFi started — STA: aegis-lab-upstream (USB-NCM downstream)
I (544) sidecar-fw: TinyUSB device stack up (NCM-only, MAC=50787D173EE4)
I (544) sidecar-fw: TinyUSB device task running
I (563) sidecar_forwarder: user-space forwarder up — STA rxcb + raw-TinyUSB NCM cb registered

usb_new_phy() returned ESP_OK. tud_init(0) returned true. The FreeRTOS task driving tud_task() is running. Telemetry tick counter increments normally; mTLS bench output is healthy. Our code is running, end of story.

Hex inspection of the 541,819-byte flash image confirms the device descriptor is present and correct:

@offset 0xfe08:  12 01 01 02 ef 02 01 40 3a 30 22 40 00 01 01 02 03 01
                                            └─────┘
                                          idProduct=0x4022 (our value)

There is no other device descriptor in the binary. grep -c "Espressif Device" sidecar-fw-smoke.bin = 0. grep -c "123456" sidecar-fw-smoke.bin = 0. The default-mode strings simply do not exist in our linked image.

Host-side evidence (Linux, fresh enumeration after physical replug)

$ dmesg | tail
usb 3-2: USB disconnect, device number 9
usb 3-2: new full-speed USB device number 10 using xhci_hcd
usb 3-2: Device not responding to setup address.
usb 3-2: device not accepting address 10, error -71
usb 3-2: WARN: invalid context state for evaluate context command.
usb 3-2: new full-speed USB device number 11 using xhci_hcd
usb 3-2: New USB device found, idVendor=303a, idProduct=4001
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2: Product: Espressif Device
usb 3-2: Manufacturer: Espressif Systems
usb 3-2: SerialNumber: 123456
cdc_acm 3-2:1.0: ttyACM2: USB ACM device

$ lsusb -v | grep -A4 "303a"
Bus 003 Device 011: ID 303a:4001 Espressif Systems Espressif Device
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  idProduct          0x4001 Espressif Device      ← NOT 0x4022

The host receives bytes that don't exist anywhere in our linked image.

dmesg pattern points at ROM ↔ app handoff

The device 10 fails to set address (error -71 EPROTO) followed by device 11 succeeds with defaults looks like a ROM-bootloader → app transition. The first address-set attempt fails because the SoC is rebooting from ROM-mode → app-mode mid-enumeration; the second attempt succeeds — but the descriptors served are still defaults.

Working hypothesis: the USB-OTG peripheral retains its ROM-mode state across the SoC reset. ROM-mode exposed the device with idProduct=0x4001 / "Espressif Device" / "123456" (these are the ROM bootloader's USB-CDC defaults). Our app's usb_new_phy() + tud_init(0) initializes TinyUSB's data structures but doesn't fully re-enumerate the peripheral with our descriptors. Linux just continues to see ROM's descriptor.

If that hypothesis is correct, the fix would be to explicitly disconnect from the bus (e.g. via tud_disconnect() or by toggling the PHY's pull-up) before tud_init(0), then reconnect. We haven't tried that yet — it's specific enough that the maintainer's input would be valuable before another rebuild cycle.

So the bug is below esp_tinyusb

Both reproducers — the original espressif/esp_tinyusb 2.2.0 path AND this raw-TinyUSB path — produce identical defaults on the wire. The original report's working hypothesis (esp_tinyusb's s_desc_cfg indirection bug) is now ruled out: with bare TinyUSB there is no s_desc_cfg indirection, our descriptors go through tud_descriptor_*_cb directly. Yet the wire is unchanged.

The bug is somewhere in the IDF / USB-OTG / ROM-bootloader integration layer.

Asks

1. Is there a known interaction between ROM bootloader's USB-CDC mode and an app's usb_new_phy() + tud_init(0) that requires explicit re-enumeration?
2. Should an app calling usb_new_phy() immediately after boot expect a clean descriptor-reset, or is there a known step (tud_disconnect() / PHY pull-up toggle / etc.) we're missing?
3. The dmesg "device not accepting address, error -71" then "new full-speed USB device" handoff — is that pattern indicative of anything specific?

Happy to provide the full reproducer source + boot log if it'd help. The minimal-reproducer code in the original report still applies; the only addition is the bare-TinyUSB integration scaffolding (PHY init + task + tusb_config.h).

[ff4415]

✅ Workaround validated — bare TinyUSB serves correct descriptors on the wire

Closing the loop on this thread. After cleaning up our lab setup (we'd been observing a separate unflashed board, see edit note below), the bare-espressif/tinyusb workaround DOES correctly serve our explicit descriptors on the wire. So:

• espressif/esp_tinyusb 2.2.0: still serves default CDC-ACM descriptor regardless of tinyusb_config_t.descriptor.{device,full_speed_config,string} pointers. Original bug stands.
• Bare espressif/tinyusb 0.19.0~3 with our own tud_descriptor_*_cb strong overrides + __attribute__((used)): works correctly. The host receives our descriptor.

Confirmed working on Linux (debian1301, kernel 6.12)

$ lsusb -v
Bus 003 Device 014: ID 303a:4022 Espressif Aegis Sidecar (USB-NCM)
  idVendor        0x303a Espressif
  idProduct       0x4022 Aegis Sidecar (USB-NCM)   ← our PID, not 0x4001 default
  iProduct        2 Aegis Sidecar (USB-NCM)         ← our string
  iSerial         3 0001                            ← our serial
  wTotalLength    0x005e (94 bytes)                 ← our NCM descriptor

$ dmesg | tail
cdc_ncm 3-2:1.0: MAC-Address: 90:70:69:15:c2:5c
cdc_ncm 3-2:1.0 eth0: register 'cdc_ncm' at usb-..., CDC NCM (NO ZLP), 90:70:69:15:c2:5c
cdc_ncm 3-2:1.0 enx90706915c25c: renamed from eth0

$ ip -br link | grep enx
enx90706915c25c  DOWN           90:70:69:15:c2:5c <BROADCAST,MULTICAST>

cdc_ncm driver bound, virtual NIC enumerated. The __attribute__((used)) on every tud_descriptor_*_cb and tud_network_*_cb was important — without it, --gc-sections strips the strong overrides and TinyUSB falls back to weak defaults.

Bug status from our perspective

The original report's espressif/esp_tinyusb bug remains: providing explicit tinyusb_config_t.descriptor.* pointers via tinyusb_driver_install() doesn't make those bytes appear on the wire. The chassis-side state (esp_tinyusb's own boot summary log shows our idProduct=0x4022 reaching s_desc_cfg.dev) and the host-side state (Linux lsusb -v shows defaults) disagree. We didn't find a path through esp_tinyusb that respects the explicit pointers; switching to bare TinyUSB sidestepped the issue entirely.

If maintainers can clarify whether explicit tinyusb_config_t.descriptor.* is supposed to work on esp_tinyusb 2.2.0, that'd be valuable for users who want to stay on the high-level wrapper. Our project has accepted the bare-TinyUSB workaround.

Thanks to the auto-bot reply for pointing us at the workaround. Going to leave this issue open in case a maintainer wants to investigate the s_desc_cfg.dev → wire byte path discrepancy.

---

Edit note: An earlier comment in this thread (now obviated by this update) described the bare-TinyUSB workaround also failing. That observation was an artifact of a multi-board lab setup where we'd been flashing one ESP32-S3 (UART connected to one host) but the OTG cable went to a different, unflashed board sitting in ROM USB-CDC mode. The "host receives bytes that aren't in our binary" observation was the unflashed board's ROM bootloader CDC default, not our app's descriptor. Once we flashed the correct board, the workaround works as expected. The original esp_tinyusb bug is still real (we did flash that path correctly first), but the bare-TinyUSB conclusion was wrong in the earlier comment.

[ff4415]

⚠️ Retraction — original report was caused by lab-fixture confusion, not an esp_tinyusb bug

After cleaning up the multi-board lab setup and re-running the same esp_tinyusb 2.0.1 code path with explicit tinyusb_config_t.descriptor.{device, full_speed_config, string} pointers via tinyusb_driver_install(), the wire shows the correct descriptors. esp_tinyusb is working as intended.

Re-test result (same code that allegedly "failed", flashed to the right board)

$ lsusb -v
Bus 003 Device 017: ID 303a:4022 Espressif Aegis Sidecar (USB-NCM)
  idVendor   0x303a Espressif
  idProduct  0x4022 Aegis Sidecar (USB-NCM)   ← our PID
  iProduct   2 Aegis Sidecar (USB-NCM)        ← our string
  iSerial    3 0001                            ← our serial
  bcdUSB     2.01                              ← our value
  wTotalLength 0x005e (94 bytes)               ← our NCM descriptor

$ dmesg | tail
cdc_ncm 3-2:1.0: MAC-Address: 90:70:69:15:c2:5c
cdc_ncm 3-2:1.0 enx90706915c25c: register 'cdc_ncm' ... CDC NCM (NO ZLP)

Root cause: lab fixture, not esp_tinyusb

We had multiple ESP32-S3 boards in the lab. We were correctly flashing the chassis on one host (board's UART side connected there) — so the chassis-side boot summary log legitimately showed idProduct=0x4022 reaching s_desc_cfg.dev, and we believed our firmware was running. However, the OTG cable on the observation host went to a different, unflashed board sitting in ROM USB-CDC mode. That unflashed board's USB-CDC defaults are exactly idProduct=0x4001 / "Espressif Device" / "123456" — which we mistook for "esp_tinyusb's defaults sneaking through."

Once we consolidated the fixture to one board on the observation host (UART for flashing, OTG for the NCM peer), esp_tinyusb's explicit-descriptor path works exactly as the docs promise.

What I think actually happens

tinyusb_descriptors_set correctly stores the caller's pointers in s_desc_cfg.{dev, fs_cfg, str}. The tud_descriptor_*_cb() callbacks return s_desc_cfg.dev etc. as advertised. The wire bytes match the chassis's compiled descriptor. There is no s_desc_cfg-to-wire discrepancy. Apologies for the noise.

Closing recommendation

I'd suggest closing this issue. The bare-TinyUSB workaround we adopted (in our private repo) was unnecessary — esp_tinyusb 2.0.1+ with TINYUSB_DEFAULT_CONFIG() + explicit descriptor.{device, full_speed_config, string} pointers correctly serves user-supplied descriptors on the wire. Anyone hitting a similar "host receives bytes not in our binary" pattern should first verify their USB-OTG cable goes to the same physical board they're flashing — multi-board lab setups can produce a remarkably convincing false positive.

Thanks for the patience reviewing the original report. Please close at your convenience.

[peter-marcisovsky]

Hi @ff4415
Thank you for the report and the explanation of what has happened. As I understood from the issue report, there is no bug, no action for us that needs be addressed.

If that is the case, feel free to close the issue. Thank you