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@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 <drsali...@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@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 >
-- 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
