search

nforgeio / RaspberryDebugger

Visual Studio Extension to Debug C# on Raspberry Pi
Apache License 2.0
39 stars 12 forks source link

Debugging sessions are failing to start after re-imaging the test Raspberry #8

Closed jefflill closed 4 years ago

jefflill commented 4 years ago

I'm not entirely sure what's happening yet. It looks like the ssh.exe debug adapter is working, but the underlying issue is:

I thought something bad might have happened to the ssh.exe because everything was working before I uninstalled and then reinstalled it to retest the detection and installation code.

I did notice:

jefflill commented 4 years ago

This is interesting: I still have the old flash drive before created the new pristine Raspberry drive. The latest debugger code works against the old drive. This suggests that the problem is with the Raspberry configuration; I must have configured something manually while working on this over the past couple weeks and whatever this didn't make it into the automated setup.

jefflill commented 4 years ago

It looks like I'm not installing the .NET Core package dependencies; the current VSIX code doesn't do this and I'll be I manually installed an SDK package on the old Raspberry drive at some point early in the project and that would have installed the dependencies and they would have remained on the drive during subsequent testing.

I'm currently downloading the packages as tar files and expanding them myself. I tried adding the dependency installation to my script but it's still not working. Perhaps I should just use the package manager so this will be automatic.

jefflill commented 4 years ago

I believe this is probably due to the DOTNET_ROOT environment variable not being set when the VSDBG is launched by the (ssh.exe) debug adapter. I saw debugging work (once) while messing around with environment variables for #10.

jefflill commented 4 years ago

That wasn't the problem. I captured some SSH network traffic to see what's going on and it appears that the debug adapter doesn't get past authentication:

No. Time    Source  Destination Protocol    Length  Info
1   0.000000    10.0.0.2    10.0.0.7    TCP 66  59976 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
2   0.007873    10.0.0.7    10.0.0.2    TCP 66  22 → 59976 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128
3   0.007938    10.0.0.2    10.0.0.7    TCP 54  59976 → 22 [ACK] Seq=1 Ack=1 Win=262656 Len=0
4   0.008759    10.0.0.2    10.0.0.7    SSHv2   87  Client: Protocol (SSH-2.0-OpenSSH_for_Windows_7.7)
5   0.017752    10.0.0.7    10.0.0.2    TCP 60  22 → 59976 [ACK] Seq=1 Ack=34 Win=64256 Len=0
6   0.079798    10.0.0.7    10.0.0.2    SSHv2   97  Server: Protocol (SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2)
7   0.082184    10.0.0.2    10.0.0.7    SSHv2   1374    Client: Key Exchange Init
8   0.088652    10.0.0.7    10.0.0.2    SSHv2   1134    Server: Key Exchange Init
9   0.090248    10.0.0.2    10.0.0.7    SSHv2   102 Client: Diffie-Hellman Key Exchange Init
10  0.095213    10.0.0.7    10.0.0.2    TCP 60  22 → 59976 [ACK] Seq=1124 Ack=1402 Win=64128 Len=0
11  0.117340    10.0.0.7    10.0.0.2    SSHv2   506 Server: Diffie-Hellman Key Exchange Reply, New Keys, Encrypted packet (len=172)
12  0.121672    10.0.0.2    10.0.0.7    TCP 54  59976 → 22 [RST, ACK] Seq=1402 Ack=1576 Win=0 Len=0

It looks like the adapter resets the connection immediately after receiving the key exchange reply from the Raspberry. No commands were every sent to the Raspberry.

The weird thing is that the exact same code works fine for the old Raspberry flash drive. I suspect that the SSH session started on the workstation is rejecting the reply from the pristine Raspberry because fingerprint doesn't match what the workstation has on file (because it has the fingerprint for the old Raspberry).

jefflill commented 4 years ago

JUMPIN' CATFISH, BATMAN!

That was the problem. I added the -o "StrictHostKeyChecking no" option to the ssh.exe parameters for the debug adapter which disables server fingerprint check. It would be better to add the host fingerprint to the workstation user's ~/.ssh/knownhosts file first from a security perspective, but I'm going to call this good.

This was a frustrating bug, but this turned out to be a good one. Fixing this will prevent users from experiencing a lot of pain and I was also able to find and fix a few other problems along the way.