On Sun, 20 Apr 2014, D. Hugh Redelmeier wrote:
I'll say it again, perhaps more clearly:
I'm willing to work on the parsing, but I'd like clear and accurate
explanation of what we (think) the syntax is now. I don't really want
to have to infer it from the code.
It would be great to know what people actually use (i.e. what not to
break). Oh, and what has been documented.
That's the starting point.
The next step would be a proposed rational design.
I have started to add legitimate cases into testing/lib/libpluto/algparse.c
including ones that should get rejected (marked as such)
This should be extended to cover more.
All that is useful, but since I don't know what exists, I don't really
understand what that list means.
Let me emphasize: talking about it is important, especially for
user-visible changes. And accurate documentation needs to be a higher
priority.
Agreed. the man pages _must_ match the implementation, always.
The serious mess of natt-related options ought to be cleaned up too.
Now, while I remember how the option handling works. But first, I
would like to clearly know which options are actually important and
used.
All of them? I'm not sure which you are referring to. The NAT options
were mostly added for people to work around some kind of deployment
issue.
ikev1_natt - work around bugs in RFC NATT implementation in certain Cisco
firmware
nat_keepalive - people on bad links like to disable this (arguably unwise)
(bool, suggested to turn into a time field - see below)
force_keepalive - obsoleted already
nat_traversal - obsoleted already
disable_port_floating - obsoleted already
nat_ikeport - work around UDP 4500 blocks
keep_alive - should become per-connection (talk of merging with nat_keepalive)
virtual_private - required by everyone
I'm still wondering about nat- vis natt-.
In the above the only "natt-" one is ikev1_natt. It specifically refers
to which nat-traversal payloads to send. The rest deals with nat, so
relates to natt. I'm okay with renaming it, although it makes sense as
it. (to me, but I also made the keyword up in the first place)
Paul
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
