Two directly connected Trezors to macARM M1 are never detected

[bosomt]

Describe the bug
Two directly connected Trezors to mac M1 are never detected.
This behavior is known since 03/2021 when we received our first M1 macbook.
See last screenshot, even suite does not register that i connected T1 and disconnected TT, it still reports TT as connected.
As new macARM architecture is replacing old Intel architecture maybe we can check and find reason for this behavior.

Problem can be solved by connecting one of devices to hub / usbC to usbMicro adapter does not help/ or by using Chrome and webUSB connection.

Firmware version and revision
2.5.2 , 2.5.3, 1.11.x

Desktop/smartphone setup (please complete the following information):

• OS: macOS M1 13.0 and 12.x

Screenshots

2x TT

T1 and TT

Only T1 connected

2x TT - no bridge

[tsusanka]

Not now, but in future it would be interesting to find out if this happens on your trezor/trezor-suite#6509 branch. As @bosomt writes

Problem can be solved ... by using Chrome and webUSB connection.

so my guess is it will not happen there?

cc @mroz22

[bosomt]

tested on https://suite.corp.sldev.cz/suite-web/transport-refactor-2/web/
with standalone bridge 2.0.27
i only see one device connected
maybe we can retest with app build ?

~/Downloads/trezorfwasuite/devkitfw  ioreg -p IOUSB                                                                                                   1 ✘  took 56s
+-o Root  <class IORegistryEntry, id 0x100000100, retain 29>
  +-o AppleT8103USBXHCI@00000000  <class AppleT8103USBXHCI, id 0x1000002c8, registered, matched, active, busy 0 (67248 ms), retain 84>
  | +-o TREZOR@00100000  <class IOUSBHostDevice, id 0x10003ac7c, registered, matched, active, busy 0 (19 ms), retain 23>
  +-o AppleT8103USBXHCI@01000000  <class AppleT8103USBXHCI, id 0x10000029b, registered, matched, active, busy 0 (50055 ms), retain 92>
    +-o TREZOR@01100000  <class IOUSBHostDevice, id 0x10003ac38, registered, matched, active, busy 0 (43 ms), retain 31>

[tsusanka]

Yes please try with desktop and Bridge turned off.

[bosomt]

same result with 2.0.32 + this branch binary :(

Info:

• Suite version: desktop 23.3.0 (8219f5c62d380a3be25dc8cfc51dad10a427b51e)
• Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) TrezorSuite/23.3.0 Chrome/104.0.5112.124 Electron/20.3.12 Safari/537.36
• OS: MacIntel
• Screen: 1440x900
• Device: model T 2.5.3 Bitcoin-only (revision 2f03ace311584988d5aeab58fd1acf24ef54711a)
• Transport: BridgeTransport 2.0.32

[tsusanka]

But that seems you are still using Bridge. And this branch it should not be needed. Maybe you have to set "nodeUSB" in debug settings?

[bosomt]

QA OK

NICE!

Info:

• Suite version: desktop 23.3.0 (8219f5c62d380a3be25dc8cfc51dad10a427b51e)
• Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) TrezorSuite/23.3.0 Chrome/104.0.5112.124 Electron/20.3.12 Safari/537.36
• OS: MacIntel
• Screen: 1440x900
• Device: model T 2.5.3 Universal (revision 2f03ace311584988d5aeab58fd1acf24ef54711a)
• Transport: NodeUsbTransport

 ~  ioreg -p IOUSB                                                         ✔
+-o Root  <class IORegistryEntry, id 0x100000100, retain 29>
  +-o AppleT8103USBXHCI@00000000  <class AppleT8103USBXHCI, id 0x1000002c8, reg$
  | +-o TREZOR@00100000  <class IOUSBHostDevice, id 0x1000450da, registered, ma$
  +-o AppleT8103USBXHCI@01000000  <class AppleT8103USBXHCI, id 0x10000029b, reg$
    +-o TREZOR@01100000  <class IOUSBHostDevice, id 0x1000450c1, registered, ma$

[tsusanka]

Mega cool! cc @mroz22

@sime another reason to kill Bridge 😛.

[matejkriz]

I'm reopening because the bridge issue is not resolved. It works fine with NodeUSB and that just proves that it's a bridge bug and not macos.

[MiroslavProchazka]

Will be solved by introducing node usb transport as primary. @mroz22