<div dir="ltr">Helllo ,<br><br><div class="gmail_quote">On Thu, Apr 1, 2010 at 2:31 AM, David McCullough <span dir="ltr"><<a href="mailto:david_mccullough@mcafee.com">david_mccullough@mcafee.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Jivin avital sela lays it down ...<br>
<div class="im">> Hello Paul,<br>
><br>
><br>
> On Wed, Mar 17, 2010 at 8:56 PM, Paul Wouters <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> wrote:<br>
><br>
><br>
> On Wed, 17 Mar 2010, avital sela wrote:<br>
><br>
><br>
><br>
> I recently built KLIPS stack to a 2.6.29.6 based kernel. The module<br>
> loads fine but when I tried to use setkey to setup a tunnel manually<br>
><br>
><br>
><br>
> KLIPS uses the PFKEY interface, not the NETLINK/XFRM interface, so setkey<br>
> and other ipsec-tools utilities and the kernel XFRM utilities (ip xfrm)<br>
> do not work with these.<br>
><br>
> Instead, see "ipsec --help" for commands or look at /proc/net/ipsec/<br>
><br>
><br>
><br>
> Thanks. I created a simple ipsec.conf file and am able to successfuly ping packets across the tunnel.<br>
><br>
> When I added support for OCF (I'm using cryptosoft driver for now) I get the following messages all the time<br>
> KLIPS klips_debug:ipsec_rcv: auth failed on incoming packet from 192.168.16.124 (replay=4): calculated hash=000040210000000000000200 received hash=ae4383e40fca800003d1f1ac, dropped<br>
<br>
<br>
</div>I have another report of this on the ocf-linux mailing list. Something must<br>
have gone astray in the last round of cryptosoft updates. cryptosoft was<br>
pretty much rewritten for this release (I am assuming you are using the 2010<br>
ocf release ?).<br></blockquote><div class="im"> <br>Yes, ocf-linux-26-20100325.patch , openswan-2.6.25<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
</blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">> 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.<br>
> Is it just a misunderstanding on my part or are the printk variables in the following code snippet from ipsec_rcv reversed<br>
<br>
<br>
</div>I check when I look at it today, but the first hash result is obviously<br>
busted :-(<br>
<div class="im"><br>
> if (memcmp(irs->hash, irs->authenticator, irs->authlen)) {<br>
> irs->ipsp->ips_errs.ips_auth_errs += 1;<br>
> KLIPS_ERROR(debug_rcv & DB_RX_INAU,<br>
> "klips_debug:ipsec_rcv: "<br>
> "auth failed on incoming packet from %s (replay=%d): calculated hash=%08x%08x%08x received hash=%08x%08x%08x, dropped\n",<br>
> irs->ipsaddr_txt,<br>
> irs->replay,<br>
> ntohl(*(__u32*)&irs->hash[0]),<br>
> ntohl(*(__u32*)&irs->hash[4]),<br>
> ntohl(*(__u32*)&irs->hash[8]),<br>
> ntohl(*(__u32*)irs->authenticator),<br>
> ntohl(*((__u32*)irs->authenticator + 1)),<br>
> ntohl(*((__u32*)irs->authenticator + 2)));<br>
> if(irs->stats) {<br>
> irs->stats->rx_dropped++;<br>
> }<br>
<br>
</div>Just for reference, is this an x86 system ? SMP ?<br>
<br></blockquote><div><br>mips (24k) uniprocessor with RT patch.<br><br><br>Thanks ,<br>Avital<br><br></div></div></div>