RTT 50ms timeout is too short for linux container pass-through

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • RTT 50ms timeout is too short for linux container pass-through

      * Running an STM32 device

      * JLink Ultra to Linux host machine over USB and SWD

      * VS Code remote dev container (docker) for my environment, cortex-debug extension in VS Code to active and use JLinkExe. So USB is tunneled inside to docker (linux to linux)

      * Docker exposing port 19021. HOST USB >> CONTAINER >> TCP 19021 >> HOST. It's a little weird, but the benefits of embedded with remote container can not be oversold.

      * RTTViewer is activated on my host machine

      * Using CONNECT TO EXISTING when I have a debug session open in VS Code.

      * RTTViewer will most of the time report the error: "J-Link DLL did not send welcome string in time."

      * If you spam the connect attempt, it will occasionally connect.


      SUSPECTED: That Segger RTTViewer will timeout at 50ms. This is likely enough time for most people but I have a lag somewhere. When I spam the CONNECT button and blow through the errors, occasionally it will connect because randomly connections make it under timeout.

      SOLUTION: I need this to be a variable or otherwise extended.

      WORKAROUND: I don't know why the connection is so slow, I could look into that?


      VIDEO:


      WIRESHARK DATA:

      The first three attempts, the SYN/SYNACK is the same, but the PUSH never comes, so after 50ms, the Viewer kills the connection with a FIN.

      LINE 28/29, this time the PUSH comes at 38 milliseconds for whatever reason. This seems to be under the 50ms timeout that Segger put in place. Now it works fine.

      I don't know what loopback from container to PC timing should be. However, the timeout seems too show for most networking this connection over internet, I'm not sure that is common but it wouldn't work there either.

      Source Code

      1. No. Time Source PHY Protocol Length Delta time (µs end to start) SN NESN More Data Event counter Info
      3. 3155 0.504 127.0.0.1 TCP 53072 → 19021 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM TSval=2925611610 TSecr=0 WS=128
      4. 3156 0.000 127.0.0.1 TCP 19021 → 53072 [SYN, ACK] Seq=0 Ack=1 Win=65483 Len=0 MSS=65495 SACK_PERM TSval=2925611610 TSecr=2925611610 WS=128
      5. 3157 0.000 127.0.0.1 TCP 53072 → 19021 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925611610 TSecr=2925611610
      6. 3163 0.050 127.0.0.1 TCP 53072 → 19021 [FIN, ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925611660 TSecr=2925611610
      7. 3164 0.000 127.0.0.1 TCP 19021 → 53072 [ACK] Seq=1 Ack=2 Win=65536 Len=0 TSval=2925611661 TSecr=2925611660
      8. 3165 0.000 127.0.0.1 TCP 19021 → 53072 [FIN, ACK] Seq=1 Ack=2 Win=65536 Len=0 TSval=2925611661 TSecr=2925611660
      9. 3166 0.000 127.0.0.1 TCP 53072 → 19021 [ACK] Seq=2 Ack=2 Win=65536 Len=0 TSval=2925611661 TSecr=2925611661
      11. 3176 0.498 127.0.0.1 TCP 53076 → 19021 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM TSval=2925612159 TSecr=0 WS=128
      12. 3177 0.000 127.0.0.1 TCP 19021 → 53076 [SYN, ACK] Seq=0 Ack=1 Win=65483 Len=0 MSS=65495 SACK_PERM TSval=2925612159 TSecr=2925612159 WS=128
      13. 3178 0.000 127.0.0.1 TCP 53076 → 19021 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925612159 TSecr=2925612159
      14. 3184 0.050 127.0.0.1 TCP 53076 → 19021 [FIN, ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925612209 TSecr=2925612159
      15. 3185 0.000 127.0.0.1 TCP 19021 → 53076 [FIN, ACK] Seq=1 Ack=2 Win=65536 Len=0 TSval=2925612209 TSecr=2925612209
      16. 3186 0.000 127.0.0.1 TCP 53076 → 19021 [ACK] Seq=2 Ack=2 Win=65536 Len=0 TSval=2925612209 TSecr=2925612209
      18. 3198 0.797 127.0.0.1 TCP 53082 → 19021 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM TSval=2925613006 TSecr=0 WS=128
      19. 3199 0.000 127.0.0.1 TCP 19021 → 53082 [SYN, ACK] Seq=0 Ack=1 Win=65483 Len=0 MSS=65495 SACK_PERM TSval=2925613007 TSecr=2925613006 WS=128
      20. 3200 0.000 127.0.0.1 TCP 53082 → 19021 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925613007 TSecr=2925613007
      21. 3206 0.050 127.0.0.1 TCP 53082 → 19021 [FIN, ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925613057 TSecr=2925613007
      22. 3207 0.000 127.0.0.1 TCP 19021 → 53082 [FIN, ACK] Seq=1 Ack=2 Win=65536 Len=0 TSval=2925613057 TSecr=2925613057
      23. 3208 0.000 127.0.0.1 TCP 53082 → 19021 [ACK] Seq=2 Ack=2 Win=65536 Len=0 TSval=2925613057 TSecr=2925613057
      25. 3218 0.485 127.0.0.1 TCP 53090 → 19021 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM TSval=2925613543 TSecr=0 WS=128
      26. 3219 0.000 127.0.0.1 TCP 19021 → 53090 [SYN, ACK] Seq=0 Ack=1 Win=65483 Len=0 MSS=65495 SACK_PERM TSval=2925613543 TSecr=2925613543 WS=128
      27. 3220 0.000 127.0.0.1 TCP 53090 → 19021 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=2925613543 TSecr=2925613543
      28. 3232 0.038 127.0.0.1 TCP 19021 → 53090 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=120 TSval=2925613582 TSecr=2925613543
      29. 3233 0.000 127.0.0.1 TCP 53090 → 19021 [ACK] Seq=1 Ack=121 Win=65536 Len=0 TSval=2925613582 TSecr=2925613582
      30. 3234 0.000 127.0.0.1 TCP 53090 → 19021 [PSH, ACK] Seq=1 Ack=121 Win=65536 Len=256 TSval=2925613582 TSecr=2925613582
      31. 3235 0.000 127.0.0.1 TCP 19021 → 53090 [ACK] Seq=121 Ack=257 Win=65280 Len=0 TSval=2925613582 TSecr=2925613582
      Display All
      EDIT: Tried to use Docker `--network=host` makes the whole thing unconnectable even with spamming the connect button.

      The post was edited 2 times, last by RTTseemsOK: Added test for docker settings. ().

    • I could still use help on this. Ideally there would be a way to adjust the timeout, otherwise, if someone could adjust in it a new build that would be good too.

      Or even more ideally... Maybe this project is updated as a Tabby plug in or something a little more versatile?

    • It might not be the solution for your setup, but I am using JLink GDB Server and RTT Viewer on the host and connect to the GDB Server on the host from within the docker container. The marked line in the launch.json shows the connection to the GDB server for downloading and debugging, RTT is done on the host side. Hope that helps.

      "configurations": [
      {
      "type": "cortex-debug",
      "request": "launch",
      "servertype": "external",
      >> "gdbTarget": "host.docker.internal:2331", <<

      "name": "Jlink",
      "device": "nrf9160",
      "interface": "swd",
      "rtos": "Zephyr",
      "runToEntryPoint": "main"
      },

      The post was edited 1 time, last by StefanSchmidt ().

    • I’m already attaching to GDB inside the container.

      The issue is rather that the telnet from docker to host adds too much latency for RTT Viewer.

      All I would need is a single byte change, but obviously this would be reverse engineering discussion and that is strictly forbidden on this forum!

      I have a workaround for now. But it would be great if Segger realized that 50ms arbitrary and too fast for edge cases and made this an argument or just increased it.

      It’s not even my biggest issue with RTT Viewer. The auto connect and re-up from old sessions needing be manually cleared on all 16 of the virtual terminals is worse I think.

      I figured I would start with the “easy one”.