[OpenIndiana-discuss] mbuffer connection refused on varius ports ... what to try

[Harry Putnam]

Trying to learn how to use mbuffer and tamp to do zfs send/receive
rather than ssh which is pretty slow even on my home gigabit lan at
home where there is very little traffic.

So far using ready made examples from posters on this group or a few I
found online I've constantly run into `connection refused' messages.

I've tried various ports which seems to make no difference. I wondered
if there is something that needs doing with the hosts to make them accept
mbuffer connections?

Send host is an HP xw8600 running bld 151_9 .. and recv host is a vm
running hipster in a vbox vm on a windows 64 host. The windows
firewall is turned off. And I have no firewall type stuff running on
either solaris host.

Here is an example command that I plagiarized totally from posts here
recently.

,----
| sender:
| zfs send tank/***@snap1 | tamp | mbuffer -s 128k -m 1000m -O
| target_host:31337
|
| receiver:
| mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd newtank
`----

My rendition:

zfs send p0/vb/***@170326_1 |tamp|mbuffer -s 128k -m1000m -0
recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
zfs recv -vF p0/vb/vm

Gets this error:
mbuffer warning: connecting to recv-host:31337 Connection refused
mbuffer error unable to connect to recv-host:31337

Trying it by starting recv part on the recv host first (some advice I
found while googling (suposed to provide a listener)) seems to make no
difference. It ends in the same error.

[James Carlson via openindiana-discuss]

Post by Harry Putnam
recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
zfs recv -vF p0/vb/vm

That makes no sense at all. The mbuffer utility doesn't produce usable
output on stdout when given a host name to connect to, and doesn't read
from stdin when given a port number. So piping from one to the other is
confounding. And running both on one host isn't logical. I don't see
what you're trying to do there.

If you plan to use mbuffer between two systems, you have to run the
receiver on one host, and the sender on the other.

Start the receiver first.

If you see "connection refused" warnings, then it's time to start
looking at:

- Is the port actually open on the receiver's side when the mbuffer
utility? Use "netstat -na" to look for it on the receiver after
starting up mbuffer on that system.

- Are you actually connecting to the host you think you are? Make
sure that "recv-host" actually resolves to a valid IP address on
the receiving system, as viewed by the sender. Typing
"host recv-host" on the sender's side can help confirm that.

This sounds like either a usage error or a configuration problem.

[Harry Putnam]

James Carlson via openindiana-discuss

Post by James Carlson via openindiana-discuss

Post by Harry Putnam
recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
zfs recv -vF p0/vb/vm

That makes no sense at all. The mbuffer utility doesn't produce usable
output on stdout when given a host name to connect to, and doesn't read
from stdin when given a port number. So piping from one to the other is
confounding. And running both on one host isn't logical. I don't see
what you're trying to do there.

Not sure where you got the notion that I'm trying to run both
operations on the same host... probably due to some idiocy in my
formulation.

Post by James Carlson via openindiana-discuss
If you plan to use mbuffer between two systems, you have to run the
receiver on one host, and the sender on the other.

I did mention in my post that I had tried by running receiver first on
remote host. It failed too with the error posted.

Post by James Carlson via openindiana-discuss
Start the receiver first.
If you see "connection refused" warnings, then it's time to start
- Is the port actually open on the receiver's side when the mbuffer
utility? Use "netstat -na" to look for it on the receiver after
starting up mbuffer on that system.
- Are you actually connecting to the host you think you are? Make
sure that "recv-host" actually resolves to a valid IP address on
the receiving system, as viewed by the sender. Typing
"host recv-host" on the sender's side can help confirm that.

With that advice in mind I simplified my commands as so:

,----
| On RECV-HOST:
| mbuffer -s 128k -m19m -I 31337 |zfs recv -vF POOL/fs
|
| Checking netstat -na |grep 31337 ... shows it is listening.
| (Thx for that good diagnostic technique)
|
| On SEND-HOST
| zfs send -v POOL/***@snap | mbuffer -s 128k -m 18m -0 RECV-HOST -I 31337
|
| Reports:
|
| send from @ to rpool/***@170327 estimated size is 10.1M
| total estimated size is 10.1M
| TIME SENT SNAPSHOT
|
| summary: 11.1 MiByte in 0.5 sec - average of 24.1 MiB/s
`----

Yippee .. it worked.

Thank you James C for persisting even when my feeble attempts look
foolish and inept to you.

The test had very small data but succeeded, so:

I now have a working example to try to work `tamp' into the commands
for when sending much larger amounts of data.

[Geoff Nordli]

Post by Harry Putnam
Trying to learn how to use mbuffer and tamp to do zfs send/receive
rather than ssh which is pretty slow even on my home gigabit lan at
home where there is very little traffic.
So far using ready made examples from posters on this group or a few I
found online I've constantly run into `connection refused' messages.
I've tried various ports which seems to make no difference. I wondered
if there is something that needs doing with the hosts to make them accept
mbuffer connections?
Send host is an HP xw8600 running bld 151_9 .. and recv host is a vm
running hipster in a vbox vm on a windows 64 host. The windows
firewall is turned off. And I have no firewall type stuff running on
either solaris host.
Here is an example command that I plagiarized totally from posts here
recently.
,----
| target_host:31337
|
| mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd newtank
`----
recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
zfs recv -vF p0/vb/vm
mbuffer warning: connecting to recv-host:31337 Connection refused
mbuffer error unable to connect to recv-host:31337
Trying it by starting recv part on the recv host first (some advice I
found while googling (suposed to provide a listener)) seems to make no
difference. It ends in the same error.

Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Geoff

[jason matthews]

On 2017

Post by Harry Putnam
,----
| target_host:31337
|
| mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd newtank
`----
recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
zfs recv -vF p0/vb/vm

Well, it is -O not -0 -- Oh not zero
you probably need a space between -m and the number so -m 1000m not -m1000m
consider copying and pasting what i wrote the first time :-)

first setup the target side. if you do it backwards you wont be able to
connect. in my original post i assumed you would setup the target first
but i didnt specifically lay it out that way.

step:
1. on target system - this means you log in over there and run this command:
mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd p0

2. on source system
zfs send p0/vb/***@170326_1 | tamp | mbuffer -s 128k -m 1000m -O
target:31337


did you install tamp on both systems?

thanks,
j.

[Harry Putnam]

jason matthews <***@broken.net> writes:

Sorry that I slaughtered your nifty commands so bad. I haven't been
able to get copy paste working on the vm that is the target and so
have been torturing things with my poor typing.

This time I scpped your message across to both hosts so no bunky retyping

Post by jason matthews
mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd p0
2. on source system
target:31337

Thank you sir ... that setup works as promised!
I'm sorry for making you do the extra work.. but thank you for persisting.

Post by jason matthews
did you install tamp on both systems?

Yes, I did have enough sense for that bit.

You commands are running along nicely as I respond..

[Harry Putnam]

Geoff Nordli <***@gnaa.net> writes:

[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?

[Timothy Coalson]

Post by Harry Putnam
[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?
You are transferring via mbuffer through a separate TCP connection, so

changing the ssh cipher won't change the speed.

Tim

[Harry Putnam]

Post by Timothy Coalson

Post by Harry Putnam
[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?
You are transferring via mbuffer through a separate TCP connection, so

changing the ssh cipher won't change the speed.

I think what Timothy C has in mind is dropping mbuffer/tamp and using
ssh for the whole thing

zfs send p/***@now | ssh RECV_HOST zfs recv p/fs

[Harry Putnam]

Post by Harry Putnam
I think what Timothy C has in mind is dropping mbuffer/tamp and using
ssh for the whole thing

OOps that should have read ...
I think what Geoff N has in mind [...]

[Doug Hughes]

Post by Harry Putnam

Post by Timothy Coalson

Post by Harry Putnam
[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?
You are transferring via mbuffer through a separate TCP connection, so

changing the ssh cipher won't change the speed.

I think what Timothy C has in mind is dropping mbuffer/tamp and using
ssh for the whole thing

In my experience, while using mbuffer has some extra pitfalls in terms
of sockets and keeping up with things when there are issues (sometimes
leaving mbuffer's lying around, which was subsequently fixed in the
mbuffer code with SIGCHLD), it's a lot more efficient on the network and
faster to do the backups by 30%. If that isn't so important, ssh works
pretty well.

[Geoff Nordli]

Post by Timothy Coalson

Post by Harry Putnam
[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?
You are transferring via mbuffer through a separate TCP connection, so

changing the ssh cipher won't change the speed.
Tim
____

Hi Tim.

From my tests, arcfour produced a noticeable speed increase. I was
digging around trying to find the numbers, but couldn't find them.

Also Harry will need to figure out what is good enough for speed. If I
am doing frequent replication, then mbuffer makes a lot of sense, but if
I am backing up a couple of times a day, then most likely an SSH
connection is good enough.

I also compress data through the SSH connection, but since Harry said he
was on a LAN compression wouldn't make sense.

Geoff

[Geoff Nordli]

Post by Harry Putnam
[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?

command line works:

-c arcfour

[Harry Putnam]

Post by Geoff Nordli

Post by Harry Putnam
[...]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.

Can that be done on ssh command line or must be done in ssh_config?

-c arcfour

But apparently something has to be done on the receiver too.

Currently my two solaris hosts are very busy shifting 400GB or so
using mbuffer/tamp

So, this was just a quick test on linux with an rsync pull from
win64 10 box running cygwin.

I get an error saying there is no matching cipher

Run from destination host:

rsync -avvz -e 'ssh -c arcfour' ***@2x2:/cygdrive/f/vb/vm/iso /

Unable to negotiate with 192.168.1.20 port 22: no matching cipher
found. Their offer:

chacha20-***@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-***@openssh.com,aes256-***@openssh.com

rsync: connection unexpectedly closed (0 bytes received so far)
[Receiver] rsync error: error in rsync protocol data stream (code 12)
at io.c(226) [Receiver=3.1.2]

I'm not at all familiar with ~/.ssh/config files but tried to use this
on the source host (win 10 running cygwin)

All the examples I googled up seem to be for outgoing ssh cmds, not
incoming. It's not even clear if ~/.ssh/config can handle incoming.

So maybe it cannot be done from command line after all without some
kind of special settings on the source host.

I tried this at ~/.ssh/config on source host. The host named
in the config is the destination host that is running the rsync cmd.

Host g1 <= name of linux host
HostName g1.local.lan <=same linux host
Ciphers arcfour

[Harry Putnam]

Post by Harry Putnam
I tried this at ~/.ssh/config on source host. The host named
in the config is the destination host that is running the rsync cmd.
Host g1 <= name of linux host
HostName g1.local.lan <=same linux host
Ciphers arcfour

Nevermind bothering to reply. I found a way to get it
working... still trying to see if it is any faster.

Ended up add arcfour to defaults in /etc/ssh/sshd_config
On the source host. And setting -c arcfour from cmd line on
destination host.

Thanks for the push start..

[Harry Putnam]

Post by Geoff Nordli
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.
Geoff

I made an attempt to see about the various speeds available
with different Ciphers were like

I didn't use any solaris hosts yet, as I want to ensure there
was no hidden snapshot or the like involved.

Source host openssh 7.4p1 Windows 10 running cygwin
Destination host openssh 7.5_p1-r1 Gentoo linux 4.9.10 kenel

The gentoo host is actually running in a vbox vm on the same
windows host ... they have bridged networks setup.

=============================================

Using default cipher (Not sure what that is or
how to find out. But the default list below does not
include `arcfour' so It would not be arcfour

The list of defaults is:

sshd -T |grep [Cc]ipher]

chacha20-***@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,
aes128-***@openssh.com,aes256-***@openssh.com

(on both ends)

(NOTE: I believe they are listed in order of preference so I guess
that means it would be chacha...)

time rsync -avvz ./isos g1:/

real 32m55.694s
user 5m9.918s
sys 9m41.603s

sudo du -sh /isos
29G /isos

du -sb /isos
30833797326 /isos

28.7 GB

==============================================

At destination host remove the test data: rm -rf /isos

Now using arcfour

Specified in the cmdline on destination host,but I had to add arcfour
to the defaults on the Source host /etc/ssh/sshd_config

time rsync -avvz -e 'ssh -c arcfour' /isos /


real 34m1.297s
user 4m22.176s
sys 7m30.078s

du -sb /isos
30833797326 /isos
28.7 GB

==============================================

As you see the default Cipher was barely a minute faster than
the arcfour over 28.7 GB of data.

Absolutely NOT a diffinative test in any way but should at least show
that on this network arcfour is likely to be no faster than the
defaults in recent openssh versions.

I still have to run an mbuffer/tamp transfer to see how that compares.

[Harry Putnam]

Post by Harry Putnam
As you see the default Cipher was barely a minute faster than
the arcfour over 28.7 GB of data.
Absolutely NOT a diffinative test in any way but should at least show
that on this network arcfour is likely to be no faster than the
defaults in recent openssh versions.
I still have to run an mbuffer/tamp transfer to see how that compares.

I've posted to a different subject, the result of a comparison of
mbuffer/tamp as against ssh

Subject: Comparison of mbuffer/tamp to ssh (A novice attempt)

[Harry Putnam]

Post by Harry Putnam
As you see the default Cipher was barely a minute faster than
the arcfour over 28.7 GB of data.
Absolutely NOT a diffinative test in any way but should at least show
that on this network arcfour is likely to be no faster than the
defaults in recent openssh versions.
I still have to run an mbuffer/tamp transfer to see how that compares.

Here is one test that appears to show that mbuffer/tamp is
significantly slower than recent ssh version

[Jerry Kemp]

Off topic question.

Wasn't familiar with the tamp utility you were referencing in your sample
command below. After some research, I believe you are referencing this:

https://blogs.oracle.com/timc/resource/tamp-2.5-source.zip

<https://blogs.oracle.com/timc/entry/tamp_a_lightweight_multi_threaded>

Correct??

Thanks,

Jerry

Post by Harry Putnam
Trying to learn how to use mbuffer and tamp to do zfs send/receive
rather than ssh which is pretty slow even on my home gigabit lan at
home where there is very little traffic.
So far using ready made examples from posters on this group or a few I
found online I've constantly run into `connection refused' messages.
I've tried various ports which seems to make no difference. I wondered
if there is something that needs doing with the hosts to make them accept
mbuffer connections?
Send host is an HP xw8600 running bld 151_9 .. and recv host is a vm
running hipster in a vbox vm on a windows 64 host. The windows
firewall is turned off. And I have no firewall type stuff running on
either solaris host.
Here is an example command that I plagiarized totally from posts here
recently.
,----
| target_host:31337
|
| mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd newtank
`----
recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
zfs recv -vF p0/vb/vm
mbuffer warning: connecting to recv-host:31337 Connection refused
mbuffer error unable to connect to recv-host:31337
Trying it by starting recv part on the recv host first (some advice I
found while googling (suposed to provide a listener)) seems to make no
difference. It ends in the same error.
_______________________________________________
openindiana-discuss mailing list
https://openindiana.org/mailman/listinfo/openindiana-discuss

[jason matthews]

Post by Jerry Kemp
Off topic question.
Wasn't familiar with the tamp utility you were referencing in your
sample command below. After some research, I believe you are
https://blogs.oracle.com/timc/resource/tamp-2.5-source.zip
<https://blogs.oracle.com/timc/entry/tamp_a_lightweight_multi_threaded>
Correct??
Thanks,
Jerry

yes, provided at those or similar links when i first referenced.

thanks,
j.