potentialy interesting

[retornaz]

Have a look at this commit: retornaz@7a7820f

This make it compatible with a more up to date sonicwall server. But maybe it stay compatible with an old version.

[abrasive]

Hi Philippe,
I'm glad to see someone is getting some use from this :) And thanks for the patch!

I'd be open to merging patches along these lines, but I'd like to be certain about the purpose of each change. Why the changes to the PPP options? I know the official client uses that set, but they don't appear to make any difference to performance in my setup. As the SSL link is not compressed, not disabling the compression options should help throughput a little also. And why the addition of nonstandard headers with no space after the colon? Does the server insist on them?

I've just committed a fix for the connection dropping during heavy upload, by the way - don't miss it.

[retornaz]

Hi, well, it was some random hacking until I got something working (with a MitM proxy to better see the differences).
For the ppp options, I don't think it make a difference. What definitely make a difference is to send the header of the tunnel in "one shot". The patch like that is not in a mergable state. I can try to work a bit on in order to have it in mergable state.

[abrasive]

Hi @retornaz, are you still using nxBender?

I've just found and fixed a bug in 454ded which was causing me problems off and on, I'd be interested to know if that resolves your issues also.

[tisoft]

I don't know what it is in this change, but without it, I can't connect and with it, it works. So thanks to @abrasive for starting the work and thanks to @retornaz to modify it so it works with the endpoint I'm using.

This is so much better than the crappy original client...

[tisoft]

I have rebased the commit from @retornaz to the latest master. This works fine for me.

[abrasive]

Two years on, I've finally got a few fixes up here. This gets me working with recent devices. If anyone is still able to test, that would be super helpful!