xiaomi: improve loock.cateye.v01 compatibility

[66Ton99]

Summary

• try miss first for loock.cateye.v01 with existing fallback behavior
• support legacy auth fallback for CatY (admin + cloud password path)
• add CatY-specific legacy start command sequence and keep it tolerant across firmware variants
• make legacy probing more tolerant for doorbell-style behavior (video can appear without audio first)
• increase CatY read deadline in legacy producer path

Context

This addresses Xiaomi Loock CatY (loock.cateye.v01) streams that authenticate but end with:
streams: read udp [::]:xxxxx: i/o timeout

Linked issue: #2180

Validation

• go test ./internal/xiaomi ./pkg/xiaomi/...

[AlexxIT]

Are you sure we need this? If the probe had a timeout for the entire probe, this is a timeout for each packet.

[66Ton99]

No, it is to make sure it is not a problem

[AlexxIT]

Does your loock.cateye.v01 use the miss protocol? Because the one I tried used a legacy protocol.

[66Ton99]

I am not sure. I will try today to monitor traffic and see how the native app connects to the device.
And I will get a Firmware.

[AlexxIT]

I just don't understand why you think the new firmware works on the miss protocol.

[66Ton99]

Original Firmware 1.3.8 from the board. It can be broken.
loock.cateye.v01.zip

[66Ton99]

CatY (loock.cateye.v01) deep test update.

What was added in this branch:

• xlocal=<port>: bind TUTK UDP local port explicitly.
• xraw=1/2: pre-dial raw UDP replay (short/long payload sets from pcap).
• xraw=3: raw replay via the same UDP socket used by TUTK dial (PreConnect hook in pkg/tutk).
• xskiplogin=1: optional skip of xiaofangLogin for Loock experiments.

What was tested (multiple retries + delays):

• baseline, xdirect, xraw=1, xraw=2, xraw=3, with/without xskiplogin.
• fixed local ports (xlocal=41590, xlocal=52366).
• remote relay hosts (m1..m5.iotcplatform.com:10001).
• long run: 12 consecutive frame attempts using the strongest combo: xdirect=1&xport=6666&xlocal=41590&xraw=3&xskiplogin=1.

Observed result:

• HTTP returned 200, but the stream payload remained empty in all attempts.
• logs remained streams: read udp [::]:<port>: i/o timeout.
• router captures consistently showed mac -> cam traffic; cam -> mac was absent or near-zero, while phone sessions still had active bidirectional flow.

Conclusion so far:

• no stable CatY media session established by go2rtc yet;
• behavior strongly suggests vendor/session locking around CatY local stream ownership.

[66Ton99]

Firmware quick triage loock.cateye.v01.Bin findings:

• Model markers are present: loock.cateye.v01, Loock-C1.
• MIOT/P2P artifacts are present in plaintext strings:
  • _sync.camera_login
  • _sync.get_p2p_id
  • p2p_id
  • p2p_password
  • p2p_checktoken
  • p2p_dev_public_key
  • wakeup
• Cloud/OTA marker found: https://ots.io.mi.com.
• TLS stack present (mbedtls, PSK ciphers listed), which supports the assumption that stream/session setup depends on cloud-backed auth state.

Implication:

• Firmware confirms CatY has explicit P2P token/checktoken flow and likely session-bound auth beyond current go2rtc TUTK emulation.
• Next reverse step should focus on _sync.get_p2p_id + p2p_checktoken request/response format and where those values are consumed in runtime before media starts.

[66Ton99]

Latest findings from live CatY (loock.cateye.v01) testing:

• Protocol path confirmation: loock.cateye.v01 is routed via xiaomi/legacy (TUTK), not xiaomi/miss (MISS requires vendor=... and v02 model).
• Current state is no longer a pure direct-connect problem: in multiple runs connectDirect reached stage=broadcast ok / stage=direct ok (184-byte responses from camera).
• Despite direct-connect success, media still does not start for go2rtc.
• Router captures show media goes to phone IP when Xiaomi app is active, while go2rtc host receives only short handshake/control replies (or no replies in bad runs), not video payload bursts.
• Tried variants without success:
  • xraw=3 and xraw=4 pre-connect bursts (including fresh startup sequence replay)
  • fixed local port (xlocal=41795)
  • skip legacy login (xskiplogin=1)
  • post-connect replay of observed packets
• Conclusion: blocker is likely in post-connect session/media authorization/start sequence (IOCtrl-level), not in initial UDP wake/connect.