ipsec-tools-devel — Development discussion of IPsec Tools

Re: [Ipsec-tools-devel] [Ipsec-tools-core] Potential Vulnerability Discovered in IPsec-Tools

[Rainer W. <rwe...@mo...>]

Reinoud Koornstra <rei...@gm...> writes:
> Thanks for the patch and discovering this. Adding Rainer to this thread as
> he'll know quickly if this patch is good or needs a small adjustment.
> Thanks,

The underlying problem is really that racoon just puts all fragments it
receives on a list without checking for duplicate fragment indices. This
means an unauthenticated attacker can just keep sending a fragment with
the same index and the list will keep growing until the machine runs out
of memory. It's also possible to make the daemon additionally consume a
lot of CPU time by triggering 'did we receive all fragements' scans
after each fragment was received. The algorithm used for detecting this
is roughly:


for (i = 1; i <= last_frag_index; ++i)
	/* walk complete list to look for fragment with index i */

The proposed patch addresses this partially by checking that no
duplicate fragments are received and by keeping the fragment list sorted
(insertion sort) so that the scan for 'all fragments received' becomes
linear. But there's another quadratic scan in the reassembly function and
for at most 255 fragments, the complexity doesn't matter that much.

As bandaid, I suggest to leave the scan algorithm alone and just reject
duplicated and/or obviously nonsensical fragment numbers.

It's possible to do a O(1) implementation here (I'm using a partial O(1)
implementation in the commercial fork I'm maintaining) and I'm planning
to replace this with a complete one. I'll ask for permission to publish
it once it's done.

Getting in touch with NetBSD might also a good idea as they are (AFAIK)
maintaining there own fork as part of the NetBSD tree.

NB: A known issue with this (and also the other patch) is that the
daemon will accept fragments whose index is larger than that of the one
marked as last fragment. But this should be harmless.

---
diff -rNu ipsec-tools-0.8.0/src/racoon/isakmp_frag.c patched/src/racoon/isakmp_frag.c
--- ipsec-tools-0.8.0/src/racoon/isakmp_frag.c  2009-04-22 12:24:20.000000000 +0100
+++ patched/src/racoon/isakmp_frag.c    2016-10-18 17:28:57.289513357 +0100
@@ -231,14 +231,31 @@
        if (iph1->frag_chain == NULL) {
                iph1->frag_chain = item;
        } else {
-               struct isakmp_frag_item *current;
+               struct isakmp_frag_item *current, *next;
 
-               current = iph1->frag_chain;
-               while (current->frag_next) {
-                       if (current->frag_last)
-                               last_frag = item->frag_num;
-                       current = current->frag_next;
-               }
+               next = iph1->frag_chain;
+               do {
+                       current = next;
+                       if (current->frag_num == item->frag_num) {
+                               plog(LLV_DEBUG, LOCATION, NULL, "duplicate fragment %d\n",
+                                    item->frag_num);
+
+                               free(item);
+                               return 0;
+                       }
+
+                       if (current->last_frag) {
+                               if (item->last_frag) {
+                                       plog(LLV_WARNING, LOCATION, NULL, "multiple last fragments received\n");
+
+                                       free(item);
+                                       return -1;
+                               }
+
+                               last_frag = current->frag_num;
+                       }
+               } while ((next = next->next));
+
                current->frag_next = item;
        }
 

Re: [Ipsec-tools-devel] [Ipsec-tools-core] Potential Vulnerability Discovered in IPsec-Tools

[Reinoud K. <rei...@gm...>]

Hi Robert,

Thanks for the patch and discovering this. Adding Rainer to this thread as
he'll know quickly if this patch is good or needs a small adjustment.
Thanks,

Reinoud.

On Oct 14, 2016 8:45 AM, "Robert Foggia" <RF...@tr...> wrote:

> Hello,
>
> Please find attached a patched for an issue discovered in ipsec-tools
> affecting raccoon 0.8.2 and prior. Details about Remote un-authenticated
> denial of service finding is below:
>
> Finding 1: Remote un-authenticated denial of service
> Credit: Trustwave
>
> The ipsec-tools racoon daemon contains a remotely exploitable
> computational complexity attack when parsing and storing isakmp fragments.
> The implementation permits a remote attacker to exhaust computational
> resources on the remote endpoint by repeatedly sending isakmp fragment
> packets in a particular order such that the worst-case computational
> complexity is realized in the algorithm utilized to determine if reassembly
> of the fragments can take place.
>
> The algorithm in question is a simple quadratic linked list walk and is in
> O(n(n+1)) hence O(n^2) for ’n’ fragments received. Since the implementation
> fails to identify repeated fragment indices, a remote attacker can
> repeatedly specify the same index. Worst-case complexity is realized if
> fragments are sent in reverse order, for instance:
>
> 253, 252 ... 3, 2, 1, 255 (last fragment)
>
> The absence of fragment index 254 is not an error as this ensures fragment
> reassembly is not possible.
>
>
> After review, please provide feedback on the next steps to get this issue
> patched.  Thanks!
>
>
> Best regards,
>
> Robert F.
> Security Researcher, Intelligence Team, SpiderLabs
>
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>
>
> On Wed, 27 Jul 2016 16:09:04 +0000
>
> >In the interest of responsible disclosure, we are notifying you about
> >potential vulnerability we have discovered in IPSec-Tools. This
> >vulnerability allows the ability for a remote unauthenticated
> >attacker to perform a denial of service attack. Based on our
> >disclosure policy, we will release an advisory detailing these
> >finding(s) after 30 days if we do not receive a reply. Because of the
> >sensitive nature of this issue, we are unable to include the advisory
> >in this email. However, we'd be happy to send the full advisory to
> >you. Please let me know if you prefer for us to send it encrypted
> >with your PGP key, send it using our secure email system, or simply
> >using conventional email.
>
> It seems no one is actively maintaining the upstream distribution any
> more. However, there is active community using it on ipsec-tools-devel
> mailing list. I suggest you post there first the patch if one exists,
> or other details.
>
> Thanks,
> Timo
>
>
> ________________________________
>
> This transmission may contain information that is privileged,
> confidential, and/or exempt from disclosure under applicable law. If you
> are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this transmission in error, please immediately contact the sender
> and destroy the material in its entirety, whether in electronic or hard
> copy format.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
>
>

Re: [Ipsec-tools-devel] [Ipsec-tools-core] Potential Vulnerability Discovered in IPsec-Tools

[Robert F. <RF...@tr...>]

Hello,

Please find attached a patched for an issue discovered in ipsec-tools affecting raccoon 0.8.2 and prior. Details about Remote un-authenticated denial of service finding is below:

Finding 1: Remote un-authenticated denial of service
Credit: Trustwave

The ipsec-tools racoon daemon contains a remotely exploitable computational complexity attack when parsing and storing isakmp fragments. The implementation permits a remote attacker to exhaust computational resources on the remote endpoint by repeatedly sending isakmp fragment packets in a particular order such that the worst-case computational complexity is realized in the algorithm utilized to determine if reassembly of the fragments can take place.

The algorithm in question is a simple quadratic linked list walk and is in O(n(n+1)) hence O(n^2) for ’n’ fragments received. Since the implementation fails to identify repeated fragment indices, a remote attacker can repeatedly specify the same index. Worst-case complexity is realized if fragments are sent in reverse order, for instance:

253, 252 ... 3, 2, 1, 255 (last fragment)

The absence of fragment index 254 is not an error as this ensures fragment reassembly is not possible.


After review, please provide feedback on the next steps to get this issue patched.  Thanks!


Best regards,

Robert F.
Security Researcher, Intelligence Team, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>


On Wed, 27 Jul 2016 16:09:04 +0000

>In the interest of responsible disclosure, we are notifying you about
>potential vulnerability we have discovered in IPSec-Tools. This
>vulnerability allows the ability for a remote unauthenticated
>attacker to perform a denial of service attack. Based on our
>disclosure policy, we will release an advisory detailing these
>finding(s) after 30 days if we do not receive a reply. Because of the
>sensitive nature of this issue, we are unable to include the advisory
>in this email. However, we'd be happy to send the full advisory to
>you. Please let me know if you prefer for us to send it encrypted
>with your PGP key, send it using our secure email system, or simply
>using conventional email.

It seems no one is actively maintaining the upstream distribution any
more. However, there is active community using it on ipsec-tools-devel
mailing list. I suggest you post there first the patch if one exists,
or other details.

Thanks,
Timo


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

Re: [Ipsec-tools-devel] sa lifetime overflow value

[Rainer W. <rwe...@mo...>]

cool linux <lin...@gm...> writes:
> lifetime maximum value will be max value of unsigned int32 FFFFFFFF which
> is 4294967295.
>
> During a negative test
> when configured phase 2 lifetime with value FFFFFFFF+1 =
> 4294967296(lifetime time 4294967296 sec;) = 0(truncated value) -- we get
> that value(life duration 0) provided as invalid
>
>
> Sep 23 13:31:36 racoon: ERROR: invalid life duration.
> Sep 23 13:31:36 racoon: ERROR: no suitable policy found.
> Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: no proposal chosen.
> Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: failed to pre-process ph2
> packet (side: 1, status: 1).
>
> On the contrary if we directly configure 0 in racoon.conf with (lifetime
> time 0 sec;) it doesn't result into such issue, infact it defaults it to 8
> hours.
>
> However - It is also observed that when configured with FFFFFFFF+2 =
> 4294967297 = 1(truncated value) -- and the same will be used as lifetime
> [Which is expected].
>
>
> The question is why there is a difference in behavior

The configured lifetime is stored as time_t and parsed via strtol. On a
64-bit system, a long can hold 4294967296 and a time_t can store that,
too. As that's not 0, the default isn't being used. The value turns to 0
upon conversion to a 32-bit integer when ISAKMP payloads are
created. This is then rejected as invalid.

Re: [Ipsec-tools-devel] sa lifetime overflow value

[cool l. <lin...@gm...>]

Hi,
Thanks for you response.
please find configuration details below.

Machine B
---------------
root:~# cat /etc/racoon/racoon.conf
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
log debug2;

sainfo address xx.xx.xx.B any address xx.xx.xx.A any {
        encryption_algorithm aes  ;
        authentication_algorithm hmac_sha256 ;
        compression_algorithm deflate ;
        lifetime time *4294967296 *sec ;
}
remote xx.xx.xx.A  {
        exchange_mode main;
        #tag id 1
        proposal_check obey;
        proposal {
                encryption_algorithm aes  ;
                hash_algorithm sha256;
                authentication_method pre_shared_key ;
                dh_group modp1024;
        }
}

Machine A
---------------
root:~# cat /etc/racoon/racoon.conf
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
log debug2;

sainfo address xx.xx.xx.A any address xx.xx.xx.B any {
        encryption_algorithm aes  ;
        authentication_algorithm hmac_sha256 ;
        compression_algorithm deflate ;
        lifetime time *4294967296 *sec ;
}
remote xx.xx.xx.B  {
        exchange_mode main;
        #tag id 1
        proposal_check obey;
        proposal {
                encryption_algorithm aes  ;
                hash_algorithm sha256;
                authentication_method pre_shared_key ;
                dh_group modp1024;
        }
}

And please let me know in which file we can directly assign a static(how to
change a default value) value to sa lifetime variable.

Thanks in advance.

Regards
Madhu


On Sat, Oct 1, 2016 at 12:55 AM, Reinoud Koornstra <
rei...@gm...> wrote:

> On Tue, Sep 27, 2016 at 2:27 PM, cool linux <lin...@gm...>
> wrote:
> > Hi,
> >
> > lifetime maximum value will be max value of unsigned int32 FFFFFFFF
> which is
> > 4294967295.
> >
> > During a negative test
> > when configured phase 2 lifetime with value FFFFFFFF+1 =
> 4294967296(lifetime
> > time 4294967296 sec;) = 0(truncated value) -- we get that value(life
> > duration 0) provided as invalid
> >
> >
> > Sep 23 13:31:36 racoon: ERROR: invalid life duration.
> > Sep 23 13:31:36 racoon: ERROR: no suitable policy found.
> > Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: no proposal chosen.
> > Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: failed to pre-process ph2
> > packet (side: 1, status: 1).
> >
> > On the contrary if we directly configure 0 in racoon.conf with (lifetime
> > time 0 sec;) it doesn't result into such issue, infact it defaults it to
> 8
> > hours.
> >
> > However - It is also observed that when configured with FFFFFFFF+2 =
> > 4294967297 = 1(truncated value) -- and the same will be used as lifetime
> > [Which is expected].
> >
> >
> > The question is why there is a difference in behavior for lifetime value
> of
> > 0, when configured explicitly as (lifetime time 0 sec;) compared to
> > (lifetime time 4294967296 sec;). Alternatively, is 0 a valid value or
> not.
>
> Interesting indeed. I would need to look where the lifetime is parsed and
> how.
> Likely Rainer knows this already. A good find though.
> Let's see if Rainer can respond quickly, otherwise I'll try to
> reproduce next week.
> Can you copy the configuration you used?
> Thanks
>
> >
> > Regards
> > Madhu
> >
>
> Reinoud.
>
> > ------------------------------------------------------------
> ------------------
> >
> > _______________________________________________
> > Ipsec-tools-devel mailing list
> > Ips...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
> >
>

Re: [Ipsec-tools-devel] sa lifetime overflow value

[Reinoud K. <rei...@gm...>]

On Tue, Sep 27, 2016 at 2:27 PM, cool linux <lin...@gm...> wrote:
> Hi,
>
> lifetime maximum value will be max value of unsigned int32 FFFFFFFF which is
> 4294967295.
>
> During a negative test
> when configured phase 2 lifetime with value FFFFFFFF+1 = 4294967296(lifetime
> time 4294967296 sec;) = 0(truncated value) -- we get that value(life
> duration 0) provided as invalid
>
>
> Sep 23 13:31:36 racoon: ERROR: invalid life duration.
> Sep 23 13:31:36 racoon: ERROR: no suitable policy found.
> Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: no proposal chosen.
> Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: failed to pre-process ph2
> packet (side: 1, status: 1).
>
> On the contrary if we directly configure 0 in racoon.conf with (lifetime
> time 0 sec;) it doesn't result into such issue, infact it defaults it to 8
> hours.
>
> However - It is also observed that when configured with FFFFFFFF+2 =
> 4294967297 = 1(truncated value) -- and the same will be used as lifetime
> [Which is expected].
>
>
> The question is why there is a difference in behavior for lifetime value of
> 0, when configured explicitly as (lifetime time 0 sec;) compared to
> (lifetime time 4294967296 sec;). Alternatively, is 0 a valid value or not.

Interesting indeed. I would need to look where the lifetime is parsed and how.
Likely Rainer knows this already. A good find though.
Let's see if Rainer can respond quickly, otherwise I'll try to
reproduce next week.
Can you copy the configuration you used?
Thanks

>
> Regards
> Madhu
>

Reinoud.

> ------------------------------------------------------------------------------
>
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
>

[Ipsec-tools-devel] sa lifetime overflow value

[cool l. <lin...@gm...>]

Hi,

lifetime maximum value will be max value of unsigned int32 FFFFFFFF which
is 4294967295.

During a negative test
when configured phase 2 lifetime with value FFFFFFFF+1 =
4294967296(lifetime time 4294967296 sec;) = 0(truncated value) -- we get
that value(life duration 0) provided as invalid


Sep 23 13:31:36 racoon: ERROR: invalid life duration.
Sep 23 13:31:36 racoon: ERROR: no suitable policy found.
Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: no proposal chosen.
Sep 23 13:31:36 racoon: [xx.xx.xx.xx] ERROR: failed to pre-process ph2
packet (side: 1, status: 1).

On the contrary if we directly configure 0 in racoon.conf with (lifetime
time 0 sec;) it doesn't result into such issue, infact it defaults it to 8
hours.

However - It is also observed that when configured with FFFFFFFF+2 =
4294967297 = 1(truncated value) -- and the same will be used as lifetime
[Which is expected].


The question is why there is a difference in behavior for lifetime value of
0, when configured explicitly as (lifetime time 0 sec;) compared to
(lifetime time 4294967296 sec;). Alternatively, is 0 a valid value or not.

Regards
Madhu

[Ipsec-tools-devel] GCM support

[Naji m A. <na...@pu...>]

Hi,

I am looking for GCM support in ipsec tools.
I looked at ipsec-tools-0.8.2<https://sourceforge.net/projects/ipsec-tools/files/ipsec-tools/0.8.2/ipsec-tools-0.8.2.tar.gz/download>, but there seems to be no support for GCM here.
Is there any newer version ipsec tools available, where this support is added.

Thanks
--naji

Re: [Ipsec-tools-devel] racoon: segmentation fault error

[Rainer W. <rwe...@mo...>]

Samanvitha Bhargav <sam...@gm...> writes:

[...]

> [root@CLA-0(FBSA-13) /root] racoon -F -f /etc/ipsec/0/ike1/racoon.conf
> Foreground mode.
> 2016-06-07 07:26:39: INFO: @(#)ipsec-tools 0.8.2 (
> http://ipsec-tools.sourceforge.net)
> Segmentation fault (core dumped)
>
> the gdb analysis of dumped core is given below. Can anybody help me on
> this..
>
> [root@CLA-0(FBSA-13) /root] gdb racoon -c
> CLA-0-8769-5755262c-racoon-SEGV.core
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> http://www.gnu.org/software/gdb/bugs/.
> Find the GDB manual and other documentation resources online at:
> http://www.gnu.org/software/gdb/documentation/.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from racoon...done.
> [New LWP 8769]
>
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> Core was generated by `/usr/sbin/racoon'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> 0 0x00007fefd73633dd in _IO_vfprintf_internal (s=s@entry=0xd69120,
> format=<optimized out="">, format@entry=0x67c180 <buf> "INFO: %s\n",
> ap=ap@entry=0x7fff9d913268) at vfprintf.c:1632
> 1632 vfprintf.c: No such file or directory.
> (gdb) bt full
> 0 0x00007fefd73633dd in _IO_vfprintf_internal (s=s@entry=0xd69120,
> format=<optimized out="">, format@entry=0x67c180 <buf> "INFO: %s\n",
> ap=ap@entry=0x7fff9d913268) at vfprintf.c:1632
> len = <optimized out="">
> string_malloced = <optimized out="">
> step0_jumps = {0, -4893, -4842, 73, 163, -5792, -5690, -5435, -1729, -767,
> 330, -8653, -8570, -8477, -8382, -8335, -4670, -5165, -1744, -2433, -1333,
> -30, -4272, -4176, -1470, -9580,

[more of this]

Who on earth is supposed to make any sense of this truckload of randomly
reformatted garbage?

Re: [Ipsec-tools-devel] racoon: segmentation fault error

[Reinoud K. <rei...@gm...>]

On Mon, Jun 6, 2016 at 10:35 PM, Samanvitha Bhargav
<sam...@gm...> wrote:
> Hi
>
> I downloaded ipsectools from : https://sourceforge.net/projects/ipsec-tools/
> and applied a patch as mentioned in :
> https://dev.openwrt.org/browser/packages/net/ipsec-tools/patches/006-linux-3.7-compat.patch?rev=35312
> Susequently after extracting and applying patch, i used the following
> commands,
> ./bootstrap
> autoconf
> ./configure --prefix=/. --libdir=/usr/lib64 --sbindir=/usr/sbin
> --enable-shared --enable-security-context=no CXX=${CROSS_COMPILE}g++
> CC=${CROSS_COMPILE}gcc AS=${CROSS_COMPILE}as AR=$ {CROSS_COMPILE}ar
> LD=${CROSS_COMPILE}ld NM=${CROSS_COMPILE}nm OBJCOPY=${CROSS_COMPILE}objcopy
> OBJDUMP=${CROSS_COMPILE}objdump RANLIB=${CROSS_COMPILE}ranlib
> READELF=${CROSS_COMPILE}readelf S TRIP=${CROSS_COMPILE}strip
> --with-kernel-headers=${RH_KERNEL_HOME}/include --host=$HOST --build=$BUILD
>
> It compiled successfully.
>
> but then, on usage the racoon crashes with a Segmentation fault.
>
> [root@CLA-0(FBSA-13) /root] racoon -F -f /etc/ipsec/0/ike1/racoon.conf
> Foreground mode.
> 2016-06-07 07:26:39: INFO: @(#)ipsec-tools 0.8.2
> (http://ipsec-tools.sourceforge.net)
> Segmentation fault (core dumped)
>
> the gdb analysis of dumped core is given below. Can anybody help me on
> this..
>
> [root@CLA-0(FBSA-13) /root] gdb racoon -c
> CLA-0-8769-5755262c-racoon-SEGV.core
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> http://www.gnu.org/software/gdb/bugs/.
> Find the GDB manual and other documentation resources online at:
> http://www.gnu.org/software/gdb/documentation/.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from racoon...done.
> [New LWP 8769]
>
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> Core was generated by `/usr/sbin/racoon'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> 0 0x00007fefd73633dd in _IO_vfprintf_internal (s=s@entry=0xd69120,
> format=<optimized out="">, format@entry=0x67c180 <buf> "INFO: %s\n",
> ap=ap@entry=0x7fff9d913268) at vfprintf.c:1632
> 1632 vfprintf.c: No such file or directory.
> (gdb) bt full
> 0 0x00007fefd73633dd in _IO_vfprintf_internal (s=s@entry=0xd69120,
> format=<optimized out="">, format@entry=0x67c180 <buf> "INFO: %s\n",
> ap=ap@entry=0x7fff9d913268) at vfprintf.c:1632

I've seen a very similar crash in SSL dump/
I wonder that %s was in this case.
Could you replace all -O2 to -O0 after the configure so that no
optimization is done?
That way we can see more instead of optimized out?
Also, what libc lib did you use to compile against?
So it crashes right away upon reading the config?

> len = <optimized out="">
> string_malloced = <optimized out="">
> step0_jumps = {0, -4893, -4842, 73, 163, -5792, -5690, -5435, -1729, -767,
> 330, -8653, -8570, -8477, -8382, -8335, -4670, -5165, -1744, -2433, -1333,
> -30, -4272, -4176, -1470, -9580,
> -2117, -8384, -8477, -5518}
> space = <optimized out="">
> is_short = <optimized out="">
> use_outdigits = <optimized out="">
> step1_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, -767, 330, -8653, -8570, -8477,
> -8382, -8335, -4670, -5165, -1744, -2433, -1333, -30, -4272, -4176, -1470,
> -9580, -2117, -8384, -8477, 0}
> group = <optimized out="">
> prec = <optimized out="">
> step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 330, -8653, -8570, -8477,
> -8382, -8335, -4670, -5165, -1744, -2433, -1333, -30, -4272, -4176, -1470,
> -9580, -2117, -8384, -8477, 0}
> string = <optimized out="">
> left = <optimized out="">
> is_long_double = <optimized out="">
> width = <optimized out="">
> step3a_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 413, 0, 0, 0, -8382, -8335,
> -4670, -5165, -1744, 0, 0, 0, 0, -4176, 0, 0, 0, 0, 0, 0}
> alt = <optimized out="">
> showsign = <optimized out="">
> is_long = <optimized out="">
> is_char = <optimized out="">
> pad = <optimized out="">
> step3b_jumps = {0 <repeats 11="" times="">, -8570, 0, 0, -8382, -8335,
> -4670, -5165, -1744, -2433, -1333, -30, -4272, -4176, -1470, -9580, -2117,
> 0, 0, 0}
> step4_jumps = {0 <repeats 14="" times="">, -8382, -8335, -4670, -5165,
> -1744, -2433, -1333, -30, -4272, -4176, -1470, -9580, -2117, 0, 0, 0}
> is_negative = <optimized out="">
> number = <optimized out="">
> base = <optimized out="">
> the_arg = {pa_wchar = -1651428480 L'\x9d913380', pa_int = -1651428480,
> pa_long_int = 140735836926848, pa_long_long_int = 140735836926848, pa_u_int
> = 2643538816,
> pa_u_long_int = 140735836926848, pa_u_long_long_int = 140735836926848,
> pa_double = 6.9532742164271511e-310, pa_long_double = <invalid float=""
> value="">,
> pa_string = 0x7fff9d913380 "\230\064\221\235\377\177", pa_wstring =
> 0x7fff9d913380 L"\x9d913498翿\001", pa_pointer = 0x7fff9d913380, pa_user =
> 0x7fff9d913380}
> spec = 115 's'
> _buffer = {routine = 0x0, arg = 0x2fd, canceltype = -665223168, prev =
> 0x7fefd731dd58}
> _avail = <optimized out="">
> thousands_sep = 0x0
> grouping = 0xffffffffffffffff <error: Cannot="" access="" memory="" at=""
> address="" 0xffffffffffffffff="">
> done = <optimized out="">
> f = 0x67c187 <buf+7> "s\n"
> lead_str_end = 0x67c186 <buf+6> "%s\n"
> end_of_spec = <optimized out="">
> work_buffer =
> "\270\257\062\327\357\177\000\000:\030\071\330\357\177\000\000\375\002\000\000\000\000\000\000\270\257\062\327\357\177\000\000\000\200Y\330\357\177\000\000\370-\221\235\377\177\000\000\364-\221\235\377\177\000\000\030sY\330\357\177\000\000\211\300\062\327\357\177\000\000\020%2\327\357\177\000\000\370-\221\235\377\177\000\000\363\026\346\365\000\000\000\000[\230\327\003\000\000\000\000\063\000\000\000\377\177\000\000\320.\221\235\377\177\000\000\270\257\062\327\357\177\000\000X\335\061\327\357\177\000\000\364-\221\235\377\177\000\000\300.\221\235\377\177\000\000\270pY\330\357\177\000\000\n",
> '\000' <repeats 15="" times="">, "x\223Y\330", '\000' <repeats 12=""
> times="">, "O2\221\235\001\000\000\000"...
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports. http://sdm.link/zohomanageengine
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
>

[Ipsec-tools-devel] racoon: segmentation fault error

[Samanvitha B. <sam...@gm...>]

Hi

I downloaded ipsectools from : https://sourceforge.net/projects/ipsec-tools/
and applied a patch as mentioned in :
https://dev.openwrt.org/browser/packages/net/ipsec-tools/patches/006-linux-3.7-compat.patch?rev=35312
Susequently after extracting and applying patch, i used the following
commands,
./bootstrap
autoconf
./configure --prefix=/. --libdir=/usr/lib64 --sbindir=/usr/sbin
--enable-shared --enable-security-context=no CXX=${CROSS_COMPILE}g++
CC=${CROSS_COMPILE}gcc AS=${CROSS_COMPILE}as AR=$ {CROSS_COMPILE}ar
LD=${CROSS_COMPILE}ld NM=${CROSS_COMPILE}nm OBJCOPY=${CROSS_COMPILE}objcopy
OBJDUMP=${CROSS_COMPILE}objdump RANLIB=${CROSS_COMPILE}ranlib
READELF=${CROSS_COMPILE}readelf S TRIP=${CROSS_COMPILE}strip
--with-kernel-headers=${RH_KERNEL_HOME}/include --host=$HOST --build=$BUILD

It compiled successfully.

but then, on usage the racoon crashes with a Segmentation fault.

[root@CLA-0(FBSA-13) /root] racoon -F -f /etc/ipsec/0/ike1/racoon.conf
Foreground mode.
2016-06-07 07:26:39: INFO: @(#)ipsec-tools 0.8.2 (
http://ipsec-tools.sourceforge.net)
Segmentation fault (core dumped)

the gdb analysis of dumped core is given below. Can anybody help me on
this..

[root@CLA-0(FBSA-13) /root] gdb racoon -c
CLA-0-8769-5755262c-racoon-SEGV.core
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from racoon...done.
[New LWP 8769]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `/usr/sbin/racoon'.
Program terminated with signal SIGSEGV, Segmentation fault.
0 0x00007fefd73633dd in _IO_vfprintf_internal (s=s@entry=0xd69120,
format=<optimized out="">, format@entry=0x67c180 <buf> "INFO: %s\n",
ap=ap@entry=0x7fff9d913268) at vfprintf.c:1632
1632 vfprintf.c: No such file or directory.
(gdb) bt full
0 0x00007fefd73633dd in _IO_vfprintf_internal (s=s@entry=0xd69120,
format=<optimized out="">, format@entry=0x67c180 <buf> "INFO: %s\n",
ap=ap@entry=0x7fff9d913268) at vfprintf.c:1632
len = <optimized out="">
string_malloced = <optimized out="">
step0_jumps = {0, -4893, -4842, 73, 163, -5792, -5690, -5435, -1729, -767,
330, -8653, -8570, -8477, -8382, -8335, -4670, -5165, -1744, -2433, -1333,
-30, -4272, -4176, -1470, -9580,
-2117, -8384, -8477, -5518}
space = <optimized out="">
is_short = <optimized out="">
use_outdigits = <optimized out="">
step1_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, -767, 330, -8653, -8570, -8477,
-8382, -8335, -4670, -5165, -1744, -2433, -1333, -30, -4272, -4176, -1470,
-9580, -2117, -8384, -8477, 0}
group = <optimized out="">
prec = <optimized out="">
step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 330, -8653, -8570, -8477,
-8382, -8335, -4670, -5165, -1744, -2433, -1333, -30, -4272, -4176, -1470,
-9580, -2117, -8384, -8477, 0}
string = <optimized out="">
left = <optimized out="">
is_long_double = <optimized out="">
width = <optimized out="">
step3a_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 413, 0, 0, 0, -8382, -8335,
-4670, -5165, -1744, 0, 0, 0, 0, -4176, 0, 0, 0, 0, 0, 0}
alt = <optimized out="">
showsign = <optimized out="">
is_long = <optimized out="">
is_char = <optimized out="">
pad = <optimized out="">
step3b_jumps = {0 <repeats 11="" times="">, -8570, 0, 0, -8382, -8335,
-4670, -5165, -1744, -2433, -1333, -30, -4272, -4176, -1470, -9580, -2117,
0, 0, 0}
step4_jumps = {0 <repeats 14="" times="">, -8382, -8335, -4670, -5165,
-1744, -2433, -1333, -30, -4272, -4176, -1470, -9580, -2117, 0, 0, 0}
is_negative = <optimized out="">
number = <optimized out="">
base = <optimized out="">
the_arg = {pa_wchar = -1651428480 L'\x9d913380', pa_int = -1651428480,
pa_long_int = 140735836926848, pa_long_long_int = 140735836926848, pa_u_int
= 2643538816,
pa_u_long_int = 140735836926848, pa_u_long_long_int = 140735836926848,
pa_double = 6.9532742164271511e-310, pa_long_double = <invalid float=""
value="">,
pa_string = 0x7fff9d913380 "\230\064\221\235\377\177", pa_wstring =
0x7fff9d913380 L"\x9d913498翿\001", pa_pointer = 0x7fff9d913380, pa_user =
0x7fff9d913380}
spec = 115 's'
_buffer = {*routine = 0x0, *arg = 0x2fd, *canceltype = -665223168, *prev =
0x7fefd731dd58}
_avail = <optimized out="">
thousands_sep = 0x0
grouping = 0xffffffffffffffff <error: Cannot="" access="" memory="" at=""
address="" 0xffffffffffffffff="">
done = <optimized out="">
f = 0x67c187 <buf+7> "s\n"
lead_str_end = 0x67c186 <buf+6> "%s\n"
end_of_spec = <optimized out="">
work_buffer =
"\270\257\062\327\357\177\000\000:\030\071\330\357\177\000\000\375\002\000\000\000\000\000\000\270\257\062\327\357\177\000\000\000\200Y\330\357\177\000\000\370-\221\235\377\177\000\000\364-\221\235\377\177\000\000\030sY\330\357\177\000\000\211\300\062\327\357\177\000\000\020%2\327\357\177\000\000\370-\221\235\377\177\000\000\363\026\346\365\000\000\000\000[\230\327\003\000\000\000\000\063\000\000\000\377\177\000\000\320.\221\235\377\177\000\000\270\257\062\327\357\177\000\000X\335\061\327\357\177\000\000\364-\221\235\377\177\000\000\300.\221\235\377\177\000\000\270pY\330\357\177\000\000\n",
'\000' <repeats 15="" times="">, "x\223Y\330", '\000' <repeats 12=""
times="">, "O2\221\235\001\000\000\000"...

Re: [Ipsec-tools-devel] Calling-Station-Id as attribute when radius authentication is in place

[Bruncko M. <Mic...@zs...>]

Hi Timo

sorry to say, but seems this patch is still not yet included. I have 
checked latest ipsec-tools package from 
ftp://ftp.netbsd.org/pub/NetBSD/misc/ipsec-tools/0.8/ but I cant see 
this patch included.
Attaching it here as it longer time included in RHEL rpm package.

thanks

michal


On 2013-07-19 12:56, Timo Teras wrote:
> On Fri, 12 Jul 2013 22:31:10 +0200
> Michal Bruncko <mic...@zs...> wrote:
> 
>> could you please include this in CVS HEAD? Currently ipsec-tools is
>> missing such radius attribute.
>> 
>> patch attached in last response from Rainer.
> 
> Done. Thank you for both of you, Rainer and Michal, for the patch and
> testing.
> 
> - Timo

Re: [Ipsec-tools-devel] ERROR: pfkey DELETE received

[Rainer W. <rwe...@mo...>]

"Eugene M. Zheganin" <em...@no...> writes:
>
> On 23.10.2015 20:38, Rainer Weikusat wrote:
>> "Eugene M. Zheganin" <em...@no...> writes:
>>
>>> Hi.
>>>
>>> I'm seeing the message "ERROR: pfkey DELETE received" quite periodically
>>> in logs. However, it does not seem it to cause any problems. What does
>>> this mean ?
>> It means racoon has received a PF_KEY SADB_DELETE message whose process
>> ID differed from its own, ie, one which was apparently not sent by
>> itself.
>>
> Sorry for this grave digging, but I'm forced to reinvestigate this 
> issue. Given that I have in the logs a record like
>
> May  1 19:00:02 balancer1 racoon: ERROR: pfkey DELETE received: ESP 
> XXX.XX.XXX.XX[500]->ZZZ.ZZ.ZZZ.ZZ[500] spi=831488614(0x318f8266)
>
> - what can it mean ? XXX.XX.XXX.XX is a local IP of the server that 
> logged this message. I think the '->' represents the direction, but if 
> some message is "received" why the direction is outgoing ?

That's logged by this code (in pfkey.c/ pk_recvdelete)

        iph2 = getph2bysaidx(src, dst, proto_id, sa->sadb_sa_spi);
        if (iph2 == NULL) {
                /* ignore */
                plog(LLV_ERROR, LOCATION, NULL,
                        "no iph2 found: %s\n",
                        sadbsecas2str(src, dst, msg->sadb_msg_satype,
                                sa->sadb_sa_spi, IPSEC_MODE_ANY));
                return 0;
        }

        plog(LLV_ERROR, LOCATION, NULL,
                "pfkey DELETE received: %s\n",
                sadbsecas2str(src, dst,
                        msg->sadb_msg_satype, sa->sadb_sa_spi, IPSEC_MODE_ANY));

The addresses represent source and destination address of the ph2 SA the
delete message referred to and the spi= is it's spi. The message is
'received' because it's a PF_KEY message (local IPsec configuration
management protocol message sent by the kernel). More to the top of this
function, you'll find the following code:


        /* the message has to be processed or not ? */
        if (msg->sadb_msg_pid == getpid()) {
                plog(LLV_DEBUG, LOCATION, NULL,
                        "%s message is not interesting "
                        "because the message was originated by me.\n",
                        s_pfkey_type(msg->sadb_msg_type));
                return -1;
        }

Communication generally works as follows:

	1. Something sends a PF_KEY delete message to the kernel. This
 	   instructs the kernel to delete the SAs specified in the
 	   message. That something is supposed to send its process ID as
 	   part of the message meta-information.

	2. The kernel resends the PF_KEY messages to all registered
	   PF_KEY listeners to inform them about the fact. A listener
	   can determine if the original message was sent by itself or
	   by some other entity by comparings its pid with the pid in
	   the received message (that's what the check above does).

You could change the LLV_ERROR message to include the received pid, eg,
to something like (untested)

        plog(LLV_ERROR, LOCATION, NULL,
                "pfkey DELETE received: %s (%u)\n",
                sadbsecas2str(src, dst,
                        msg->sadb_msg_satype, sa->sadb_sa_spi, IPSEC_MODE_ANY), msg->sadb_msg_pid);

This would give you the process ID of the entity which sent the message
which ought to be helpful for identifying the sender of the message.

A conceivable scenario (conjecture which doesn't contradict know facts):
A racoon process sends a delete and then crashes. It's restarted
automatically and the new process receives the delete.

[Ipsec-tools-devel] policy "require" vs policy "unique"

[Eugene M. Z. <em...@no...>]

Hi,

I need help triubleshooting one of my VPNs to a 3rdparty network with 
Cisco ASA as a gateway. It's a legacy ipsec VPN (not uning any 
intermediate encapsulation like gre or ip-in-ip, since ASA is uncapable 
of it), when all the trafic gets captured by the policy, not routed via 
tunnel interfaces. I have one pair of security gateways and two pairs of 
target networks (actually they are hosts, so mask is /32). The thing is, 
only one pair of target SP (both are "require") is working at a time. 
Guys at the other side think this is because I should use "unique" level 
of policy, but then some additional questions are problems arise:

1) I've also found various descriptions of such behavior and the 
solution was switching to the "unique" policy level of SP. But the thing 
is my situation is different: instead of the situation when the traffic 
is handled properly only for an initial set of SP which the traffic was 
matching to, in my case SA are renegotiated each time IPsec stack is 
seeing the traffic matching new SPs. Let me illustrate with a scheme of 
my policies:

SP1 in: <target A> <target B> <traffic type> <gateway A> <gateway B> 
<require>

SP1 out: <target B> <target A> <traffic type> <gateway B> <gateway A> 
<require>

SP2 in: <target A> <target C> <traffic type> <gateway A> <gateway B> 
<require>

SP2 out: <target C> <target A> <traffic type> <gateway B> <gateway A> 
<require>

When there's traffic matching the SP1 set, it's working. As soon as the 
traffic matching set SP2 appears, SA got renegotiated, SP2 traffic 
starts to flow, SP1 traffic stops to flow, but it doesn't disappear, so 
I have a situation when both flows works 50% of the time and SA are 
constantly renegotiated for a same security gateways pair. At this time 
I'm not sure who's initiation the SA renegotioation: I'm sure remote 
side does, guys at the remote side are sure mine side does, and we kinda 
argue a lot about that.

2) I've tried to adding the "unique" level to the second set of SPs (and 
here's the question: do I need both sets to be "unique" or only second 
one ? As far as I understand "unique" add more fine-grained IDs to the 
policy. This means that it needs also fine-grained SA, but this is 
unclear for me - does it ?). This way packets cannot make into a tunnel, 
I suppose this is because the ipsec stack cannot find the SA with 
additional ID at it's end (am I right ?). Furthermore, the following 
records appear in the racoon log for each attempt to send the traffic 
matching the "unique" policy SPs:

May 20 20:56:53 dev racoon: [gateway A IP] ERROR: notification 
INVALID-ID-INFORMATION received in informational exchange.
May 20 20:56:53 dev racoon: [gateway A IP] ERROR: error message: 's Z > 
a n Q < 0 ] $ Q r I; G m O B r I* S DN N `' i EI a#y s e7 y PM #j ;8h` - 
; n i\9 = & o? + o & b'% t # c N ` = U 1P h80a ( Qwb~ } '.

it looks to me that the encrypted message wasn't decrypted properly. Is 
this some kind of bug or misconfiguration at either end ?

3) I also have a VPN tunnel to another ISP, which happened to use 
Checkpoint at their side. It has a similar configuration: one pair of 
security gateways, and 6 pairs of SP with different target networks, 
bound to one pair of security gateways mentioned, all with "require" 
policy. And they are working just fine. So, the question is - if the 
manual would use the RFC "MAY" and "SHOULD" syntax (I hope you 
understand what I'm referring to) - would the verb for "unique" vs 
"require" policy be "SHOULD use" or "MAY use" ? In other words -is the 
"unique" policy level mandatory for a situation when there's more than 
one pair of source/destination target networks for one set of security 
gateways ?

Thanks.

Eugene.

Re: [Ipsec-tools-devel] ERROR: pfkey DELETE received

[Eugene M. Z. <em...@no...>]

Hi.

On 23.10.2015 20:38, Rainer Weikusat wrote:
> "Eugene M. Zheganin" <em...@no...> writes:
>
>> Hi.
>>
>> I'm seeing the message "ERROR: pfkey DELETE received" quite periodically
>> in logs. However, it does not seem it to cause any problems. What does
>> this mean ?
> It means racoon has received a PF_KEY SADB_DELETE message whose process
> ID differed from its own, ie, one which was apparently not sent by
> itself.
>
Sorry for this grave digging, but I'm forced to reinvestigate this 
issue. Given that I have in the logs a record like

May  1 19:00:02 balancer1 racoon: ERROR: pfkey DELETE received: ESP 
XXX.XX.XXX.XX[500]->ZZZ.ZZ.ZZZ.ZZ[500] spi=831488614(0x318f8266)

- what can it mean ? XXX.XX.XXX.XX is a local IP of the server that 
logged this message. I think the '->' represents the direction, but if 
some message is "received" why the direction is outgoing ?
- if it's not the local racoon who's initiating the pfkey DELETE when 
who can it be ? I'm the only engineer having access to this server. I'm 
not issuing any SADB changes. I'm also not unsing any kind of 
DPD-initiated scripts, which could issue such changes. Yet I'm seeing 
these messages in logs. Is there any way of determining who was it ?

Thanks.
Eugene.

[Ipsec-tools-devel] ipsec-tools maintenance

[Christoph B. <bad...@bs...>]

Have you guys figured out how and where maintenance of the ipsec-tools is
going to be handled?

I saw Adam Majer's github repository but the last change to that was
almost a year ago and there are no pull requests.

I ask because I have some spare time starting the week after the next one
and could commit some patches to the NetBSD repository.

Also, if anyone wants to pick up the flag and get commit rights to the
NetBSD repository for ipsec-tools, I'd be willing to sponsor them.

--chris

Re: [Ipsec-tools-devel] [PATCH v3 0/5] Fix musl libc build issues

[Jörg K. <joe...@em...>]

On Mo, 2016-05-09 at 11:35 +0100, Rainer Weikusat wrote:
> Reinoud Koornstra <rei...@gm...> writes:
> > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause
> > <joe...@em...cks> wro
> 
> [...]
> 
> > > I do not have a strong opinion if __P should be removed or not.
> > 
> > Well, .... I don't really think it's necessary to keep.
> > However, NetBSD also has racoon and likely keeps __P.
> > Maybe for that sake we should keep it, not sure.
> 
> Removing __P means a huge 'coding style' change which is difficult/
> impossible to audit and doesn't add anything of value (at best).

Do you agree with the current patch for __P?

Best regards
Jörg Krause

Re: [Ipsec-tools-devel] [PATCH v3 4/5] Check for strtouq

[Jörg K. <joe...@em...>]

On Mo, 2016-05-09 at 18:14 +0100, Rainer Weikusat wrote:
> Jörg Krause <joe...@em...cks> writes:
> 
> [...]
> 
> > diff -purN ipsec-tools-0.8.2-3/configure.ac ipsec-tools-0.8.2-
> > 4/configure.ac
> > --- ipsec-tools-0.8.2-3/configure.ac	2016-05-08
> > 12:09:07.692445249 +0200
> > +++ ipsec-tools-0.8.2-4/configure.ac	2016-05-08
> > 12:11:17.661679674 +0200
> > @@ -124,7 +124,7 @@ AC_STRUCT_TM
> >  AC_FUNC_MEMCMP
> >  AC_TYPE_SIGNAL
> >  AC_FUNC_VPRINTF
> > -AC_CHECK_FUNCS(gettimeofday select socket strerror strtol strtoul
> > strlcpy strlcat)
> > +AC_CHECK_FUNCS(gettimeofday select socket strerror strtol strtoul
> > strtoull strtouq strlcpy strlcat)
> >  AC_REPLACE_FUNCS(strdup)
> >  RACOON_CHECK_VA_COPY
> >  
> > diff -purN ipsec-tools-0.8.2-3/src/racoon/misc.h ipsec-tools-0.8.2-
> > 4/src/racoon/misc.h
> > --- ipsec-tools-0.8.2-3/src/racoon/misc.h	2016-05-08
> > 12:09:28.132324323 +0200
> > +++ ipsec-tools-0.8.2-4/src/racoon/misc.h	2016-05-08
> > 12:11:17.661679674 +0200
> > @@ -75,6 +75,14 @@ extern void close_on_exec __P((int fd));
> >  #define strlcat(d,s,l) strncat(d,s,(l)-strlen(d)-1)
> >  #endif
> >  
> > +#ifndef HAVE_STRTOUQ
> > +#  ifdef HAVE_STRTOULL
> > +#    define strtouq strtoull
> > +#  elif HAVE_STRTOUL
> > +#    define strtouq strtoul
> > +#  endif
> > +#endif
> > +
> >  #define STRDUP_FATAL(x) if (x == NULL) {			\
> >  	plog(LLV_ERROR, LOCATION, NULL, "strdup failed\n");	
> > \
> >  	exit(1);						\
> 
> I had a closer look at the code:
> 
> strtouq is only used in backupsa.c and it's actually useless there
> because the return value is assigned to an u_int32_t. That's this
> code:
> 
>                 GETNEXTNUM(sa_args.l_bytes, strtouq);
>                 GETNEXTNUM(sa_args.l_addtime, strtouq);
>                 GETNEXTNUM(sa_args.l_usetime, strtouq);
> 
> and the structure definition is (libipsec/libpfkey.h)
> 
> struct pfkey_send_sa_args {
> 
> [...]
> 
>         u_int32_t       l_bytes;
>         u_int32_t       l_addtime;
>         u_int32_t       l_usetime;
> 
> 'lifebytes' is deprecated. The other two are both SA lifetimes in
> seconds either from date of creation (addtime) or date of first use
> (usetime). Considering that the values are unsigned, the maximum
> lifetime would be more than 130 years which ought to be sufficient
> for a
> ph2 SA. Consequently, I suggest to avoid this complication and just
> use
> strtoul.

Many thanks for looking at this!

> ---
> --- ipsec-tools-0.8.2/src/racoon/backupsa.c	2010-04-02
> 16:15:00.000000000 +0100
> +++ ipsec-tools-0.8.2.p/src/racoon/backupsa.c	2016-05-09
> 18:00:49.448253909 +0100
> @@ -276,9 +276,9 @@ do { 						
> 		\
>  		GETNEXTNUM(sa_args.a_keylen, strtoul);
>  		GETNEXTNUM(sa_args.flags, strtoul);
>  		GETNEXTNUM(sa_args.l_alloc, strtoul);
> -		GETNEXTNUM(sa_args.l_bytes, strtouq);
> -		GETNEXTNUM(sa_args.l_addtime, strtouq);
> -		GETNEXTNUM(sa_args.l_usetime, strtouq);
> +		GETNEXTNUM(sa_args.l_bytes, strtoul);
> +		GETNEXTNUM(sa_args.l_addtime, strtoul);
> +		GETNEXTNUM(sa_args.l_usetime, strtoul);
>  		GETNEXTNUM(sa_args.seq, strtoul);
>  
>  #undef GETNEXTNUM

Looks good to me! I'll update the patch soon...

Best regards
Jörg Krause

[Ipsec-tools-devel] some remarks about ph1 hash calculations

[Rainer W. <rwe...@mo...>]

This is published here in the hope that it's good for something. All
code examples are copyrighted by my employer and quoted as examples.

The oakley.c file contains a routine oakley_ph1hash_common which is used
to calculate and vertiy the hashes used for ph1 authentication. These
are defined as (code comment):

 *   I-digest = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b)
 *   R-digest = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1_b)

 I	-	initiator
 R	-	responder
 g^i	-	public DH/ initiator
 g^r	-	         / responder
 CKY-I	-	initiator cookie
 CKY-R  -	responder cookie
 SAi_b	-	SA payload (w/o general header) the initiator sent (_b
		 ::= body)
 ID_i1_b-	body of ph1 ID payload of the initiator
 ID_r1_b-	dito for responder

 | means 'concatenate', ie, copy byte-by-byte to a buffer from left to
 right

For validation, the responder needs to calculate the initiator hash and
vice versa.

The code is pretty complicated(-looking) because it's basically a
sequence of code blocks deciding which value to copy into the buffer
next depending on whether 'we' are R or I and need to calculate the R or
I hash, followed by (inline) code copying whatever needs to be copied in
this step. This can be greatly simplified by using some suitable data
structures,

enum {
	OHP_G_0,
	OHP_G_1,
	OHP_SA,
	OHP_ID_0,
	OHP_ID_1,

	N_OHPS
};

struct oakley_state {
	struct {
		size_t total;
		uint64_t cks[2];
		vchar_t *parts[N_OHPS];
	} hash_in;
		 
	vchar_t *hash;
};

If both responder and initiator values of something will or may be
needed (eg, cookies or ID payload bodies), there'll be a pair of values
and the first ("0th") member will be the one for 'us' and the second for
the other party of the negotiation. The hash calculation routine can
then use the following prototype:

vchar_t *oakley_ph1hash_common(struct ph1handle *iph1,
			       struct oakley_state *oak_state,
			       int side)

side == 0 means 'our hash', side == 1 'their hash'. The content of the
buffer can then be generated (based on helper functions for either
appending a sequence of bytes ['cookie'] or the content of a vchar_t) by

	bp = add_vc_to_buf(oak_state->hash_in.parts[OHP_G_0 + side], bp);
	bp = add_vc_to_buf(oak_state->hash_in.parts[OHP_G_0 + (side ^ 1)], bp);
	
	bp = add_to_buf(oak_state->hash_in.cks + side, sizeof(*oak_state->hash_in.cks), bp);
	bp = add_to_buf(oak_state->hash_in.cks + (side ^ 1), sizeof(*oak_state->hash_in.cks), bp);
	
	bp = add_vc_to_buf(oak_state->hash_in.parts[OHP_SA], bp);
	add_vc_to_buf(oak_state->hash_in.parts[OHP_ID_0 + side], bp);

bp (initially) pointing buffer of a sufficient size. The basic idea here is
that, assuming side is defined as above, the expression

	OHP_G_0 + side

is the array index of the g^x of the party whose hash is to be
calculated and

	OHP_G_0 + (side ^ 1)

is the index of the other g^x (similar for all other pairs).

Re: [Ipsec-tools-devel] [PATCH v3 4/5] Check for strtouq

[Rainer W. <rwe...@mo...>]

Jörg Krause <joe...@em...cks> writes:

[...]

> diff -purN ipsec-tools-0.8.2-3/configure.ac ipsec-tools-0.8.2-
> 4/configure.ac
> --- ipsec-tools-0.8.2-3/configure.ac	2016-05-08
> 12:09:07.692445249 +0200
> +++ ipsec-tools-0.8.2-4/configure.ac	2016-05-08
> 12:11:17.661679674 +0200
> @@ -124,7 +124,7 @@ AC_STRUCT_TM
>  AC_FUNC_MEMCMP
>  AC_TYPE_SIGNAL
>  AC_FUNC_VPRINTF
> -AC_CHECK_FUNCS(gettimeofday select socket strerror strtol strtoul
> strlcpy strlcat)
> +AC_CHECK_FUNCS(gettimeofday select socket strerror strtol strtoul
> strtoull strtouq strlcpy strlcat)
>  AC_REPLACE_FUNCS(strdup)
>  RACOON_CHECK_VA_COPY
>  
> diff -purN ipsec-tools-0.8.2-3/src/racoon/misc.h ipsec-tools-0.8.2-
> 4/src/racoon/misc.h
> --- ipsec-tools-0.8.2-3/src/racoon/misc.h	2016-05-08
> 12:09:28.132324323 +0200
> +++ ipsec-tools-0.8.2-4/src/racoon/misc.h	2016-05-08
> 12:11:17.661679674 +0200
> @@ -75,6 +75,14 @@ extern void close_on_exec __P((int fd));
>  #define strlcat(d,s,l) strncat(d,s,(l)-strlen(d)-1)
>  #endif
>  
> +#ifndef HAVE_STRTOUQ
> +#  ifdef HAVE_STRTOULL
> +#    define strtouq strtoull
> +#  elif HAVE_STRTOUL
> +#    define strtouq strtoul
> +#  endif
> +#endif
> +
>  #define STRDUP_FATAL(x) if (x == NULL) {			\
>  	plog(LLV_ERROR, LOCATION, NULL, "strdup failed\n");	\
>  	exit(1);						\

I had a closer look at the code:

strtouq is only used in backupsa.c and it's actually useless there
because the return value is assigned to an u_int32_t. That's this code:

                GETNEXTNUM(sa_args.l_bytes, strtouq);
                GETNEXTNUM(sa_args.l_addtime, strtouq);
                GETNEXTNUM(sa_args.l_usetime, strtouq);

and the structure definition is (libipsec/libpfkey.h)

struct pfkey_send_sa_args {

[...]

        u_int32_t       l_bytes;
        u_int32_t       l_addtime;
        u_int32_t       l_usetime;

'lifebytes' is deprecated. The other two are both SA lifetimes in
seconds either from date of creation (addtime) or date of first use
(usetime). Considering that the values are unsigned, the maximum
lifetime would be more than 130 years which ought to be sufficient for a
ph2 SA. Consequently, I suggest to avoid this complication and just use
strtoul.

---
--- ipsec-tools-0.8.2/src/racoon/backupsa.c	2010-04-02 16:15:00.000000000 +0100
+++ ipsec-tools-0.8.2.p/src/racoon/backupsa.c	2016-05-09 18:00:49.448253909 +0100
@@ -276,9 +276,9 @@ do { 								\
 		GETNEXTNUM(sa_args.a_keylen, strtoul);
 		GETNEXTNUM(sa_args.flags, strtoul);
 		GETNEXTNUM(sa_args.l_alloc, strtoul);
-		GETNEXTNUM(sa_args.l_bytes, strtouq);
-		GETNEXTNUM(sa_args.l_addtime, strtouq);
-		GETNEXTNUM(sa_args.l_usetime, strtouq);
+		GETNEXTNUM(sa_args.l_bytes, strtoul);
+		GETNEXTNUM(sa_args.l_addtime, strtoul);
+		GETNEXTNUM(sa_args.l_usetime, strtoul);
 		GETNEXTNUM(sa_args.seq, strtoul);
 
 #undef GETNEXTNUM

Re: [Ipsec-tools-devel] [PATCH v3 0/5] Fix musl libc build issues

[Reinoud K. <rei...@gm...>]

It doesn't matter too much what musl based system.
ipsec-tools now compiles and runs on a system with musl as c library,
that should include yours as well.
Best thing to do is download his patches, apply them, compile and run. :)
That's the best way, not too much effort to try I'd say.
Please let us know your experience.
Thanks,

Reinoud.

On Mon, May 9, 2016 at 4:19 AM, Anthony G. Basile
<ba...@op...> wrote:
> On 5/9/16 4:32 AM, Reinoud Koornstra wrote:
>> On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra
>> <rei...@gm...> wrote:
>>> On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...cks> wrote:
>>>> On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote:
>>>>> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em...
>>>>> cks> wrote:
>>>>>> This series of patches fix build issues with the musl C library
>>>>>> [1].
>>>>>>
>>>>>> musl is used as the default C library in OpenWRT and Alpine and is
>>>>>> supported by other Linux distros (Gentoo, Arch, Debian) and
>>>>>> projects
>>>>>> (Buildroot, Rust, ...).
>>>>>>
>>>>>> Short summary about the patches:
>>>>>> 1) Fix missing definition of __P() macro
>>>>>> 2) Remove unneeded <sys/sysctl.h>
>>>>>> 3) Check for GLOB_TILDE
>>>>>> 4) Check for strtouq
>>>>>> 5) Fix redirection of <sys/signal.h>
>>>>>>
>>>>>> As the projects CVS repository on sourceforge is outdated, I
>>>>>> created
>>>>>> the patches from the sources with the version 0.8.2.
>>>>>>
>>>>>> [1] http://www.musl-libc.org
>>>>>>
>>>>>> Changes v2 -> v3:
>>>>>>  * do not get rid of __P, but include the compatibility header
>>>>>> gnuc.h
>>>>>> whenever needed (suggested by Rainer Weikusat)
>>>>>
>>>>> Why keep the __P macro? it's ancient now and if musl can't deal with
>>>>> it, but compiles without it, then we should remove it if uclibc-ng,
>>>>> glibc and musl can compile all. You are suggesting to include gnuc.h
>>>>> in ipsec-tools?
>>>>> Also good with me, however, then we must maintain that file as well
>>>>> and keep it in check with newer versions.
>>>>> As of now I do not understand why we should keep __P, what does it
>>>>> bring us that we otherwise wouldn't have?
>>>>
>>>> The only feedback I got for the patch was from Rainer Weikusat, who
>>>> proposed to stay with __P and use the gnuc.h instead [1].
>>>>
>>>> Note, that gnuc.h is already part of ipsec-tools. It's in the racoon
>>>> subdirectory. I moved it, so it is available for the sources of the
>>>> other subdirectories.
>>>>
>>>> I do not have a strong opinion if __P should be removed or not.
>>>
>>> Well, .... I don't really think it's necessary to keep.
>>> However, NetBSD also has racoon and likely keeps __P.
>>> Maybe for that sake we should keep it, not sure.
>>>
>>>>
>>
>> I really like your patches though and I think they should be included in 0.8.3.
>> If Rainer is Ok with your patches I think I can safely include them in
>> the proposal for 0.8.3.
>
> I'm doing gentoo+musl, so I'm very interested in these patches.  Have
> they been tested and if so with what musl based system?
>
>>
>>
>>>> Btw, who is maintaining this project?
>>>>
>>>
>>> We all do in a way.
>>> I Proposed a patch for 0.8.3
>>> I need to spilt that patch up in different ones.
>>> Secondly, Rainer said there is still a leak present, but had no time
>>> yet to patch it up and logically didn't want 0.8.3 with that leak
>>> present.
>>> When he will publish the patch, I'll make a list of patches and submit it.
>>> Timo Terras offered to review it and create 0.8.3 as he's the lead.
>>> Despite what lots of people may think, there is still a fairly large
>>> community using ipsec-tools.
>>> By all means, if anybody will see something missing from the list that
>>> i'll propose, feel free to comment.
>>> Thanks,
>>>
>>> Reinoud.
>>>
>>>> [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/
>>
>> ------------------------------------------------------------------------------
>> Find and fix application performance issues faster with Applications Manager
>> Applications Manager provides deep performance insights into multiple tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> _______________________________________________
>> Ipsec-tools-devel mailing list
>> Ips...@li...
>> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
>>
>
>
> --
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel

Re: [Ipsec-tools-devel] [PATCH v3 0/5] Fix musl libc build issues

[Anthony G. B. <ba...@op...>]

On 5/9/16 4:32 AM, Reinoud Koornstra wrote:
> On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra
> <rei...@gm...> wrote:
>> On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...cks> wrote:
>>> On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote:
>>>> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joe...@em...
>>>> cks> wrote:
>>>>> This series of patches fix build issues with the musl C library
>>>>> [1].
>>>>>
>>>>> musl is used as the default C library in OpenWRT and Alpine and is
>>>>> supported by other Linux distros (Gentoo, Arch, Debian) and
>>>>> projects
>>>>> (Buildroot, Rust, ...).
>>>>>
>>>>> Short summary about the patches:
>>>>> 1) Fix missing definition of __P() macro
>>>>> 2) Remove unneeded <sys/sysctl.h>
>>>>> 3) Check for GLOB_TILDE
>>>>> 4) Check for strtouq
>>>>> 5) Fix redirection of <sys/signal.h>
>>>>>
>>>>> As the projects CVS repository on sourceforge is outdated, I
>>>>> created
>>>>> the patches from the sources with the version 0.8.2.
>>>>>
>>>>> [1] http://www.musl-libc.org
>>>>>
>>>>> Changes v2 -> v3:
>>>>>  * do not get rid of __P, but include the compatibility header
>>>>> gnuc.h
>>>>> whenever needed (suggested by Rainer Weikusat)
>>>>
>>>> Why keep the __P macro? it's ancient now and if musl can't deal with
>>>> it, but compiles without it, then we should remove it if uclibc-ng,
>>>> glibc and musl can compile all. You are suggesting to include gnuc.h
>>>> in ipsec-tools?
>>>> Also good with me, however, then we must maintain that file as well
>>>> and keep it in check with newer versions.
>>>> As of now I do not understand why we should keep __P, what does it
>>>> bring us that we otherwise wouldn't have?
>>>
>>> The only feedback I got for the patch was from Rainer Weikusat, who
>>> proposed to stay with __P and use the gnuc.h instead [1].
>>>
>>> Note, that gnuc.h is already part of ipsec-tools. It's in the racoon
>>> subdirectory. I moved it, so it is available for the sources of the
>>> other subdirectories.
>>>
>>> I do not have a strong opinion if __P should be removed or not.
>>
>> Well, .... I don't really think it's necessary to keep.
>> However, NetBSD also has racoon and likely keeps __P.
>> Maybe for that sake we should keep it, not sure.
>>
>>>
> 
> I really like your patches though and I think they should be included in 0.8.3.
> If Rainer is Ok with your patches I think I can safely include them in
> the proposal for 0.8.3.

I'm doing gentoo+musl, so I'm very interested in these patches.  Have
they been tested and if so with what musl based system?

> 
> 
>>> Btw, who is maintaining this project?
>>>
>>
>> We all do in a way.
>> I Proposed a patch for 0.8.3
>> I need to spilt that patch up in different ones.
>> Secondly, Rainer said there is still a leak present, but had no time
>> yet to patch it up and logically didn't want 0.8.3 with that leak
>> present.
>> When he will publish the patch, I'll make a list of patches and submit it.
>> Timo Terras offered to review it and create 0.8.3 as he's the lead.
>> Despite what lots of people may think, there is still a fairly large
>> community using ipsec-tools.
>> By all means, if anybody will see something missing from the list that
>> i'll propose, feel free to comment.
>> Thanks,
>>
>> Reinoud.
>>
>>> [1] https://sourceforge.net/p/ipsec-tools/mailman/message/35036132/
> 
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
> 


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [Ipsec-tools-devel] [PATCH v3 0/5] Fix musl libc build issues

[Rainer W. <rwe...@mo...>]

Reinoud Koornstra <rei...@gm...> writes:
> On Mon, May 9, 2016 at 1:19 AM, Jörg Krause
> <joe...@em...cks> wro

[...]

>> I do not have a strong opinion if __P should be removed or not.
>
> Well, .... I don't really think it's necessary to keep.
> However, NetBSD also has racoon and likely keeps __P.
> Maybe for that sake we should keep it, not sure.

Removing __P means a huge 'coding style' change which is difficult/
impossible to audit and doesn't add anything of value (at best).

Re: [Ipsec-tools-devel] [PATCH v3 0/5] Fix musl libc build issues

[Reinoud K. <rei...@gm...>]

On Mon, May 9, 2016 at 2:47 AM, Jörg Krause <joe...@em...cks> wrote:
> On Mo, 2016-05-09 at 02:32 -0600, Reinoud Koornstra wrote:
>> On Mon, May 9, 2016 at 2:28 AM, Reinoud Koornstra
>> <rei...@gm...> wrote:
>> > On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joerg.krause@embedded.
>> > rocks> wrote:
>> > > On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote:
>> > > > On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joerg.krause@embed
>> > > > ded.ro
>> > > > cks> wrote:
>> > > > > This series of patches fix build issues with the musl C
>> > > > > library
>> > > > > [1].
>> > > > >
>> > > > > musl is used as the default C library in OpenWRT and Alpine
>> > > > > and is
>> > > > > supported by other Linux distros (Gentoo, Arch, Debian) and
>> > > > > projects
>> > > > > (Buildroot, Rust, ...).
>> > > > >
>> > > > > Short summary about the patches:
>> > > > > 1) Fix missing definition of __P() macro
>> > > > > 2) Remove unneeded <sys/sysctl.h>
>> > > > > 3) Check for GLOB_TILDE
>> > > > > 4) Check for strtouq
>> > > > > 5) Fix redirection of <sys/signal.h>
>> > > > >
>> > > > > As the projects CVS repository on sourceforge is outdated, I
>> > > > > created
>> > > > > the patches from the sources with the version 0.8.2.
>> > > > >
>> > > > > [1] http://www.musl-libc.org
>> > > > >
>> > > > > Changes v2 -> v3:
>> > > > >  * do not get rid of __P, but include the compatibility
>> > > > > header
>> > > > > gnuc.h
>> > > > > whenever needed (suggested by Rainer Weikusat)
>> > > >
>> > > > Why keep the __P macro? it's ancient now and if musl can't deal
>> > > > with
>> > > > it, but compiles without it, then we should remove it if
>> > > > uclibc-ng,
>> > > > glibc and musl can compile all. You are suggesting to include
>> > > > gnuc.h
>> > > > in ipsec-tools?
>> > > > Also good with me, however, then we must maintain that file as
>> > > > well
>> > > > and keep it in check with newer versions.
>> > > > As of now I do not understand why we should keep __P, what does
>> > > > it
>> > > > bring us that we otherwise wouldn't have?
>> > >
>> > > The only feedback I got for the patch was from Rainer Weikusat,
>> > > who
>> > > proposed to stay with __P and use the gnuc.h instead [1].
>> > >
>> > > Note, that gnuc.h is already part of ipsec-tools. It's in the
>> > > racoon
>> > > subdirectory. I moved it, so it is available for the sources of
>> > > the
>> > > other subdirectories.
>> > >
>> > > I do not have a strong opinion if __P should be removed or not.
>> >
>> > Well, .... I don't really think it's necessary to keep.
>> > However, NetBSD also has racoon and likely keeps __P.
>> > Maybe for that sake we should keep it, not sure.
>> >
>> > >
>>
>> I really like your patches though and I think they should be included
>> in 0.8.3.
>> If Rainer is Ok with your patches I think I can safely include them
>> in
>> the proposal for 0.8.3.
>
> You're welcome!
>
> There might be an issue with simply replacing strtouq with strtoul or
> strtoull if strtouq is not available [1]. I guess autoconf should check
> for the size of unsigned long long and unsigned long, too.

that would be good indeed.
As resilient as possible. :)

>
> [1] http://lists.busybox.net/pipermail/buildroot/2016-May/160719.html

Re: [Ipsec-tools-devel] [PATCH v3 0/5] Fix musl libc build issues

[Jörg K. <joe...@em...>]

On Mo, 2016-05-09 at 02:28 -0600, Reinoud Koornstra wrote:
> On Mon, May 9, 2016 at 1:19 AM, Jörg Krause <joe...@em...
> cks> wrote:
> > On So, 2016-05-08 at 23:34 -0600, Reinoud Koornstra wrote:
> >> On Sun, May 8, 2016 at 4:43 AM, Jörg Krause <joerg.krause@embedded
> .ro
> >> cks> wrote:
> >> > This series of patches fix build issues with the musl C library
> >> > [1].
> >> >
> >> > musl is used as the default C library in OpenWRT and Alpine and
> is
> >> > supported by other Linux distros (Gentoo, Arch, Debian) and
> >> > projects
> >> > (Buildroot, Rust, ...).
> >> >
> >> > Short summary about the patches:
> >> > 1) Fix missing definition of __P() macro
> >> > 2) Remove unneeded <sys/sysctl.h>
> >> > 3) Check for GLOB_TILDE
> >> > 4) Check for strtouq
> >> > 5) Fix redirection of <sys/signal.h>
> >> >
> >> > As the projects CVS repository on sourceforge is outdated, I
> >> > created
> >> > the patches from the sources with the version 0.8.2.
> >> >
> >> > [1] http://www.musl-libc.org
> >> >
> >> > Changes v2 -> v3:
> >> >  * do not get rid of __P, but include the compatibility header
> >> > gnuc.h
> >> > whenever needed (suggested by Rainer Weikusat)
> >>
> >> Why keep the __P macro? it's ancient now and if musl can't deal
> with
> >> it, but compiles without it, then we should remove it if uclibc-
> ng,
> >> glibc and musl can compile all. You are suggesting to include
> gnuc.h
> >> in ipsec-tools?
> >> Also good with me, however, then we must maintain that file as
> well
> >> and keep it in check with newer versions.
> >> As of now I do not understand why we should keep __P, what does it
> >> bring us that we otherwise wouldn't have?
> >
> > The only feedback I got for the patch was from Rainer Weikusat, who
> > proposed to stay with __P and use the gnuc.h instead [1].
> >
> > Note, that gnuc.h is already part of ipsec-tools. It's in the
> racoon
> > subdirectory. I moved it, so it is available for the sources of the
> > other subdirectories.
> >
> > I do not have a strong opinion if __P should be removed or not.
> 
> Well, .... I don't really think it's necessary to keep.
> However, NetBSD also has racoon and likely keeps __P.
> Maybe for that sake we should keep it, not sure.
> 
> >
> > Btw, who is maintaining this project?
> >
> 
> We all do in a way.
> I Proposed a patch for 0.8.3
> I need to spilt that patch up in different ones.
> Secondly, Rainer said there is still a leak present, but had no time
> yet to patch it up and logically didn't want 0.8.3 with that leak
> present.
> When he will publish the patch, I'll make a list of patches and
> submit it.
> Timo Terras offered to review it and create 0.8.3 as he's the lead.
> Despite what lots of people may think, there is still a fairly large
> community using ipsec-tools.

That's good news!

> By all means, if anybody will see something missing from the list
> that
> i'll propose, feel free to comment.

Is there an up-to-date repository (preferable git)? This would ease
patch creation.

Best regards
Jörg Krause