On Wed, 20 Jan 2016, Andrew Cagney wrote:
I'm looking to move the code dealing with INVALID_KE and NO_PROPOSAL_CHOSEN to before the point where the "state" object is allocated. in both cases, since the proposal is dropped on the floor, there's no reason to even start allocating state.
That does assume there is no connection switching that could make things better.
- how critical is the order when it comes to parsing/rejecting packets? Specifically the vendor ID, my glance at the code suggests it doesn't need state so it too can be moved to before state is created?
vendorid information might go onto the state, but that assumes there is a state. For NO_PROPOSAL_CHOSEN or INVALID_KE we would not need it, unless later in life we need to do some workaround based on VID.
- I suspect I can do a quick cheap KE pre-check (is it in any proposal, is the payload valid) before starting on the proposal, is it worth it though? It does mean that INVALID_KE can come from two places
Why two places? Is there a case where you wouldn't know beforehand the KE was wrong, but would find out later? Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
