From antony at phenome.org Fri Oct 4 18:54:42 2019 From: antony at phenome.org (Antony Antony) Date: Fri, 4 Oct 2019 20:54:42 +0200 Subject: [Swan-dev] comment on version.mk - make rpm Message-ID: <20191004185442.gl4v5tc4fxmp477k@AntonyAntony.local> a minor comment. I noticed a commit to fix version number in "make rpm" https://github.com/libreswan/libreswan/commit/b68c5a33261ea07defa119edee97e4a495588d6c It is good improvement to "make rpm". However, there is another way to set pluto --version, IPSECVERSION=%{IPSECVERSION} https://github.com/libreswan/libreswan/blob/master/packaging/fedora/libreswan-testing.spec#L18 setting IPSECVERSION is also used in Debian and OpenWRT packaging. May be it is better to use this method instead of b68c5a. Having two different ways to set pluto --version is likely to end up in trouble. Copying version.mk is possibly dificult to do in Debian or openwrt. Debian run the make in place and not in seperate directory like ~/rpmbuild/ From paul at nohats.ca Mon Oct 7 13:56:39 2019 From: paul at nohats.ca (Paul Wouters) Date: Mon, 7 Oct 2019 09:56:39 -0400 (EDT) Subject: [Swan-dev] comment on version.mk - make rpm In-Reply-To: <20191004185442.gl4v5tc4fxmp477k@AntonyAntony.local> References: <20191004185442.gl4v5tc4fxmp477k@AntonyAntony.local> Message-ID: On Fri, 4 Oct 2019, Antony Antony wrote: > a minor comment. I noticed a commit to fix version number in "make rpm" > > https://github.com/libreswan/libreswan/commit/b68c5a33261ea07defa119edee97e4a495588d6c > > It is good improvement to "make rpm". > > However, there is another way to set pluto --version, > IPSECVERSION=%{IPSECVERSION} > https://github.com/libreswan/libreswan/blob/master/packaging/fedora/libreswan-testing.spec#L18 > > setting IPSECVERSION is also used in Debian and OpenWRT packaging. May be it > is better to use this method instead of b68c5a. People often re-use spec files by grabbing their existing one and only changing the Version: and Release: fields. When you install a SRPM and the spec file goes into ~/rpmbuild/SPECS, you do not remember the origin of that spec file. So you might not be aware that you would need to change Version:, Release: _and_ IPSECVERSION. Having two independent version-like options in the spec file that can contradict each other seems dangerous, and I wanted to avoid people creating a "3.31" tarball that still has IPSECVERSION=3.30 hardcoded in the spec file, which will misidentify as 3.30 instead of 3.31. And if ipsec version and rpm -q libreswan contradict each other, which one do you believe? Paul From andrew.cagney at gmail.com Tue Oct 8 15:32:59 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Tue, 8 Oct 2019 11:32:59 -0400 Subject: [Swan-dev] what is 192.0.3.254:1/8 Message-ID: as in: find_connection: looking for policy for connection: 192.0.3.254:1/8 -> 192.0.2.254:1/0 perhaps this helps (or confuses)? subnet from endpoint 192.0.3.254:8 (in netlink_acquire() at kernel_netlink.c:1782) add bare shunt 0x7f943c3fdf78 192.0.3.254/32:8 --1--> 192.0.2.254/32:0 => %hold 0 %acquire-netlink since this is happening when an acquire is triggered by a ping packet, 1 is maybe ICMP and 8 is something found in the acquire's .sport field (but what?) Two problems: - the syntax is terrible: :1 isn't a port, /8 isn't a mask - even 192.0.3.254:(1/8) would be better - there's a subnet kicking round with a bogus port 8, does it get scrubbed, or do we get away with this because the IKEv2 TS code is instead looking at end.port and that's zero ... From paul at nohats.ca Wed Oct 9 04:36:54 2019 From: paul at nohats.ca (Paul Wouters) Date: Wed, 9 Oct 2019 00:36:54 -0400 (EDT) Subject: [Swan-dev] what is 192.0.3.254:1/8 In-Reply-To: References: Message-ID: On Tue, 8 Oct 2019, Andrew Cagney wrote: > find_connection: looking for policy for connection: 192.0.3.254:1/8 > -> 192.0.2.254:1/0 > > perhaps this helps (or confuses)? Yes, it is the encoding of types/subtypes into ports as per https://tools.ietf.org/html/rfc7296#section-3.13.1 > subnet from endpoint 192.0.3.254:8 (in netlink_acquire() at > kernel_netlink.c:1782) > add bare shunt 0x7f943c3fdf78 192.0.3.254/32:8 --1--> > 192.0.2.254/32:0 => %hold 0 %acquire-netlink > > since this is happening when an acquire is triggered by a ping packet, > 1 is maybe ICMP and 8 is something found in the acquire's .sport > field (but what?) > > Two problems: > > - the syntax is terrible: :1 isn't a port, /8 isn't a mask - even > 192.0.3.254:(1/8) would be better I guess ideally it would be: 192.0.3.254/32 --1/8--> 192.0.2.254/32:0 > - there's a subnet kicking round with a bogus port 8, does it get > scrubbed, or do we get away with this because the IKEv2 TS code is > instead looking at end.port and that's zero ... It might get wiped in the "broadening" of the shunt. And it cannot work without broadening, because you cannot have a narrowed policy for only 1/8 (well it makes no sense, you could only send pings but not ping replies). The widening for proto 1 should probably be 1/0 (eg no sub-types) Paul From andrew.cagney at gmail.com Wed Oct 9 20:46:10 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Wed, 9 Oct 2019 16:46:10 -0400 Subject: [Swan-dev] what is 192.0.3.254:1/8 In-Reply-To: References: Message-ID: On Wed, 9 Oct 2019 at 00:37, Paul Wouters wrote: > > On Tue, 8 Oct 2019, Andrew Cagney wrote: > > > find_connection: looking for policy for connection: 192.0.3.254:1/8 > > -> 192.0.2.254:1/0 > > > > perhaps this helps (or confuses)? > > Yes, it is the encoding of types/subtypes into ports as per https://tools.ietf.org/html/rfc7296#section-3.13.1 Ah, so xfrm is following the model put forward in the RFC. > > subnet from endpoint 192.0.3.254:8 (in netlink_acquire() at > > kernel_netlink.c:1782) > > add bare shunt 0x7f943c3fdf78 192.0.3.254/32:8 --1--> > > 192.0.2.254/32:0 => %hold 0 %acquire-netlink > > > > since this is happening when an acquire is triggered by a ping packet, > > 1 is maybe ICMP and 8 is something found in the acquire's .sport > > field (but what?) > > > > Two problems: > > > > - the syntax is terrible: :1 isn't a port, /8 isn't a mask - even > > 192.0.3.254:(1/8) would be better > > I guess ideally it would be: 192.0.3.254/32 --1/8--> 192.0.2.254/32:0 192.0.3.254/32 --ICMP.PING--> 192.0.2.254/32:0 although this doesn't help the log line: subnet from endpoint 192.0.3.254:8 (in netlink_acquire() at kernel_netlink.c:1782) but I suspect here the problem is that the code's abusing ip_subnet so that record_and_initiate_opportunistic() signature doesn't need to be changed > > - there's a subnet kicking round with a bogus port 8, does it get > > scrubbed, or do we get away with this because the IKEv2 TS code is > > instead looking at end.port and that's zero ... > > It might get wiped in the "broadening" of the shunt. And it cannot work > without broadening, because you cannot have a narrowed policy for only > 1/8 (well it makes no sense, you could only send pings but not ping > replies). The widening for proto 1 should probably be 1/0 (eg no > sub-types) > > Paul From andrew.cagney at gmail.com Wed Oct 9 21:09:47 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Wed, 9 Oct 2019 17:09:47 -0400 Subject: [Swan-dev] testing: check/ip/ipcheck.h fix spelling and grammatical error In-Reply-To: <46pQ4331jWz7Yr6h@vault.libreswan.fi> References: <46pQ4331jWz7Yr6h@vault.libreswan.fi> Message-ID: On Wed, 9 Oct 2019 at 15:57, D. Hugh Redelmeier wrote: > > New commits: > commit 1d22c5a11acfbee75f996c2a750677109c0362ab > Author: D. Hugh Redelmeier > Date: Wed Oct 9 15:55:26 2019 -0400 > > testing: check/ip/ipcheck.h fix spelling and grammatical error > > Note: none of these messages shows up in a test reference log so I > guess that the testing isn't comprehensive. I sure hope that none of those messages show up - they're all failures! check-01 invokes the tests as: ipsec ipcheck > /dev/null || echo error so any text appearing on stderr triggers a failure (the content of the text doesn't matter just that there is some). This is proving far more workable than enumcheck and some other tests that do use reference output - since no one seems to update or read it Andrew From andrew.cagney at gmail.com Fri Oct 11 15:50:35 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 11 Oct 2019 11:50:35 -0400 Subject: [Swan-dev] can shunk_t (string chunk) be merged into chunk_t (byte chunk) In-Reply-To: References: Message-ID: On Mon, 21 Jan 2019 at 13:40, Andrew Cagney wrote: > > This came up in an offline discussion. While chunk_t is intended for > bytes and shunk_t is intended for characters, they do both provide > pointer+length abstractions. This begs the question: should they be > merged? It turns out that they have a critical difference: The code has evolved: - rather than having duplication, operations that work equally on chunk(rw) or shunk(ro) are being merged into hunk_*(), for instance: hunk_streq(chunk, "a string") hunk_streq(shunk, "a string") - shunk_t is no longer string (const char *) centric - it's .ptr type was changed to 'const void *'; this means code needs an explicit and local conversion of .ptr (I find that makes things more readable as there's no question as to the type/sign of the data);I think new chunk_t code should follow this lead (and existing code shouldn't have explicit .ptr casts stripped out) - code uses functions with 'void *' and/or 'const void *' parameters and type<->void conversion, and not macros with casts; the latter suppresses const conversion warnings So circling back to the name. I find the 'c' in chunk_t really unfortunate - c[onstant]hunk_t, c[har]hunk_t. I guess chunk_t / shunk_t should have been called rw_hunk_t / ro_hunk_t; oops. > - chunk_t points at writable data but shunk_t points at read-only data > > so I'd argue no. For instance, a construct like: > > const char string[4] = { 'H', 'e', 'l', 'p', }; > shunk_t s = { .ptr = string, .len = sizeof(string), }; > > is valid (unlike strspn() et.al., shunks don't assume NUL > termination), where as: > > chunk_t c = { .ptr = (uint8_t*) string, .len = sizeof(string), }; > > is not. > > What might useful are: > > - think of a better name - string_t would be terrible, slice_t might be better > - change .ptr to 'const uint8_t*', but that would break things like > .ptr = "a string" :-( > > Andrew From andrew.cagney at gmail.com Fri Oct 11 17:36:21 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 11 Oct 2019 13:36:21 -0400 Subject: [Swan-dev] new log file check - ISCNTRL (and the sadness that is python's RE) Message-ID: I've added checks for control characters in both pluto.log and console.txt, the'll show up as ISCNTRL. (Pluto, when debug-logging was spewing an ECDSA structure that contained raw bytes - that structure should have contained printable ASCII). The bad news is that kvmresults.py gets slower again. Superficially, it's because I simply added a new regex call to a growing list - the code looks like: if re.match(buffer, "(null)"): add PRINTF_NULL if re.match(buffer, "[^ -~\n]"): add ISCNTRL and as everyone knows the correct way to right this is more like: if re.match(buffer, "(null)|[^ -~\n]")): which lets the RE generate a really fast DFA, just like grep. I've even got a patch to do this (should revisit it, it also plays with the "re" alternative "regex") But here's where things get sad - it's slower than the above. It turns out that Python's RE has an optimization where it will use a low level string search to match things like "(null)" and that's faster than the high-level DFA :-( From hugh at mimosa.com Sun Oct 13 15:04:12 2019 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sun, 13 Oct 2019 11:04:12 -0400 (EDT) Subject: [Swan-dev] ip_range Message-ID: The ip_range type seems to be used for two purposes: - traffic selectors - ip address pools The two uses have diverged. Lots of complexity has been added for the address pool case which is not clearly correct or useful for the traffic selector case. Is there an RFC-based limit on range sizes for traffic selectors? If so, that should be enforced (i.e. violation should be failure, not truncation). If not, we should not trunctate them. For address pools, I think that we get to set the rules. It seems to me that 2^32 is large enough. That's what our code supports. Why not treat a larger size as an actual error rather than truncating to specified range? Then a lot of truncation logic goes away. Clearly this limit must be spelled out in the documentation (perhaps it is -- I haven't looked). The routines that currently do truncation don't know whether they are dealing with a traffic selector or an address pool. I suggest that the old ip_range type be reinstated and that a new type, perhaps "pool_range", be added with the new features. The pool_range type could be composed of an ip_range and some additions. Among other things, this would allow improved modularization and better diagnostics. From hugh at mimosa.com Sun Oct 13 15:42:07 2019 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sun, 13 Oct 2019 11:42:07 -0400 (EDT) Subject: [Swan-dev] proposal: "const struct ip_protocol" => "ip_protocol" Message-ID: We currently have struct ip_protocol {...}; As far as I can tell, all uses of it are of the form const struct ip_protocol Why not typedef const struct {...} ip_protocol; Then all uses should be changed appropriately (a sed script would do it). That way the "const" could not be left off accidentally, the code becomes more concise, easier to fit on a line, easier to type, easier to read ("chunking"), etc. More importantly, I think that the code becomes easier to think about -- the power of abstraction. BETTER: Almost all uses would be of the form ip_protocol * If instead, we define: struct ip_protocol {...}; typedef const struct *ip_protocol; then the table initialization can use "const struct ip_protocol" and all other uses get to eliminate the *. This should make the use even simpler and less error prone. A better abstraction all around. This change might not be a simple sed operation (I haven't checked) but it should be easy to do it without introducing errors. I propose to make this change if there are no serious objections. It should be done when most code is at rest. Can people tell me if they have code in-flight that would be affected? Practical detail: We can make the transition "hard" by naming the struct differently (perhaps "ip_protocol_"). That way unconverted code would fail to compile. That would be my preference. Perhaps an initial soft transition would be easier. Then we could switch to hard after we think all in-flight code has landed. From andrew.cagney at gmail.com Sun Oct 13 16:43:33 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sun, 13 Oct 2019 12:43:33 -0400 Subject: [Swan-dev] proposal: "const struct ip_protocol" => "ip_protocol" In-Reply-To: References: Message-ID: for const: because it gets confusing and is obscure; better to spell out: const something where the code is being used than leave everyone wondering, for instance, given: ip_something(something *foo, const someotherthing *bar, somethingelse *baz); which are typos and which are correct? imnsho field_desc et.al., being made typedef const struct were a massive mistake for struct something vs typedef something; kernel guidelines say don't use typedefs; we've modified that to say "typedef" denotes stay-out but here we're saying welcome aboard On Sun, 13 Oct 2019 at 11:42, D. Hugh Redelmeier wrote: > > We currently have > struct ip_protocol {...}; > > As far as I can tell, all uses of it are of the form > const struct ip_protocol > > Why not > typedef const struct {...} ip_protocol; > > Then all uses should be changed appropriately (a sed script would do it). > > That way the "const" could not be left off accidentally, the code becomes > more concise, easier to fit on a line, easier to type, easier to read > ("chunking"), etc. More importantly, I think that the code becomes easier > to think about -- the power of abstraction. > > BETTER: > > Almost all uses would be of the form > ip_protocol * > > If instead, we define: > struct ip_protocol {...}; > typedef const struct *ip_protocol; > > then the table initialization can use "const struct ip_protocol" and all > other uses get to eliminate the *. This should make the use even simpler > and less error prone. A better abstraction all around. > > This change might not be a simple sed operation (I haven't checked) but it > should be easy to do it without introducing errors. > > I propose to make this change if there are no serious objections. > > It should be done when most code is at rest. Can people tell me if they > have code in-flight that would be affected? > > Practical detail: > > We can make the transition "hard" by naming the struct differently > (perhaps "ip_protocol_"). That way unconverted code would fail to > compile. That would be my preference. > > Perhaps an initial soft transition would be easier. Then we could switch > to hard after we think all in-flight code has landed. > _______________________________________________ > Swan-dev mailing list > Swan-dev at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev From andrew.cagney at gmail.com Sun Oct 13 16:49:59 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sun, 13 Oct 2019 12:49:59 -0400 Subject: [Swan-dev] ip_range In-Reply-To: References: Message-ID: On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier wrote: > > The ip_range type seems to be used for two purposes: > > - traffic selectors The (ikev2) traffic selector code outputs an ip_subnet, not an ip_range Internally it just happens to use an ip_range as part of the journey towards a subnet. Like the comment points out: /* * This is not the subnet you're looking for. * * In libreswan ip_subnet is used to store client routing information. * IKEv2 calls this traffic selectors and it allows the negotiation * of: * * LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT * * The structures below can only handle a limited subset of this, * namely: * * NETWORK_PREFIX | 0 / MASK : PORT * * where PORT==0 imples 0..65535, and (presumably) port can only be * non-zero when the NETWORK_PREFIX/MASK is for a single address. */ > - ip address pools > > The two uses have diverged. Lots of complexity has been added for the > address pool case which is not clearly correct or useful for the traffic > selector case. > > Is there an RFC-based limit on range sizes for traffic selectors? > If so, that should be enforced (i.e. violation should be failure, > not truncation). If not, we should not trunctate them. > > For address pools, I think that we get to set the rules. It seems to > me that 2^32 is large enough. That's what our code supports. Why not > treat a larger size as an actual error rather than truncating to > specified range? Then a lot of truncation logic goes away. Clearly > this limit must be spelled out in the documentation (perhaps it is -- > I haven't looked). This is what Antony did. > The routines that currently do truncation don't know whether they are > dealing with a traffic selector or an address pool. > > I suggest that the old ip_range type be reinstated and that a new type, > perhaps "pool_range", be added with the new features. > > The pool_range type could be composed of an ip_range and some additions. > > Among other things, this would allow improved modularization and > better diagnostics. > _______________________________________________ > Swan-dev mailing list > Swan-dev at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev From andrew.cagney at gmail.com Sun Oct 13 17:18:29 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sun, 13 Oct 2019 13:18:29 -0400 Subject: [Swan-dev] ip_range In-Reply-To: References: Message-ID: PS: Moving the size logic out of ttorange() and into a function vis: bool range_size(const ip_range *range, uintmax_t *staturated_size) MUST_USE_RESULT /* false if overflow */ (same for converse range+offset) I think does have merit. Andrew On Sun, 13 Oct 2019 at 12:49, Andrew Cagney wrote: > > On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier wrote: > > > > The ip_range type seems to be used for two purposes: > > > > - traffic selectors > > The (ikev2) traffic selector code outputs an ip_subnet, not an > ip_range Internally it just happens to use an ip_range as part of the > journey towards a subnet. Like the comment points out: > > /* > * This is not the subnet you're looking for. > * > * In libreswan ip_subnet is used to store client routing information. > * IKEv2 calls this traffic selectors and it allows the negotiation > * of: > * > * LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT > * > * The structures below can only handle a limited subset of this, > * namely: > * > * NETWORK_PREFIX | 0 / MASK : PORT > * > * where PORT==0 imples 0..65535, and (presumably) port can only be > * non-zero when the NETWORK_PREFIX/MASK is for a single address. > */ > > > > > - ip address pools > > > > The two uses have diverged. Lots of complexity has been added for the > > address pool case which is not clearly correct or useful for the traffic > > selector case. > > > > Is there an RFC-based limit on range sizes for traffic selectors? > > If so, that should be enforced (i.e. violation should be failure, > > not truncation). If not, we should not trunctate them. > > > > For address pools, I think that we get to set the rules. It seems to > > me that 2^32 is large enough. That's what our code supports. Why not > > treat a larger size as an actual error rather than truncating to > > specified range? Then a lot of truncation logic goes away. Clearly > > this limit must be spelled out in the documentation (perhaps it is -- > > I haven't looked). > > This is what Antony did. > > > The routines that currently do truncation don't know whether they are > > dealing with a traffic selector or an address pool. > > > > I suggest that the old ip_range type be reinstated and that a new type, > > perhaps "pool_range", be added with the new features. > > > > The pool_range type could be composed of an ip_range and some additions. > > > > Among other things, this would allow improved modularization and > > better diagnostics. > > _______________________________________________ > > Swan-dev mailing list > > Swan-dev at lists.libreswan.org > > https://lists.libreswan.org/mailman/listinfo/swan-dev From hugh at mimosa.com Sun Oct 13 17:29:09 2019 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sun, 13 Oct 2019 13:29:09 -0400 (EDT) Subject: [Swan-dev] proposal: "const struct ip_protocol" => "ip_protocol" In-Reply-To: References: Message-ID: | From: Andrew Cagney | because it gets confusing and is obscure; better to spell out: | const something | where the code is being used than leave everyone wondering, for instance, given: | ip_something(something *foo, const someotherthing *bar, somethingelse *baz); | which are typos and which are correct? imnsho field_desc et.al., | being made typedef const struct were a massive mistake Clearly I disagree (since I created most of them). Why is it a mistake? Confusing and obscure? No use should be without the const, so make it built-in. The const is part of the abstraction. The "const" is something you should not have to think about separately at each use of the abstraction. If I remember correctly, the C const qualifier is now idempotent so adding a redundant one doesn't generate a compiler error. | for struct something vs typedef something; | kernel guidelines say don't use typedefs; we've modified that to say | "typedef" denotes stay-out but here we're saying welcome aboard We don't use kernel guidelines except for formatting. This isn't kernel code. I don't know what you mean by "stay-out" vs. "welcome aboard". Very very roughly, struct meant: structuring data transparently, typedef meant: an abstraction (with varying transparency). From andrew.cagney at gmail.com Mon Oct 14 03:07:36 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sun, 13 Oct 2019 23:07:36 -0400 Subject: [Swan-dev] proposal: "const struct ip_protocol" => "ip_protocol" In-Reply-To: References: Message-ID: On Sun, 13 Oct 2019 at 13:29, D. Hugh Redelmeier wrote: > > | From: Andrew Cagney > > | because it gets confusing and is obscure; better to spell out: > | const something > | where the code is being used than leave everyone wondering, for instance, given: > | ip_something(something *foo, const someotherthing *bar, somethingelse *baz); > | which are typos and which are correct? imnsho field_desc et.al., > | being made typedef const struct were a massive mistake > > Clearly I disagree (since I created most of them). > Why is it a mistake? Confusing and obscure? No use should be without > the const, so make it built-in. The const is part of the abstraction. > The "const" is something you should not have to think about separately > at each use of the abstraction. Two are separate, lets keep them that way: - how the object is constructed Forcing const on the type takes away any flexibility - this week the structure may have a static initializer, next week who can say - how the object is used Functions spell out that a parameter is being "read only" by adding const modern languages try to use things like "final" to differentiate between these. We don't have that, we have "const" so instead we get to put "const" on parameters > If I remember correctly, the C const qualifier is now idempotent so > adding a redundant one doesn't generate a compiler error. Except you'll insist on removing them: commit 6eca8ba46cd7954c7113db7b789d3002f30f8963 Author: D. Hugh Redelmeier Date: Mon Sep 14 23:17:53 2015 -0400 pluto: sprinkle const on struct spd_route and related tidying [...] - remove redundant const from struct_desc objects only to then find, on the next iteration, that they can't be const so we get to put them back. Or we end up with the tacky workarounds like this: include/constants.h:typedef const struct enum_names enum_names; include/constants.h:typedef const struct enum_enum_names enum_enum_names; include/constants.h:typedef const struct sparse_name sparse_names[]; suck it up, drop the typedef, it's a struct. From antony at phenome.org Mon Oct 14 09:44:14 2019 From: antony at phenome.org (Antony Antony) Date: Mon, 14 Oct 2019 11:44:14 +0200 Subject: [Swan-dev] ip_range In-Reply-To: References: Message-ID: <20191014094414.sftvlyjcjy47lp6r@AntonyAntony.local> On Sun, Oct 13, 2019 at 01:18:29PM -0400, Andrew Cagney wrote: > PS: > > Moving the size logic out of ttorange() and into a function vis: agree. Though I want to recored is_subet (with /) or a range (with - ) inside the ttorange. That is important for jam_range. > bool range_size(const ip_range *range, uintmax_t *staturated_size) > MUST_USE_RESULT /* false if overflow */ > > (same for converse range+offset) I think does have merit. I have the similar idea. If the offset is variable lease the address could begin closer to the prefix boundry. > On Sun, 13 Oct 2019 at 12:49, Andrew Cagney wrote: > > > > On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier wrote: > > > > > > The ip_range type seems to be used for two purposes: > > > > > > - traffic selectors > > > > The (ikev2) traffic selector code outputs an ip_subnet, not an > > ip_range Internally it just happens to use an ip_range as part of the > > journey towards a subnet. Like the comment points out: in ikev2 traffic selectors it is a transient use. I tempted to leave ip_range the same for now. Your next argument is more convincing. See bellow. > > /* > > * This is not the subnet you're looking for. > > * > > * In libreswan ip_subnet is used to store client routing information. > > * IKEv2 calls this traffic selectors and it allows the negotiation > > * of: > > * > > * LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT > > * > > * The structures below can only handle a limited subset of this, > > * namely: > > * > > * NETWORK_PREFIX | 0 / MASK : PORT > > * > > * where PORT==0 imples 0..65535, and (presumably) port can only be > > * non-zero when the NETWORK_PREFIX/MASK is for a single address. > > */ > > > > > > > > > - ip address pools > > > > > > The two uses have diverged. Lots of complexity has been added for the > > > address pool case which is not clearly correct or useful for the traffic > > > selector case. > > > > > > Is there an RFC-based limit on range sizes for traffic selectors? > > > If so, that should be enforced (i.e. violation should be failure, > > > not truncation). If not, we should not trunctate them. no. I don't think so. Libreswan and linux kernel currenly only accept a subnet. I herd a Kernel developer, Stefeen, mumbling add kernel support for range because in RFC IP and port are ranges. > > > > > > For address pools, I think that we get to set the rules. It seems to > > > me that 2^32 is large enough. That's what our code supports. Why not > > > treat a larger size as an actual error rather than truncating to > > > specified range? Then a lot of truncation logic goes away. Clearly > > > this limit must be spelled out in the documentation (perhaps it is -- > > > I haven't looked). > > > > This is what Antony did. Yes. However, there is convience factor in accepting smaller prefixes say /64, even upto /32 and for testing purposes /1; even though size is truncated to to 2^32-1. > > > The routines that currently do truncation don't know whether they are > > > dealing with a traffic selector or an address pool. > > > > > > I suggest that the old ip_range type be reinstated and that a new type, > > > perhaps "pool_range", be added with the new features. > > > > > > The pool_range type could be composed of an ip_range and some additions. > > > sure. sounds good to me. I don't have a preference. I guess I will move the .size to ip_pool and size computation a funcation as Andrew suggest. > > > Among other things, this would allow improved modularization and > > > better diagnostics. -antony From andrew.cagney at gmail.com Mon Oct 14 13:33:22 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 14 Oct 2019 09:33:22 -0400 Subject: [Swan-dev] ip_range In-Reply-To: <20191014094414.sftvlyjcjy47lp6r@AntonyAntony.local> References: <20191014094414.sftvlyjcjy47lp6r@AntonyAntony.local> Message-ID: On Mon, 14 Oct 2019 at 05:44, Antony Antony wrote: > > On Sun, Oct 13, 2019 at 01:18:29PM -0400, Andrew Cagney wrote: > > PS: > > > > Moving the size logic out of ttorange() and into a function vis: > > agree. Though I want to recored is_subet (with /) or a range (with > - ) inside the ttorange. That is important for jam_range. Yes, the two are unrelated. Like your comment says, it's just a hint to jam_range(). Once size and "overflow" are turned into a function (which makes them robust - redundancy in these structures has proven dangerous) we've no need for a new type. Least of all one that only address-pool might need. > > bool range_size(const ip_range *range, uintmax_t *staturated_size) > > MUST_USE_RESULT /* false if overflow */ > > > > (same for converse range+offset) I think does have merit. > > I have the similar idea. If the offset is variable lease the address could > begin closer to the prefix boundry. > > > > On Sun, 13 Oct 2019 at 12:49, Andrew Cagney wrote: > > > > > > On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier wrote: > > > > > > > > The ip_range type seems to be used for two purposes: > > > > > > > > - traffic selectors > > > > > > The (ikev2) traffic selector code outputs an ip_subnet, not an > > > ip_range Internally it just happens to use an ip_range as part of the > > > journey towards a subnet. Like the comment points out: > > in ikev2 traffic selectors it is a transient use. I tempted to leave > ip_range the same for now. Your next argument is more convincing. See > bellow. > > > > /* > > > * This is not the subnet you're looking for. > > > * > > > * In libreswan ip_subnet is used to store client routing information. > > > * IKEv2 calls this traffic selectors and it allows the negotiation > > > * of: > > > * > > > * LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT > > > * > > > * The structures below can only handle a limited subset of this, > > > * namely: > > > * > > > * NETWORK_PREFIX | 0 / MASK : PORT > > > * > > > * where PORT==0 imples 0..65535, and (presumably) port can only be > > > * non-zero when the NETWORK_PREFIX/MASK is for a single address. > > > */ > > > > > > > > > > > > > - ip address pools > > > > > > > > The two uses have diverged. Lots of complexity has been added for the > > > > address pool case which is not clearly correct or useful for the traffic > > > > selector case. > > > > > > > > Is there an RFC-based limit on range sizes for traffic selectors? > > > > If so, that should be enforced (i.e. violation should be failure, > > > > not truncation). If not, we should not trunctate them. > > no. I don't think so. Libreswan and linux kernel currenly only accept a > subnet. I herd a Kernel developer, Stefeen, mumbling add kernel support for > range because in RFC IP and port are ranges. > > > > > > > > > For address pools, I think that we get to set the rules. It seems to > > > > me that 2^32 is large enough. That's what our code supports. Why not > > > > treat a larger size as an actual error rather than truncating to > > > > specified range? Then a lot of truncation logic goes away. Clearly > > > > this limit must be spelled out in the documentation (perhaps it is -- > > > > I haven't looked). > > > > > > This is what Antony did. > > Yes. > > However, there is convience factor in accepting smaller prefixes say /64, > even upto /32 and for testing purposes /1; even though size is truncated to > to 2^32-1. Right. The only thing that uses size is the address pool. It doesn't need to be in ip_range, and there doesn't need to be a new type. > > > > The routines that currently do truncation don't know whether they are > > > > dealing with a traffic selector or an address pool. > > > > > > > > I suggest that the old ip_range type be reinstated and that a new type, > > > > perhaps "pool_range", be added with the new features. > > > > > > > > The pool_range type could be composed of an ip_range and some additions. > > > > > > sure. sounds good to me. I don't have a preference. I guess I will move the > .size to ip_pool and size computation a funcation as Andrew suggest. > > > > > Among other things, this would allow improved modularization and > > > > better diagnostics. > > -antony > _______________________________________________ > Swan-dev mailing list > Swan-dev at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev From andrew.cagney at gmail.com Sat Oct 26 14:01:26 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sat, 26 Oct 2019 10:01:26 -0400 Subject: [Swan-dev] strange time time death in nss-cert-09-notyetvalid-initiator-ikev2 Message-ID: One of my test environments was failing in nss-cert-09-notyetvalid-initiator-ikev2, yet not testing.libreswan.org and not other environments. The command being run is: faketime -f +370d ipsec pluto --config /etc/ipsec.conf and pluto.log contains the totally unhelpful: [...] Initializing libevent in pthreads mode: headers: 2.1.8-stable (2010800); library: 2.1.8-stable (2010800) | libevent_malloc: new ptr-libevent at 0x7f1f55e5afd0 size 40 | libevent_malloc: new ptr-libevent at 0x7f1f55e5cfd0 size 40 | libevent_malloc: new ptr-libevent at 0x7f1f55e5efd0 size 40 | creating event base | libevent_malloc: new ptr-libevent at 0x7f1f55e60fc0 size 56 | libevent_malloc: new ptr-libevent at 0x7f1f55e62d60 size 664 with the help of ftrace -f I turned up: write(3, "| libevent_malloc: new ptr-libev"..., 60) = 60 getuid() = 0 geteuid() = 0 getgid() = 0 getegid() = 0 fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0 ioctl(1, TCGETS, 0x7ffc9c7672a0) = -1 ENOTTY (Inappropriate ioctl for device) munmap(0x7f1f58f13000, 8) = 0 munmap(0x7f1f59149000, 32) = 0 write(1, "Invalid clock_id for clock_getti"..., 37) = -1 EBADF (Bad file descriptor) exit_group(1) = ? +++ exited with 1 +++ (END) any ideas? (as an aside, the message didn't make it to the log file; wonder where FD-1 is pointing; and we currently have problems getting early log messages out) From andrew.cagney at gmail.com Sat Oct 26 14:35:49 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sat, 26 Oct 2019 10:35:49 -0400 Subject: [Swan-dev] strange time time death in nss-cert-09-notyetvalid-initiator-ikev2 In-Reply-To: References: Message-ID: Grrr, Updating the VMs made the problem go away. (this just leaves the problem of logging going missing) Andrew On Sat, 26 Oct 2019 at 10:01, Andrew Cagney wrote: > > One of my test environments was failing in > nss-cert-09-notyetvalid-initiator-ikev2, yet not testing.libreswan.org > and not other environments. The command being run is: > > faketime -f +370d ipsec pluto --config /etc/ipsec.conf > > and pluto.log contains the totally unhelpful: > > [...] > Initializing libevent in pthreads mode: headers: 2.1.8-stable > (2010800); library: 2.1.8-stable (2010800) > | libevent_malloc: new ptr-libevent at 0x7f1f55e5afd0 size 40 > | libevent_malloc: new ptr-libevent at 0x7f1f55e5cfd0 size 40 > | libevent_malloc: new ptr-libevent at 0x7f1f55e5efd0 size 40 > | creating event base > | libevent_malloc: new ptr-libevent at 0x7f1f55e60fc0 size 56 > | libevent_malloc: new ptr-libevent at 0x7f1f55e62d60 size 664 > > with the help of ftrace -f I turned up: > > write(3, "| libevent_malloc: new ptr-libev"..., 60) = 60 > getuid() = 0 > geteuid() = 0 > getgid() = 0 > getegid() = 0 > fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0 > ioctl(1, TCGETS, 0x7ffc9c7672a0) = -1 ENOTTY (Inappropriate > ioctl for device) > munmap(0x7f1f58f13000, 8) = 0 > munmap(0x7f1f59149000, 32) = 0 > write(1, "Invalid clock_id for clock_getti"..., 37) = -1 EBADF (Bad > file descriptor) > exit_group(1) = ? > +++ exited with 1 +++ > (END) > > any ideas? > > (as an aside, the message didn't make it to the log file; wonder where > FD-1 is pointing; and we currently have problems getting early log > messages out) From andrew.cagney at gmail.com Tue Oct 29 21:08:32 2019 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Tue, 29 Oct 2019 17:08:32 -0400 Subject: [Swan-dev] ikev2-mobike-03: road.pluto.log: ABORT: ASSERTION FAILED: sr->eroute_owner == SOS_NOBODY (in delete_states_by_connection() at state.c:1382) Message-ID: Toumo and I brainstormed this a bit as Toumo was seeing it on his laptop. During shutdown, while it is trying to delete everything, it panics in delete_states_by_connection() where: -- it deletes all states associated with a connection (the log shows it deleting both the child and parent): foreach_state_by_connection_func_delete(c, relations ? same_phase1_sa_relations : same_phase1_sa); -- checks that, with the states all gone, there's no lingering route: const struct spd_route *sr; for (sr = &c->spd; sr != NULL; sr = sr->spd_next) { passert(sr->eroute_owner == SOS_NOBODY); passert(sr->routing != RT_ROUTED_TUNNEL); } except there is - hooking up a debugger shows sr->eroute_owner == CHILD_SA so for some reason deleting the child didn't delete the route ... Looking back through the logs, the interesting thing seems to be: | XFRM RTM_DELADDR 192.1.33.222 IFA_LOCAL | FOR_EACH_STATE_... in record_deladdr (for_each_state) | start processing: state #2 connection "road-eastnet"[1] 192.1.2.23 from 192.1.2.23:500 (in for_each_state() at state.c:1570) | stop processing: state #2 connection "road-eastnet"[1] 192.1.2.23 from 192.1.2.23:500 (in for_each_state() at state.c:1572) | start processing: state #1 connection "road-eastnet"[1] 192.1.2.23 from 192.1.2.23:500 (in for_each_state() at state.c:1570) | FOR_EACH_CONNECTION_... in route_owner | conn road-eastnet mark 0/00000000, 0/00000000 vs | conn road-eastnet mark 0/00000000, 0/00000000 | conn road-eastnet mark 0/00000000, 0/00000000 vs | conn road-eastnet mark 0/00000000, 0/00000000 | route owner of "road-eastnet"[1] 192.1.2.23 unrouted: NULL | running updown command "ipsec _updown" for verb down | command executing down-client | executing down-client: PLUTO_VERB='down-client' PLUTO_VERSION='2.0' PLUTO_CONNECTION='road-eastnet' PLUTO_INTERFACE='eth0' PLUTO_NEXT_HOP='192.1.33.254' PLUTO_ME='192.1.33.222' PLUTO_MY_ID='192.1.3.209' PLUTO_MY_CLIENT='192.0.3.10/32' PLUTO_MY_CLIENT_NET='192.0.3.10' PLUTO_MY_CLIENT_MASK='255.255.255.255' PLUTO_MY_PORT='0' PLUTO_MY_PROTOCOL='0' PLUTO_SA_REQID='16392' PLUTO_SA_TYPE='ESP' PLUTO_PEER='192.1.2.23' PLUTO_PEER_ID='192.1.2.23' PLUTO_PEER_CLIENT='192.0.2.0/24' PLUTO_PEER_CLIENT_NET='192.0.2.0' PLUTO_PEER_CLIENT_MASK='255.255.255.0' PLUTO_PEER_PORT='0' PLUTO_PEER_PROTOCOL='0' PLUTO_PEER_CA='' PLUTO_STACK='netkey' PLUTO_ADDTIME='1571944637' PLUTO_CONN_POLICY='PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV2_ALLOW+IKEV2_ALLOW_NARROWING+SAREF_TRACK+IKE_FRAG_ALLOW+MOBIKE+ESN_NO' PLUTO_CONN_KIND='CK_INSTANCE' PLUTO_CONN_ADDRFAMILY='ipv4' XAUTH_FAILED=0 PLUTO_MY_SOURCEIP='192.0.3.10' PLUTO_IS_PEER_CISCO='0' PLUTO_PEER_DNS_INFO='' PLUTO_PEER_DOMAIN_INFO='' PLUTO_PEER_BANNER='' PLUTO_CFG_SERVER='0' PLUTO_CFG_CLIENT='1'... I'm wondering if the code shutting down the above 'client' was meant to remove the child's route from the connection? Andrew From paul at nohats.ca Tue Oct 29 23:12:58 2019 From: paul at nohats.ca (Paul Wouters) Date: Tue, 29 Oct 2019 19:12:58 -0400 (EDT) Subject: [Swan-dev] strange time time death in nss-cert-09-notyetvalid-initiator-ikev2 In-Reply-To: References: Message-ID: On Sat, 26 Oct 2019, Andrew Cagney wrote: > Subject: Re: [Swan-dev] strange time time death in > nss-cert-09-notyetvalid-initiator-ikev2 > > Grrr, > Updating the VMs made the problem go away. Yes, the new libfaketime-0.9.8-4 recompile fixes various compile time issues with the libraries on fedora 30+ Paul