<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 28, 2015 at 11:53 PM, 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"><div id=":20y" class="a3s" style="overflow:hidden">tiple auth methods, we'd have to<br>
return all of them (for example using a bit-set), and use these methods<br>
in main/aggressive_mode.c to select the appropriate </div></blockquote></div><br>Hi Martin,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanx for the reply. Yes, I realized from the code that only the auth method in the first transform proposal from the SA payload is returned. Same with the lifetime, which i thought would not matter so much, but a Juniper SRX did not like it either when the lifetime was different from what it had proposed. Sadly, the proposal structures in the ike_cfg_t do not have the auth method in them, so even if i get a list of auth methods from the sa payloads, it was not easy to do a proper match against the proposals in <a href="http://ike_cfg.in">ike_cfg.in</a> the end i ended up putting in a hack to keep the auth method in ike_cfg, based on the connection definition. And when the get_proposals on the sa_payload is done, it will return only those proposals that match the auth method. if no proposal is found, then it does what strongswan currently does. it seems to work for me now, but i hope there is a better solution. </div><div class="gmail_extra">i did something similar for lifetime.</div><div class="gmail_extra"><br></div><div class="gmail_extra">regards,</div><div class="gmail_extra">sk</div></div>