On Tue, Jun 23, 2020 at 01:07:54PM +0200, Marco Gaiarin wrote:
>
> > What i'm missing? Thanks.
>
> No, sorry, but there's something in the csync2 logic that realy i don't
> understand.
>
> As stated in previous email, i was used to update some files via
> csync2, using my portable PC at work. So i had:
>
> host [email protected];
>
> switching to smartwork, i've simply added the second, VPN, address of
> my portable:
>
> host [email protected];
> host [email protected];
>
> and found that csync still work as expected.
>
>
> Now i'm back to work, and syncing with the 'old' address assigned does
> not work (eg, i can sync only from VPN address); if i comment out the
> VPN address, eg:
>
> host [email protected];
> #host [email protected];
>
> I can sync from the non-VPN with some server, but not others:
>
> Dirty item %wpkghome%/packages/vlc.xml gaio.vpn.sv.lnf.it 0
> Local> HELLO gaio.vpn.sv.lnf.it\n
> Peer> Identification failed!\n
> While syncing file %wpkghome%/packages/vlc.xml:
> response from peer(%wpkghome%/packages/vlc.xml): vdmpp1.pp.lnf.it [13] <-
> Identification failed!
> Local> BYE\n
> Peer> OK (cu_later).\n
> response from peer(<no file>): vdmpp1.pp.lnf.it [6] <- OK (cu_later).
>
>
> I'm really puzzled... please help me...
It all depends on the *forward* name resolution
from the view point of the server.
The server accepts a TCP connection,
calls getpeername() on that socket,
gets the client address.
Later, that client "identifies" with HELLO some.name.there.
The server uses a *forward* lookup on that,
it calls getaddrinfo(some.name.there, ...).
If one of the addresses returned by this getaddrinfo()
matches the client address found earlier with getpeername(),
csync2 is happy. Otherwise, it is not.
Lars
_______________________________________________
Csync2 mailing list
[email protected]
https://lists.linbit.com/mailman/listinfo/csync2
