| From: Paul Wouters <p...@nohats.ca> | On Sat, 20 Jun 2015, D. Hugh Redelmeier wrote: | | > I'm trying to fix IKEv2's inI2 ourR2 logic (after I broke it). | | What was the effect of the break? Dose this explain our missing packets?
Amusingly, the symptom was UDP packets with no IKE content, just UDP headers / pseudo headers. So: no such luck. It might only be in my tree. I think that we want my tree since it does fix some other problems. I'm trying to test it now (as you might gather from all my whining). | > Confusingly, they seem to both be in STATE_PARENT_R2. That seems wrong. | > Very wrong. | | This has been a known issue and the core of why we need to fix the state | names. I wanted new state names for less important reasons. I had forgotten how bad this is. | Can we get to a temporary state where we do still send the packets | without overhauling the state machine? Oh yeah. Fixed in my tree. Easy, once I understood the Cups and balls game that was going on. <https://en.wikipedia.org/wiki/Cups_and_balls> | > Code after other calls to ikev2_parent_inI2outR2_auth_tail ought to be | > checked. I fixed code after the other call. | > In v1, the st_tpacket logic was used for retransmission. In IKE V2, inI2 | > out R2 is a responder state and will never do any retransmitting. So it | > kind of doesn't matter if the st_tpacket/st_tfrags values persist. Unless | > they are used as IV-like objects (I don't think that they are). | | I don't think so? I'm not sure what you mean with IV-like objects. I | think any kind of IV for IKE is stored in specific st_ variables or | remains within the nss symkeys. Look at the way st_firstpacket_me is used in ikev2_calculate_rsa_sha1 and st_firstpacket_him in ikev2_verify_rsa_sha1 and ikev2_verify_psk_auth. That's "IV-like". | But is this teh cause of the missing packets, or the solution of the | missing packets? I'm completely lost now. It fixes some things. We should know more when testing is done and analyzed. A rocky process. _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
