[solved] How to set rsync protocol version

Tony0945 · Last edited by Tony0945 on Sat Sep 05, 2020 10:06 pm; edited 1 time in total

After updating last night, this morning I can't rsync, getting a protocol version error.

Anon-E-moose · Posted: Sat Sep 05, 2020 2:55 pm Post subject:

https://serverfault.com/questions/267154/protocol-version-mismatch-is-your-shell-clean

Tony0945 · Posted: Sat Sep 05, 2020 3:04 pm Post subject:

Thank you Anon-E-Moose. that's in my bag of tricks now!

It didn't help, but it worked on the other end, puling instead of pushing. It worked even without the --protocol=31

I had already transferred the file with scp, but again had to pull instead of push. Something must be wrong on one system or the other despite having re-emerged both sync and openssh on both systems. And both systems use the same versions.

EDIT: And same use flags

Tony0945 · Posted: Sat Sep 05, 2020 6:12 pm Post subject:

For some reason, machine CASTI is sending an ungodly huge protocol version (ascii ?).
I'm checking the source cade but not finding anything. I'll try patching to see where this occurs.

it occurs with not only native built but by using machine MSI (a 2700X) as a build box.

Hu · Moderator Joined: 06 Mar 2007 Posts: 16021

If you suspect that a text string is being misinterpreted as a version number, it could be interesting to print the bad data as a string. Perhaps you will get lucky and it will be a readable string that has an obvious origin, such as the output of bash --no-such-option due to rsync running bash (or something else) with invalid parameters. The number quoted above, 993287451, converts to 0x3B345D1B. Viewed as ASCII, this would be ;4]escape, or possibly transpose those, depending on whether the string was read as little endian or big endian. esc]4; looks a bit like the start of a terminal control sequence. ]2; changes the window title. I don't know what ]4; does.

Tony0945 · Posted: Sat Sep 05, 2020 8:13 pm Post subject:

I guessed that, Hu, but didn't get as far as you did.
Examining the code, all seems well on the C side. However, there are python "helper" function that I think are screwing it up.
I can't read python, but the actual transmission and receipt of the versions in not in the C code and my extremely limited knowledge of python, I think it's in there.
All machines are running the same versions of rsync and openssh with the same useflags. They do have different results from "eselect python list"
DAMN PYTHON TO HELL!
Excuse me, I had to vent. I may resort to patching the C code to ignore obviously impossible versions. Since all of my machines run exactly the same (stable amd) version, I may patch out the version check altogether.

Before that though, I want to follow up on checking bash. I found the problem box did not even have a /root/.bash_profile and copied it over from a different box and rebooted. No change. yes, all three running the same bash with same useflags. I have changed colors since I can't see the dark blue against black. There may be a typo there. Sadly, I commit many typos as my eyes (and maybe fingers) continue to decline.

Tony0945 · Posted: Sat Sep 05, 2020 10:05 pm Post subject:

Problem was caused by a printf in /root/.bashrc to change directory colors

Not python after all.

Between Anon-E-Moose and Hu, this is solved. Unfortunately along the way I trashed passwordless ssh

Tony0945 · Posted: Sat Sep 05, 2020 10:10 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 16021

You probably need to move that behind a test for an interactive shell. The shells spawned by rsync are considered non-interactive, and would skip over a statement that only runs for interactive shells.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6727

There's a reason /etc/skel/.bashrc is written the way it is...

Tony0945 · Posted: Sun Sep 06, 2020 2:53 am Post subject:

Aha! I knew I had seen some code somewhere.
Thank, Ant P.