On Fri, 27 Apr 2018, Robin O'Leary wrote:
On Thu, Apr 26, 2018 at 11:33:46PM -0700, Stephen Casner wrote:
The use case is not so much debugging the internals of wolfssh, rather diagnosing incompatibilities between clients and the the wolfssh server. Enabling DEBUG_WOLFSSH basically compiles in more log statements, but those don't print unless "log level debug wolfssh" is entered.
At least for the specific problem with cipher algorithm choice that at least two people (including me) have encountered, a better solution would be to avoid having to resort to debug mode at all by giving that condition its own unique error code that could be returned to the caller. With the additional reporting you have already added, I guess there'd be a clear message logged somewhere---and maybe reported back to the connecting client?
Clearly what you say here is correct. I was coming to that conclusion myself last evening. The reason I have not pursued this solution is that I'm trying to avoid changes to the wolfssh code, such as extending the list of error codes, that would not be part of their release. But since I have established my credentials with them by providing the SCP code, perhaps I can make this change and issue a pull request for it. Reporting back to the connecting client may not be possible because the algorithms have to be agreed before the channel is open. Unfortunately the client diagnostics don't give the necessary details, either, just "SSH2_MSG_KEXINIT sent" and then the connection closes.
I would still be good to have a working menu config option to define DEBUG_WOLFSSH where it really is necessary to dig deeper.
Agreed. I'll see if I can figure out how to properly avoid the _impure_ptr problem. -- Steve