hi Tobias,<br><br><div class="gmail_quote">On 29 July 2011 15:58, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Hi Patricia,<div class="im"><br>
<br>
> I've tested strongswan-4.5.3rc2 and I still get the same behaviour.<br>
> I'm testing MOBIKE by sending CBR traffic from the initiator at a<br>
> rate of 45Kbps.<br>
><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
When I deactivate eth0 I obtain the behavior that you can see on one.png.<br>
<br>
Then, I activate eth0 again and deactivate eth1 and I obtain the<br>
behaviour showed in two.png (nothing strange).<br>
</blockquote>
<br></div>
Ah, the problem here is not exactly what I described previously and not quite what the patch fixes.  The problem in this situation is that the original IPsec SA covers packets between 163.117.141.82 and 163.117.141.81.  Now, when 163.117.141.82 goes down, there is simply no IPsec SA yet which covers eth1's 163.117.14.33.  MOBIKE has first to determine this as a valid path and then update the SA appropriately. The submitted patch basically fixes this last update step.  So how do you fix it?  Well, you have to make sure that 'left' (the IP address that might change) is not part of the local traffic selector.  To do so I'd recommend you assign your client a virtual IP address.<br>

</blockquote><div><br>I've test also with virtual IP's and I obtain the same behaviour :( <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


<br>
Regards,<br><font color="#888888">
Tobias<br>
<br>
</font></blockquote></div><br>