View previous topic :: View next topic |
Author |
Message |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
Posted: Sat Sep 05, 2020 1:57 pm Post subject: [solved] How to set rsync protocol version |
|
|
After updating last night, this morning I can't rsync, getting a protocol version error.
Code: | cmd=<NULL> machine=casti user=root path=/usr/portage/packages/
cmd[0]=ssh cmd[1]=-l cmd[2]=root cmd[3]=-4 cmd[4]=casti cmd[5]=rsync cmd[6]=--server cmd[7]=-vvvvnlogDtpre.iLsfxCIvu cmd[8]=. cmd[9]=/usr/portage/packages/
opening connection using: ssh -l root -4 casti rsync --server -vvvvnlogDtpre.iLsfxCIvu . /usr/portage/packages/ (10 args)
msg checking charset: UTF-8
(Client) Protocol versions: remote=993287451, negotiated=31
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
[sender] _exit_cleanup(code=2, file=compat.c, line=600): entered
rsync error: protocol incompatibility (code 2) at compat.c(600) [sender=3.2.3]
[sender] _exit_cleanup(code=2, file=compat.c, line=600): about to call exit(2) (DRY RUN)
|
remote=993287451, negotiated=31 That looks bad.
This after re-emerging both rsync and ssh on both machines and both are running the same versions of both.
Code: | MSI ~ # eix -e rsync
[I] net-misc/rsync
Available versions: 3.2.2-r1{tbz2} 3.2.3{tbz2} **9999*l {acl examples iconv ipv6 libressl lz4 ssl static stunnel system-zlib xattr xxhash zstd CPU_FLAGS_X86="sse2"}
Installed versions: 3.2.3{tbz2}(08:24:23 AM 09/05/2020)(iconv ssl xattr -acl -examples -ipv6 -libressl -lz4 -static -stunnel -system-zlib -xxhash -zstd CPU_FLAGS_X86="sse2")
Homepage: https://rsync.samba.org/
Description: File transfer program to keep remote files into sync
MSI ~ # eix -e openssh
[I] net-misc/openssh
Available versions: 8.1_p1-r4^t{tbz2} ~8.2_p1-r7^t ~8.3_p1-r5^t {X X509 audit bindist debug hpn kerberos ldns libedit libressl livecd pam +pie +scp sctp security-key selinux +ssl static test xmss ABI_MIPS="n32" KERNEL="linux"}
Installed versions: 8.1_p1-r4^t{tbz2}(08:25:17 AM 09/05/2020)(X pie ssl -X509 -audit -bindist -debug -hpn -kerberos -ldns -libedit -libressl -livecd -pam -sctp -selinux -static -test -xmss ABI_MIPS="-n32" KERNEL="linux")
Homepage: https://www.openssh.com/
Description: Port of OpenBSD's free SSH release
|
Last edited by Tony0945 on Sat Sep 05, 2020 10:06 pm; edited 1 time in total |
|
Back to top |
|
 |
Anon-E-moose Watchman


Joined: 23 May 2008 Posts: 5048 Location: Dallas area
|
Posted: Sat Sep 05, 2020 2:55 pm Post subject: |
|
|
https://serverfault.com/questions/267154/protocol-version-mismatch-is-your-shell-clean
Quote: | You can tell the client end (assuming it is the newer end) to not advertise such a high version that the old rysnc server version doesn't recognize it. You can do this using the --protocol= option. In my case, using --protocol=30 did the trick. |
_________________ PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie) amd64-no-multilib, eudev, openrc, openbox
The New OTW |
|
Back to top |
|
 |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
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 |
|
Back to top |
|
 |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
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. |
|
Back to top |
|
 |
Hu Moderator

Joined: 06 Mar 2007 Posts: 16464
|
Posted: Sat Sep 05, 2020 7:02 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
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. |
|
Back to top |
|
 |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
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 |
|
Back to top |
|
 |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
Posted: Sat Sep 05, 2020 10:10 pm Post subject: |
|
|
Hu wrote: | 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. |
The actual stroing being printed was: Code: | ## Set the blue hue (color 4) to CornflowerBlue
printf '\e]4;4;#6495ed\a' |
Now, I've lost the color, but can freely scp & rsync.
Serves me right for following Ubuntu fixes. |
|
Back to top |
|
 |
Hu Moderator

Joined: 06 Mar 2007 Posts: 16464
|
Posted: Sat Sep 05, 2020 11:10 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
Ant P. Watchman

Joined: 18 Apr 2009 Posts: 6867
|
Posted: Sun Sep 06, 2020 12:04 am Post subject: |
|
|
There's a reason /etc/skel/.bashrc is written the way it is... |
|
Back to top |
|
 |
Tony0945 Advocate

Joined: 25 Jul 2006 Posts: 4474 Location: Illinois, USA
|
Posted: Sun Sep 06, 2020 2:53 am Post subject: |
|
|
Aha! I knew I had seen some code somewhere.
Thank, Ant P. |
|
Back to top |
|
 |
|