'--address' option on client side.
Dan Stromberg
drsalists at gmail.com
Fri Mar 26 20:24:41 UTC 2021
I've not looked into mrsync and multiple interfaces; I'm guessing it'll use
your (multicast) routing table.
On Fri, Mar 26, 2021 at 1:13 PM Harry Mangalam via rsync <
rsync at lists.samba.org> wrote:
> mrcast is interesting (Hadn't stumbled across it before) but while it
> handles multicat, it doesn't seem to be able to handle multiple interfaces,
> if I read the docs correctly.
> Am I wrong?
> harry
>
> On Fri, Mar 26, 2021 at 12:29 PM Dan Stromberg <drsalists at gmail.com>
> wrote:
>
>>
>> Hi Harry. Are you the person I worked with at UCI a bit?
>>
>> Anyway, you might consider trying mrsync; it's intended to do rsync over
>> multicast.
>>
>> HTH.
>>
>> On Fri, Mar 26, 2021 at 12:22 PM Harry Mangalam via rsync <
>> rsync at lists.samba.org> wrote:
>>
>>> Spent an hour trying to find the answer to this on the various SO, SF,
>>> other usual suspects, but have failed.
>>>
>>> I'm trying to improve a parallel rsync wrapper called parsyncfp (pfp)
>>> in response to a user request. He wants rsync to emit data on multiple
>>> interfaces (one interface per rsync instance). From the man page it seems
>>> like the '--address' option would do that and in fact using it as such does
>>> not result in an error, but it also does not result in both interfaces
>>> being used, either from pfp or when launched directly from different shells.
>>>
>>> My route (working from home) shows the 2 wlan interfaces up with
>>> different IP #s:
>>> wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>>> inet 192.168.1.223 netmask 255.255.255.0 broadcast
>>> 192.168.1.255
>>> ...
>>>
>>> wlx9cefd5fb0bb5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>>> inet 192.168.1.186 netmask 255.255.255.0 broadcast
>>> 192.168.1.255
>>> ...
>>> and route shows:
>>> $ route
>>>
>>> Kernel IP routing table
>>> Destination Gateway Genmask Flags Metric Ref Use
>>> Iface
>>> default router.asus.com 0.0.0.0 UG 601 0 0
>>> wlx9cefd5fb0bb5
>>> default router.asus.com 0.0.0.0 UG 602 0 0
>>> wlp3s0
>>> link-local 0.0.0.0 255.255.0.0 U 1000 0 0
>>> wlp3s0
>>> 192.168.1.0 0.0.0.0 255.255.255.0 U 601 0 0
>>> wlx9cefd5fb0bb5
>>> 192.168.1.0 0.0.0.0 255.255.255.0 U 602 0 0
>>> wlp3s0
>>>
>>> and while the arp results from the rsyncing machine look OK:
>>> $ arp -n
>>>
>>> Address HWtype HWaddress Flags Mask
>>> Iface
>>> 192.168.1.107 ether 90:73:5a:f1:23:ee C
>>> wlx9cefd5fb0bb5
>>> 192.168.1.107 ether 90:73:5a:f1:23:ee C
>>> wlp3s0
>>> 192.168.1.1 ether 74:d0:2b:5e:32:40 C
>>> wlp3s0
>>> 192.168.1.139 ether d8:31:34:64:bc:f0 C
>>> wlp3s0
>>> 192.168.1.139 ether d8:31:34:64:bc:f0 C
>>> wlx9cefd5fb0bb5
>>> 192.168.1.198 ether 94:94:26:08:b2:4e C
>>> wlx9cefd5fb0bb5
>>> 192.168.1.1 ether 74:d0:2b:5e:32:40 C
>>> wlx9cefd5fb0bb5
>>>
>>>
>>> the arp table from another machine on the same net show this:
>>> $ arp -n
>>> Address HWtype HWaddress Flags Mask
>>> Iface
>>> 192.168.1.203 ether b0:68:e6:3d:58:a7 C
>>> wlp3s0
>>> 192.168.1.107 ether 90:73:5a:f1:23:ee C
>>> wlp3s0
>>> 192.168.1.186 ether 9c:ef:d5:fb:0b:b5 C
>>> wlp3s0
>>> 192.168.1.1 ether 74:d0:2b:5e:32:40 C
>>> wlp3s0
>>> 192.168.1.223 ether 9c:ef:d5:fb:0b:b5 C
>>> wlp3s0
>>>
>>> and the rsync machine is the .186 and .223 above, indicating that the 2
>>> interfaces are regarded as the same MAC.
>>>
>>> The alternating rsync commands generated from pfp are:
>>> rsync --address=192.168.1.223 --bwlimit=1000000 -a -s
>>> --log-file=/home/hjm/.parsyncfp/rsync-logfile-14.34.52_2021-03-25_16
>>> --files-from=/home/hjm/.parsyncfp/fpcache/f.16 '/home/hjm'
>>> bridgit:/home/hjm/test
>>>
>>> and
>>>
>>> rsync --address=192.168.1.186 --bwlimit=1000000 -a -s
>>> --log-file=/home/hjm/.parsyncfp/rsync-logfile-14.34.52_2021-03-25_17
>>> --files-from=/home/hjm/.parsyncfp/fpcache/f.17 '/home/hjm'
>>> bridgit:/home/hjm/test
>>>
>>> But the byte streams show only data flowing on one. This is the case
>>> whether the rsyncs are started from parsyncfp or via separate rsyncs
>>> started from separate shells.
>>> Before I go further down the rabbit hole and start messing with ARP
>>> tables and network namespaces, was this the intent of the option or am I
>>> misunderstanding it?
>>> On the server side, the --address option seems to be used to bind the
>>> responding IP# and while I haven't tried that, that seems to be
>>> straightforward (but not useful for me).
>>>
>>> thanks in advance for such a magical program
>>> Harry
>>> --
>>>
>>> Harry Mangalam
>>> --
>>> Please use reply-all for most replies to avoid omitting the mailing list.
>>> To unsubscribe or change options:
>>> https://lists.samba.org/mailman/listinfo/rsync
>>> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>>>
>>
>
> --
>
> Harry Mangalam
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20210326/0459a95b/attachment.htm>
More information about the rsync
mailing list