On Sat, 25 Jan 2020 at 15:29, Antony Antony <ant...@phenome.org> wrote: > > First, I noticed sanitizers have improved a lot. Thanks. > > I know iptable change was discused a while ago[1]. > > Now we are sanitizing sport and dport when it is not default, however, for > some tests like mobike it is not a good idea.
No. The old sanitizers did that - they sanitized any port with 4 or more digits. Mostly. Maybe. I suspect this was because any port >1024 was once considered ephemeral. Now, like the comment says: # ephemeral ports # - according to IANA: 49152-65535 # - according to Linux: 32768-61000 # the below matches 30000-.. which is good enough we're sanitizing anything >=32k (ok, technically, 30k :-) because it _is_ ephemeral. > I am still thinking how to change the tests to preserve the ports when we > want them to, and sanitize when we should not care. I guess using different > NAT port ranges would help. I red the comments in ephemeral-ports.sed. > > Andrew,www > I have a feeling the following commit along with other ephemeral-ports.sed > changes have gone a bit too far some tests. > > We should keep ports of ip xfrm state in mobike and few other tests, crypto > values are not important in mobike. That is why it is not an "ipsec look". > Also ip xfrm state is called several times in those tests, "ipsec look" > output would be too long and we are likely to overlook changes/regression. > > https://testing.libreswan.org/v3.28-1508-gca5c702fb3-master/ikev2-mobike-06/OUTPUT/east.console.diff > > eg these are not important in mobike > + replay-window 32 flag af-unspec > + auth-trunc hmac(sha256) 0xHASHKEY 128 otoh they do no harm and bring things into line with other tests. like the comment points out: # Paul: this is _crazy_, nothing is ephemeral here so it completely breaks # everything that tries to use this. It seems like it tried to fixup # older kernel vs newer kernel ip xfrm output or something ???? and a grep shows we're down to two tests (and they don't appear in TESTLIST anyway): testing/pluto/ikev2-68-sa-clones-auto-route/testparams.sh:REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS ip-xfrm.sed" testing/pluto/ikev2-68-sa-clones-null-iperf/testparams.sh:REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS ip-xfrm.sed" > this line should be there. > + encap type espinudp sport 4500 dport EPHEMERAL addr 0.0.0.0 > I have a feeling that dport EPHEMERAL is important in this test and > shouldn't be sanitized. I will take a closer look when working on the > sanitizer. The port comes from: iptables -t nat -L -n | grep 192.1.33.222 || iptables -t nat -A POSTROUTING -s 192.1.33.222/32 -p udp -j SNAT --to-source 191.1.2.250:33000-34000 && iptables -t nat -A POSTROUTING -s 192.1.33.222/32 -j SNAT --to-source 192.1.2.250 which is ephemeral - i.e., above 32k and random. > I will try to fix them, however, do not want to fight with your changes. > > I think, some how the ephemeral ports should kept in mobike tests. Which > possibly means on nic specify NAT sports to be bellow 30K? > if nic has narrow range, with 2 or 3 ports then mobike tests should get > predicable port. Atleast that is the theory we will see. > > May be revert this commit for mobikes tests? Now I'm confused. If ip-xfrm.sed is re-instated, the above line will be deleted. So is that above line important or not? > On Fri, Jan 24, 2020 at 03:56:45PM +0000, Andrew Cagney wrote: > > New commits: > > commit 66e89c481c051c30a2ef0fe2d905702fa4344523 > > Author: Andrew Cagney <cagney at gnu.org> > > Date: Fri Jan 24 10:43:25 2020 -0500 > > > > testing: avoid optional ip-xfrm.sed sanitizer > > > > Let sanitizers such as guest-ip-xfrm-state.sed deal with command > > specific sanitization. > > > > Follow-up e03853f86d6deb1078a59515329ed7cbf136cfad. > > PS: > [1] has iptables SNAT started assigning random ports? > https://www.mail-archive.com/swan-dev@lists.libreswan.org/msg03376.html > _______________________________________________ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev