'--address' option on client side.

[Harry Mangalam]

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