[Openswan Users] klips and setkey

[avital sela]

Helllo ,

On Thu, Apr 1, 2010 at 2:31 AM, David McCullough <
david_mccullough at mcafee.com> wrote:

>
> Jivin avital sela lays it down ...
> > Hello Paul,
> >
> >
> > On Wed, Mar 17, 2010 at 8:56 PM, Paul Wouters <paul at xelerance.com>
> wrote:
> >
> >
> >       On Wed, 17 Mar 2010, avital sela wrote:
> >
> >
> >
> >               I recently built KLIPS stack to a 2.6.29.6 based kernel.
> The module
> >               loads fine but when I tried to use setkey to setup a tunnel
> manually
> >
> >
> >
> >       KLIPS uses the PFKEY interface, not the NETLINK/XFRM interface, so
> setkey
> >       and other ipsec-tools utilities and the kernel XFRM utilities (ip
> xfrm)
> >       do not work with these.
> >
> >       Instead, see "ipsec --help" for commands or look at
> /proc/net/ipsec/
> >
> >
> >
> > Thanks. I created a simple ipsec.conf file and am able to successfuly
> ping packets across the tunnel.
> >
> > When I added support for OCF (I'm using cryptosoft driver for now) I get
> the following messages all the time
> > KLIPS klips_debug:ipsec_rcv: auth failed on incoming packet from
> 192.168.16.124 (replay=4): calculated hash=000040210000000000000200 received
> hash=ae4383e40fca800003d1f1ac, dropped
>
>
> I have another report of this on the ocf-linux mailing list.  Something
> must
> have gone astray in the last round of cryptosoft updates.  cryptosoft was
> pretty much rewritten for this release (I am assuming you are using the
> 2010
> ocf release ?).
>

Yes, ocf-linux-26-20100325.patch , openswan-2.6.25

>

> > In the message above I thought that "calculated hash" was the value
> computed by the crypto sub-system and the "received hash" is the value that
> was placed in the packet by the sender. Looking at the actual packets using
> Wireshark it seems that its actually the other way around.
> > Is it just a misunderstanding on my part or are the printk variables in
> the following code snippet from ipsec_rcv reversed
>
>
> I check when I look at it today,  but the first hash result is obviously
> busted :-(
>
> > if (memcmp(irs->hash, irs->authenticator, irs->authlen)) {
> >                         irs->ipsp->ips_errs.ips_auth_errs += 1;
> >                         KLIPS_ERROR(debug_rcv & DB_RX_INAU,
> >                                     "klips_debug:ipsec_rcv: "
> >                                     "auth failed on incoming packet from
> %s (replay=%d): calculated hash=%08x%08x%08x received hash=%08x%08x%08x,
> dropped\n",
> >                                     irs->ipsaddr_txt,
> >                                     irs->replay,
> >                                     ntohl(*(__u32*)&irs->hash[0]),
> >                                     ntohl(*(__u32*)&irs->hash[4]),
> >                                     ntohl(*(__u32*)&irs->hash[8]),
> >                                     ntohl(*(__u32*)irs->authenticator),
> >                                     ntohl(*((__u32*)irs->authenticator +
> 1)),
> >                                     ntohl(*((__u32*)irs->authenticator +
> 2)));
> >                         if(irs->stats) {
> >                                 irs->stats->rx_dropped++;
> >                         }
>
> Just for reference,  is this an x86 system ?  SMP ?
>
>
mips (24k) uniprocessor with RT patch.


Thanks ,
Avital
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20100401/d4838b3f/attachment.html