Hi, Let's resurrect this question. :) I've made a patch to illustrate what I mean about the wildcard address in the lock object. Regards, Alexander On Tue, Jan 24, 2023 at 8:22 AM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jan 23, 2023 at 3:17 PM Alexander Zubkov <green@qrator.net> wrote:
On Mon, Jan 23, 2023 at 3:06 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
Hi all,
A quick try to fix the problem. But I'm not sure in complete correctness though.
Hi
That looks more-or-less OK, will merge.
- ipa_equal(x->addr, y->addr); + ipa_equal(x->addr, y->addr) && + ipa_equal(x->addr2, y->addr2);
I think undefined addr2 should work like wildcard, i.e. the condition should be:
Maybe. I do not know well how this lock works. If different lock keys can affect another. And in this case it is probably better to fix "local" role for that second address and reflect it in its name.
I think even better to call this wildcard_addr, for example. So if something else needs this wildcard feature, it is clear which addr to use in the lock object.
ipa_equal(x->addr, y->addr) && (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2, y->addr2));
(Undefined local ip will be resolved to some ip and may collide with defined ones.)
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."