[Bug] recording stops after a unsupported encoding EncodingType error:

[toni-moreno]

Hi @amitbet .

I'm working with your last vnc2video version and I've seen that vnc connection is closed after an unsuported EncodingType error.

time="2020-02-18 10:15:45" level=error msg="Received error message :unsupported encoding EncodingType(458900) \n"

There is any way to bypass this error and continue with the connection opened?

Thank you very much!

[amitbet]

Hi Toni, The error you are seeing means something went wrong while understanding the stream, 458900 is not an acceptable encoding type that wasn't in my list - it is just some garbage that was read from the stream since the vnc2video code got derailed. can you provide some info about your environment (what vnc server are you using? what OS / version, which vnc mode / settings, etc)?

Regards, Amit.

On Tue, Feb 18, 2020 at 8:18 AM Toni Moreno [email protected] wrote:

Hi @amitbet https://github.com/amitbet .

I'm working with your last vnc2video version and I've seen that vnc connection is closed after an unsuported EncodingType error.

time="2020-02-18 10:15:45" level=error msg="Received error message :unsupported encoding EncodingType(458900) \n"

There is any way to bypass this error and continue with the connection opened?

Thank you very much!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amitbet/vnc2video/issues/9?email_source=notifications&email_token=AAXNOACGWLFZHPJACGSHIVLRDPN23A5CNFSM4KXELM42YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IOKAM6A, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXNOABLCL6W6J7PEYROEXTRDPN23ANCNFSM4KXELM4Q .

[toni-moreno]

Hi @amitbet . I've been working on recording video from one docker image to other where serving vnc from X11 with x11vnc server.

https://github.com/aerokube/windows-images/blob/master/image/entrypoint.sh#L39

Anyway, it seems a very "heavy" decision force closing connection when a encondingType error happens , don't you thing ?. What would happen if you simply ignore it?

Thank you very much!

[amitbet]

It is not an encoding error... this means that something unexpected happened and now the proxy no longer understands the stream, so everything that will be read from this point onwards will be misunderstood causing endless errors. the RFB stream is not very robust, it doesn't contain size metadata, so continued reading of the bytes according to the spec is crucial to staying in sync with the meaning, any deviation and you veer wildly off course. the solution is usually finding the frame that was not understood (usually some type that wasn't programmed in), and provide the correct handling in the code.

On Thu, Feb 20, 2020 at 7:03 AM Toni Moreno [email protected] wrote:

Hi @amitbet https://github.com/amitbet . I've been working on recording video from one docker image to other where serving vnc from X11 with x11vnc server.

https://github.com/aerokube/windows-images/blob/master/image/entrypoint.sh#L39

Anyway, it seems a very "heavy" decision force closing connection when a encondingType error happens , don't you thing ?. What would happen if you simple ignore it?

Thank you very much!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amitbet/vnc2video/issues/9?email_source=notifications&email_token=AAXNOAFZA5GOQ67DNBDOF33RDYFIZA5CNFSM4KXELM42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMKX3SI#issuecomment-588611017, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXNOABJKEUYN2LML5HWDW3RDYFIZANCNFSM4KXELM4Q .

[toni-moreno]

ok @amitbet . If ignore bad code is not an option. Perhaps could be close() and try to restart() connection again ? What do you think about this solution?

[amitbet]

usually the right fix would be to debug the code and see what went wrong (it will usually be some message type that isn't implemented in the code, like some qemu specific message or maybe some other message that I haven't implemented)

once we know what message it was, it is usually added easily - you can look at vncproxy where most of these loose ends were tied up already.

when developing this I used tightVNC server, and osxVnc , but not x11vnc server these servers should work better with this project, but the best approach would be to fix the bug.

if you have the time to debug this, tell me what you find and i'll help guide you towards the answer.

[ternshare]

I had the same problem with x11vnc server and I found it just happen after copying text, which relates to ServerCutText message of the RFB protocol. You can change the ServerCutText struct from _ [1]byte to _ [3]byte, and change var pad [1]byte to var pad [3]byte in ServerCutText Read and Write functions in messages.go. It correct the message length for me and there's no more error.