ipsec-tools 0.1 + kernel 2.5.64

ipsec-tools 0.1 + kernel 2.5.64

[Andreas Jellinghaus]

Hi,

both manual keying and automatic keying with racoon (pre-shared secret)
are working fine. No need to patch or modify anything. 
I tried only ipv4.

But: don't "setkey -DP" while racoon is running, it crashes
my machine. Sorry, could not get any details.

Andreas

Re: ipsec-tools 0.1 + kernel 2.5.64

[bert hubert]

On Wed, Mar 05, 2003 at 12:29:12PM +0100, Andreas Jellinghaus wrote:
> Hi,
> 
> both manual keying and automatic keying with racoon (pre-shared secret)
> are working fine. No need to patch or modify anything. 
> I tried only ipv4.

By the way, regarding ipsec-tools 0.1, are you sure you want to fork the
projects involved?

By the way, you did not mention it here but ipsec-tools is available on
http://sourceforge.net/projects/ipsec-tools , I also link them from
http://lartc.org/howto/lartc.ipsec.html

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

Re: ipsec-tools 0.1 + kernel 2.5.64

[Derek Atkins]

bert hubert <ahu@ds9a.nl> writes:

> On Wed, Mar 05, 2003 at 12:29:12PM +0100, Andreas Jellinghaus wrote:
> > Hi,
> > 
> > both manual keying and automatic keying with racoon (pre-shared secret)
> > are working fine. No need to patch or modify anything. 
> > I tried only ipv4.
> 
> By the way, regarding ipsec-tools 0.1, are you sure you want to fork the
> projects involved?

I spoke to the KAME people and unfortunately, at least for now, there
is no other choice but to fork.  Perhaps down the road we can merge,
but as of last week they don't want to host a linux package.  They are
willing to take some of our patches, but that doesn't help with a
build system.

> By the way, you did not mention it here but ipsec-tools is available on
> http://sourceforge.net/projects/ipsec-tools , I also link them from
> http://lartc.org/howto/lartc.ipsec.html

I didn't?   Perhaps I said ipsec-tool.sourceforge.net which has a
link to sourceforge.net/projects/ipsec-tools and is much shorter
to type. ;) 

> Regards,
> 
> bert

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

Re: ipsec-tools 0.1 + kernel 2.5.64

[James Morris]

On 5 Mar 2003, Andreas Jellinghaus wrote:

> But: don't "setkey -DP" while racoon is running, it crashes
> my machine. Sorry, could not get any details.

Please apply the patch in this message:
http://marc.theaimsgroup.com/?l=linux-netdev&m=104669387317759&w=2


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: ipsec-tools 0.1 + kernel 2.5.64

[Andreas Jellinghaus]

> Please apply the patch in this message:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=104669387317759&w=2

Thanks, now everything is working fine!

Andreas

ipsec-tools 0.1 + kernel 2.5.64

[Kostadin Karaivanov]

>Hi,
>
>both manual keying and automatic keying with racoon (pre-shared secret)
>are working fine. No need to patch or modify anything. 
>I tried only ipv4.
>
>But: don't "setkey -DP" while racoon is running, it crashes
>my machine. Sorry, could not get any details.
This problem is present for me since 2.5.59, but once I get kernel oops
right after "setkey -DP" and before crash, it is on real tty not ssh or telnet,
on ssh/telnet console there is nothing exept freeze of course :-), I never tried 
serial console to catch the oops
>
>Andreas
BTW "ipsec-tools 0.1" from where ???

wwell Larry

Re: ipsec-tools 0.1 + kernel 2.5.64

[Kostadin Karaivanov]

Kostadin Karaivanov wrote:

>> Hi,
>>
>> both manual keying and automatic keying with racoon (pre-shared secret)
>> are working fine. No need to patch or modify anything. I tried only 
>> ipv4.
>>
>> But: don't "setkey -DP" while racoon is running, it crashes
>> my machine. Sorry, could not get any details.
>
>>
>> Andreas
>
> BTW "ipsec-tools 0.1" from where ??? 

   If you mention www.sf.net/projects/ipsec-tools
   they does not compiles for me I cot following error

grabmyaddr.c:69:1: warning: "HAVE_GETIFADDRS" redefined
<command line>:1:1: warning: this is the location of the previous definition
grabmyaddr.c:88: redefinition of `struct ifaddrs'
grabmyaddr.c:200: warning: static declaration for `getifaddrs' follows 
non-static
grabmyaddr.c:254: warning: static declaration for `freeifaddrs' follows 
non-static
make[3]: *** [grabmyaddr.o] Error 1
make[3]: Leaving directory `/usr/src/ipsec-tools-0.1/src/racoon'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/ipsec-tools-0.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/ipsec-tools-0.1'
make: *** [all] Error 2

  I can provide additional info if needed (gcc-3.2.2)

>
>
> wwell Larry
>
>

Re: ipsec-tools 0.1 + kernel 2.5.64

[Derek Atkins]

Hi,

>   If you mention www.sf.net/projects/ipsec-tools
>   they does not compiles for me I cot following error

Yes, this is what we mean...

> grabmyaddr.c:69:1: warning: "HAVE_GETIFADDRS" redefined
> <command line>:1:1: warning: this is the location of the previous definition
> grabmyaddr.c:88: redefinition of `struct ifaddrs'
> grabmyaddr.c:200: warning: static declaration for `getifaddrs' follows
> non-static
> grabmyaddr.c:254: warning: static declaration for `freeifaddrs' follows
> non-static
> make[3]: *** [grabmyaddr.o] Error 1
> make[3]: Leaving directory `/usr/src/ipsec-tools-0.1/src/racoon'

Hmm...  What version of glibc are you using?  This seems to imply that
getifaddrs() and freeifaddrs() is now in libc, where it wasn't before.
I didn't know it got added -- I wonder when that happened?

>   I can provide additional info if needed (gcc-3.2.2) 

Please.  Feel free to follow up personally rather than to this list
(or at least be sure to CC me on all your replies, as I'm not actually
subscribed directly).

Can you try this patch and see if that fixes the problem?

diff -u -r1.3 grabmyaddr.c
--- src/racoon/grabmyaddr.c	3 Mar 2003 23:56:56 -0000	1.3
+++ src/racoon/grabmyaddr.c	5 Mar 2003 18:12:28 -0000
@@ -65,7 +65,7 @@
 #include "isakmp_var.h"
 #include "gcmalloc.h"
 
-#ifdef __linux__
+#if defined(__linux__) && !defined(HAVE_GETIFADDRS)
 #define HAVE_GETIFADDRS
 #endif
 
@@ -78,7 +78,7 @@
 static int suitable_ifaddr6 __P((const char *, const struct sockaddr *));
 #endif
 
-#ifdef __linux__
+#if defined(__linux__) && !defined(HAVE_GETIFADDRS)
 
 /* We could do this _much_ better. kame racoon in its current form
  * will esentially die at frequent changes of address configuration.

Thanks,

-derek, ipsec-tools maintainer
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com

Re: ipsec-tools 0.1 + kernel 2.5.64

[Christoph Hellwig]

On Wed, Mar 05, 2003 at 01:15:00PM -0500, Derek Atkins wrote:
> Hmm...  What version of glibc are you using?  This seems to imply that
> getifaddrs() and freeifaddrs() is now in libc, where it wasn't before.
> I didn't know it got added -- I wonder when that happened?

It's new in glibc 2.3

>  
> @@ -78,7 +78,7 @@
>  static int suitable_ifaddr6 __P((const char *, const struct sockaddr *));
>  #endif
>  
> -#ifdef __linux__
> +#if defined(__linux__) && !defined(HAVE_GETIFADDRS)

#ifdef <OS> is a very bad style.  As you're already using autoconf
I'd suggest just checking for HAVE_GETIFADDRS

Re: ipsec-tools 0.1 + kernel 2.5.64

[Derek Atkins]

Christoph Hellwig <hch@infradead.org> writes:

> It's new in glibc 2.3

Ahh.. Thanks.  I'm still using older versions myself.

> #ifdef <OS> is a very bad style.  As you're already using autoconf
> I'd suggest just checking for HAVE_GETIFADDRS

Well, the problem is that the replacement function is only valid on
Linux, so I need to have the <OS> test in there anyways.  It may be
"bad style", but the test needs to exist _somewhere_.  Besides, I've
never been one to be convinced to do something purely based on
stylistic arguments.  Give me a real technical reason why it needs to
be different and I'll consider changing it.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available

Re: ipsec-tools 0.1 + kernel 2.5.64

[Christoph Hellwig]

On Wed, Mar 05, 2003 at 01:43:30PM -0500, Derek Atkins wrote:
> Well, the problem is that the replacement function is only valid on
> Linux, so I need to have the <OS> test in there anyways.

It's probably not valid on Linux but on OSes that support the functionality
you use to implement it.  It might e.g. work on the Hurd that uses old
Linux networking code.

> It may be
> "bad style", but the test needs to exist _somewhere_.  Besides, I've
> never been one to be convinced to do something purely based on
> stylistic arguments.  Give me a real technical reason why it needs to
> be different and I'll consider changing it.

Checking for OSes is wrong because you couldn't care less for the
OS, you care for the functionality that is provided.  This is the
nice idea behind autoconf (the implementation of autoconf is a completly
different issue, though).

Re: ipsec-tools 0.1 + kernel 2.5.64

[Derek Atkins]

Christoph Hellwig <hch@infradead.org> writes:

> On Wed, Mar 05, 2003 at 01:43:30PM -0500, Derek Atkins wrote:
> > Well, the problem is that the replacement function is only valid on
> > Linux, so I need to have the <OS> test in there anyways.
> 
> It's probably not valid on Linux but on OSes that support the functionality
> you use to implement it.  It might e.g. work on the Hurd that uses old
> Linux networking code.

I find it extremely unlikely that the hurd would have the include file
<linux/rtnetlink.h>, which is part of the code chunk in question.  As
I said, the code is extremely linux-specific.

> Checking for OSes is wrong because you couldn't care less for the
> OS, you care for the functionality that is provided.  This is the
> nice idea behind autoconf (the implementation of autoconf is a completly
> different issue, though).

As I said, the current code is OS specific.  I find is EXTREMELY
unlikely it would work on anything that isn't Linux.  I wont argue
about autoconf implementation.

However, I will acknowledge that my original patch was broken.  Here
is a better one.  This should work on both pre- and post- glibc-2.3
linux systems.

-derek

diff -u -r1.3 -r1.4
--- src/racoon/grabmyaddr.c	3 Mar 2003 23:56:56 -0000	1.3
+++ src/racoon/grabmyaddr.c	5 Mar 2003 18:54:08 -0000	1.4
@@ -65,8 +65,9 @@
 #include "isakmp_var.h"
 #include "gcmalloc.h"
 
-#ifdef __linux__
+#if defined(__linux__) && !defined(HAVE_GETIFADDRS)
 #define HAVE_GETIFADDRS
+#define NEED_LINUX_GETIFADDRS
 #endif
 
 #ifndef HAVE_GETIFADDRS
@@ -78,7 +79,7 @@
 static int suitable_ifaddr6 __P((const char *, const struct sockaddr *));
 #endif
 
-#ifdef __linux__
+#ifdef NEED_LINUX_GETIFADDRS
 
 /* We could do this _much_ better. kame racoon in its current form
  * will esentially die at frequent changes of address configuration.

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com

Re: ipsec-tools 0.1 + kernel 2.5.64

[Derek Atkins]

Sorry, that was the wrong patch.

Try this one.

-derek

diff -u -r1.4 grabmyaddr.c
--- src/racoon/grabmyaddr.c	5 Mar 2003 18:54:08 -0000	1.4
+++ src/racoon/grabmyaddr.c	5 Mar 2003 19:54:17 -0000
@@ -65,10 +65,13 @@
 #include "isakmp_var.h"
 #include "gcmalloc.h"
 
-#if defined(__linux__) && !defined(HAVE_GETIFADDRS)
+#ifdef __linux__
+#include <linux/rtnetlink.h>
+ifndef HAVE_GETIFADDRS
 #define HAVE_GETIFADDRS
 #define NEED_LINUX_GETIFADDRS
 #endif
+#endif
 
 #ifndef HAVE_GETIFADDRS
 static unsigned int if_maxindex __P((void));
@@ -93,8 +96,6 @@
 	struct sockaddr *ifa_addr;
 	struct sockaddr_storage ifa_addrbuf;
 };
-
-#include <linux/rtnetlink.h>
 
 __u32 nl_pid;
 int nl_rescan;


-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com