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>
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>
On Fri 26 Mar 2021, Harry Mangalam via rsync wrote:> > 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.255As both interfaces are on the same network, the kernel will use one interface to transmit data to that network.> 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 0Here you see wlx9cefd5fb0bb5 has a lower metric, hence it will preferentially be used. You need to dive deeper into linux policy based routing, to force traffic e.g. from a particular IP address out over a certain interface. This is totally outside the scope of rsync; there's nothing rsync can do to influence this. You need the 'ip rule' and 'ip route' commands. Paul