When picking winning sec, properly filter out the ones we didn't declare about ims HOT 5 CLOSED

Eh, why'd they put sha1/aes at a lower q than sha1/null, especially when md5/aes is first :/

I guess that's enough motivation to support AUTH_HMAC_MD5 as well, that ought to be easy enough. I'll send a patch that supports md5 and picks the right pair

from ims.

martinetd@383ce05 should work better for this particular case; but thinking back this really should have worked: the Security-Server you gave as an example does list sha1/aes-cbc, with all other values (spi/ports) being identical, so while sha1+aes was't the first choice it should be supported...
I guess ultimately we'll have to leave it up to some configuration option e.g. I sure would want to enable aes if there's a valid option that works with aes even if it's not the first choice (the option could be "disallow null encryption" or something simpler than actually selecting alg/ealg though)

I didn't open a PR because your main branch is quite a bit far behind mine (alarm, some cleanup); but patch should apply cleanly if you want to try, and it should select md5/fix key length as you did so that'll probably work

from ims.

from ims.

Nope it shouldn't. The IPSec tunnel that the server prepared is the highest
q that is listed in both Security-Server and Security-Client. The server
doesn't prepare all intersecting variants

Ah, I was about to say we don't send hmac-md5 in our security-client, but you've patched that as well in your branch -- I'll fix that to also offer md5.

Ok so that makes sense, we just need to make the option adjust what is sent in Security-Client when we add one.

from ims.

@phhusson Sorry should have said I updated the commit, please also take martinetd@c862196 (tip of my securityserver branch) for the Security-Client value

from ims.