I looked at xauth-pluto-26 and east seemed to be receiving zero packets so I kicked testing.
On Tue, 5 Mar 2019 at 21:51, Paul Wouters <[email protected]> wrote: > > > I looked at the many slow failures we are seeing for tests that are > supposed to fail to establish a connection. the test harnass now > times out on these, eg: > > https://testing.libreswan.org/v3.27-930-g9df3f69c7-master/ikev2-x509-14-san-dn-mismatch > > The issue is that the last retransmit before we release the hack is at 32s: > > 010 "san" #2: STATE_PARENT_I2: retransmission; will wait 32 seconds for > response > 002 "san" #2: certificate verified OK: > [email protected],CN=east.testing.libreswan.org,OU=Test > Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA > 003 "san" #2: ID_DER_ASN1_DN > '[email protected],CN=east.testing.libreswan.org,OU=Test > Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA' does not match expected > 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, > CN=NOTeast.testing.libreswan.org, [email protected]' > 002 "san" #2: Peer public key SubjectAltName does not match peer ID for this > connection > 002 "san" #2: X509: CERT payload does not match connection ID > 224 "san" #2: STATE_PARENT_I2: v2N_AUTHENTICATION_FAILED > 002 "san" #2: deleting other state #2 (STATE_PARENT_I2) and NOT sending > notification > 002 "san" #1: deleting state (STATE_PARENT_I2) and NOT sending notification > > The 32s is putting us over the 60s wait period in the python expect > code and thus causing the failure. > > The old behaviour was to error after the first AUTH failed: > > 002 "san" #2: Peer public key SubjectAltName does not match peer ID for this > connection > 002 "san" #2: X509: CERT payload does not match connection ID > 224 "san" #2: STATE_PARENT_I2: v2N_AUTHENTICATION_FAILED > 031 "san" #2: STATE_PARENT_I2: 10 second timeout exceeded after 0 > retransmits. Possible authentication failure: no acceptable response to our > first encrypted message > 000 "san" #2: starting keying attempt 2 of an unlimited number, but releasing > whack > west # > > > I the think old behaviour was correct. The AUTH payload failed but not > because of a failure of encryption or integrity. It is simply not > allowed to because it is the wrong IKE ID. There won't be coming a > better answer on this exchange. It is not a forged/bad packet. > > I'll redo a git bisect tomorrow and see why it changed. > > Paul > _______________________________________________ > Swan mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
