On Wed, 2014-11-05 at 12:03 +0100, Peter Magnusson wrote: > I tested the patch you provided and it does make the certhash look > much nicer so that part seems to work fine now. The patch I sent wasn't quite correct; you were just getting a hex dump of a random part of the stack instead of a hash of the cert. Fixed and pushed to git now. > Unfortunately im still having the same problem as i described before. Right. That will be an orthogonal issue. Can we see the full output of 'openconnect -vv --dump-http-traffic' on the offending run, please? Perhaps just to Kevin and/or myself, and/or vet it for sensitive information first. But I don't think you've entered any passwords by the time it goes wrong, have you? And you already gave us the hostname, so I don't *think* there'll be anything sensitive in there. Do check though. I wonder if the server is conflating the two connection attempts. When we're asked to run the CSD trojan, we're given a 'CSD token' for it to submit its results with. We are expected to put that token into a cookie named 'sdesktop' for the subsequent HTTP requests from OpenConnect. If you run OpenConnect again too soon, perhaps it's still expecting your requests to bear the *same* CSD token, and that's why it doesn't tell you to run the CSD trojan again. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141105/15a4dc68/attachment.bin>
