'--address' option on client side.

[Dan Stromberg]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20210326/40f5ebe2/attachment.htm>