On Sat, 7 Sep 2019, Andrew Cagney wrote:
Channelling hugh ...
The test results took a recent dive ~130->320 https://testing.libreswan.org/
and a git bisect turned up these
changes:
pluto: in decode_peer_id_counted() isanyid check should also apply to initiator
pluto: decode_peer_id_counted() if we didn't switch connections, confirm ID
wildcard or not
I'm looking into this. Note that a bad debug line caused some of it at
first, but now looking at the next run without that and still seeing a
lot.
The old issue of bad packet counters still plague us with very many
false positives, but these are not the new ones causing the drop.
This one is worrying, who touched the CERT / CRL code?
https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/nss-cert-crl-03-strict/OUTPUT/east.console.diff
It shows new leaks with CRL and issuer's that seem questionable as those
are all end certificates and not CA certificates.
Maybe related:
https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/nss-cert-crl-03-strict/OUTPUT/west.console.diff
I never know whether to trust the CRL/OCSP tests as these tests require
certificates be regenerated before the test run starts.
It seems part of what my above listed commits did was cause this:
https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/newoe-25-cat-5/OUTPUT/road.console.diff
-000 "block": our idtype: ID_IPV4_ADDR; our id=192.1.3.209; their idtype:
%none; their id=(none)
+000 "block": our idtype: ID_IPV4_ADDR; our id=192.1.3.209(with %any); their
idtype: %none; their id=(none)(with %any)
It is a bit misleading here. Anything in the "block" group has
authby=never, so the ID is irrelevant. It is likely better to not
display the entire line for authby=never connections. But if we go
that way, there is a lot more we should never print, like the dpd=
line and others. So for now I suppressed printing the new %any
stuff for NEVER_NEGOTIATE() connections.
Others I see are:
https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/xauth-pluto-20-pam-timeout/OUTPUT/road.console.diff
-002 "xauth-road-eastnet" #2: deleting state (STATE_MAIN_I3) and NOT sending
notification
+002 "xauth-road-eastnet" #2: deleting state (STATE_MAIN_I2) and NOT sending
notification
Another group I see is:
https://testing.libreswan.org/v3.28-761-gbc0ebde9e-master/seccomp-03-updown/OUTPUT/road.console.diff
-004 "westnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.23 #2: STATE_V2_IPSEC_I: IPsec SA
established tunnel mode {ESP/NAT=>0xESPESP <0xESPESP xfrm=AES_GCM_16_256-NONE NATOA=none
NATD=192.1.2.23:4500 DPD=passive}
+002 "westnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.23 #2: IKE SA authentication
request rejected by peer: AUTHENTICATION_FAILED
+000 "westnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.23 #2: scheduling retry
attempt 1 of an unlimited number, but releasing whack
The connection is PSK and I surely caused this with the above commits.
As it shows:
"roadnet-eastnet-ipv4-psk-ikev2"[1] 192.1.2.254 #1: Peer ID '@road' not
suitable for connection 'roadnet-eastnet-ipv4-psk-ikev2'
It should not have done any certificate SAN checking on this since we
did not do CERT payloads at all. I will look at fixing this today.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
