<div dir="ltr">Hi Martin,<div><br></div><div>I tested the fix and it works. Thank you for the patch.</div><div>I concur with your explanation above. I think this fix can go into the main branch.</div><div><br></div><div>Thanx,</div>
<div>sach </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 14, 2014 at 2:12 AM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
> In process_r, you check if the informational message is a DELETE<br>
<div class="">> message. Is this necessary? I am concerned that if this message is not<br>
> a delete, but another informational message that the FW sends for<br>
> whatever reason, we return SUCCESS, which would delete this task and<br>
> could lead to the same problem.<br>
<br>
</div>This is the original behavior we had, and I'd like to avoid changing<br>
that if there is no specific reason to do so.<br>
<br>
Unfortunately IKEv1 is not that well standardized that we can predict<br>
the peer behavior. It is actually possible that it indicates Quick mode<br>
failure with such an INFORMATIONAL (where returning SUCCESS is the<br>
correct behavior). It will most likely include a notify payload then,<br>
but not sure if we can rely on that.<br>
<br>
The only non-delete INFORMATIONALs that I can think of at this stage are<br>
DPD checks. These are caught in the task manager and never hit the task,<br>
so should be no problem.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br></div>