On Wed, 17 Mar 2021 at 11:21, Paul Wouters <[email protected]> wrote: > > On Wed, 17 Mar 2021, Andrew Cagney wrote: > > > looking around the above there's DHR's comment: > > > > /* > > * ??? the use of hp looks nonsensical. > > * Either the first non-empty host_pair should be used > > * (like the current code) and the following should > > * be broken into two loops: first find the non-empty > > * host_pair list, second look through the host_pair list. > > * OR > > * what's really meant is look at the host_pair for > > * each sra, something that matches the current > > * nested loop structure but not what it actually does. > > */ > > > > and this lookup: > > > > hp = find_host_pair(&sra->this.host_addr, > > &sra->that.host_addr); > > > > so I suspect having the code also: > > > > find_host_pair(&sra->this.host_addr, &unset_address) > > > > would do what you want and much faster. > > I don't think so, because I don't think hostpair will consider all the > %any connections as belonging to the same host pair. > > > However, along the lines of DHR's comment, is this just adding to the > > problem? > > It's concept is really for left/right on the same IP (which is also an > issue, with multiple behind NAT). Which is why I think the concept of > hostpair is not sustainable. This isn't the first time code needed to > be changed to search all connections :/
I still don't follow. >From the bug. Before any connection, A's host-pair contains the oriented template: local=192.168.173.129 remote = %any : A(template) after one connection it contain both an oriented template and an oriented instance: A(template): local=192.168.173.129 remote = %any : A(instance): local=192.168.173.129 remote = 192.168.173.144 the above lookup is only for 192.168.173.129->192.168.173.144, if it also looked for 192.168.173.129->unset_address, it would find the template. Which I'm guessing is what is needed. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
