my recent fixes to ikev2 retransmit exposed an issue. I am working on a fix for the regression. However, I noticed it is only on klips. The root cause is probably worth looking further.
The test newoe-02-klips, road, is using klips stack. It is hitting passert since merge commit 59b1d0. I think I can fix this soon. If I fix it the root cause may go unnoticed. Switch the stack to netkey on road there is no crash. A further look suggest klips does not support AES_GCM? Then why send AES_GCM in proposal as the initiator to the responder. | check_kernel_encrypt_alg(20,256): alg not present in system "private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #2: ESP algo ESP_AES_GCM_C=20 with key_len 256 is not valid (encryption alg not present in kernel) "private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #2: ESP/AH responder AUTH Child proposed/accepted a proposal we don't actually support! http://swantest.libreswan.fi/results/blackswan/2017-06-23-swantest-3.21rc2-142-g4cb3a8b-master/newoe-02-klips/OUTPUT/road.pluto.log Could it be KLIPS does not support ESP_AES_GCM_C? I am not sure yet. If KLIPS suppors it this is something else. Why pluto figure this out late in the negotiation? Shouldn't pluto know as the initiator which ESP algorithms are supported by kernel and send only those in the proposal to the responder? Do we need another ESP default list based klips or netkey:) -antony _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
