2011-10-21 03:58:44

by satpal parmar

[permalink] [raw]
Subject: Cryptoapi: H/W accelerator/ IPsec interfaces

Hi All
I am trying to work Openswan IPsec(2.6.33) ?(NETKEY) with?NSS H/W
cryptodrivers??for ARM cortex based SoC running linux 2.6.37. I am
facing this weird?problem?where when I ping I see (wireshark) ESP
packets going ?both side but I am not?receiving anything on?either
side. See the log below.I could have assumed its h/W driver problem
but since?its?happening?on both of?tunnel I am not able to conclude
anything. Things are working fine without h/w?accelerator drivers.
I am new user of ?cryptoapi and have little idea on its internals. I
appreciate?if?anyone?can help me understand:
1.How/where/when (api level) ?IPsec ?request services of Crptoapi .
2.How/where/when?Cryptoapi request services from H/W accelerators
drivers registered to it.
Any suggestion/pointers to resolve my problem will be a plus.
Thanks in advance.
SP
++++++++++++++++++++++++++++++++++++
LOG
++++++++++++++++
[email protected]# dmesg | grep nss
nss_rng nss_rng: NSS Random Number Generator ver. 2.0
nss_aes_mod_init: loading NSS AES driver
nss-aes nss-aes: NSS AES hw accel rev: 3.2 (context 0 @0x41140000)
nss-aes nss-aes: NSS AES hw accel rev: 3.2 (context 1 @0x41141000)
nss-aes nss-aes: NSS AES hw accel rev: 3.2 (context 2 @0x411a0000)
nss-aes nss-aes: NSS AES hw accel rev: 3.2 (context 3 @0x411a1000)
nss_aes_probe: probe() done
nss_des_mod_init: loading NSS DES driver
nss-des nss-des: NSS DES hw accel rev: 2.2 (context 0 @0x41160000)
nss-des nss-des: NSS DES hw accel rev: 2.2 (context 1 @0x41161000)
nss_des_probe: probe() done
nss_sham_mod_init: loading NSS SHA/MD5 driver
nss-sham nss-sham: NSS SHA/MD5 hw accel rev: 4.3 (context 0 @0x41100000)
nss-sham nss-sham: NSS SHA/MD5 hw accel rev: 4.3 (context 1 @0x41101000)
nss-sham nss-sham: NSS SHA/MD5 hw accel rev: 4.3 (context 2 @0x411c0000)
nss-sham nss-sham: NSS SHA/MD5 hw accel rev: 4.3 (context 3 @0x411c1000)
nss_sham_probe: probe() done

[email protected]# ping 192.168.11.45
----------------------------------->Before IPSEC
PING 192.168.11.45 (192.168.11.45): 56 data bytes
64 bytes from?192.168.11.45: seq=0 ttl=63 time=10.186 ms
64 bytes from?192.168.11.45: seq=1 ttl=63 time=0.483 ms
64 bytes from?192.168.11.45: seq=2 ttl=63 time=0.323 ms
64 bytes from?192.168.11.45: seq=3 ttl=63 time=0.304 ms
^C
--- 192.168.11.45 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.304/2.824/10.186 ms
[email protected]# cp /home/ipsec.secrets /etc/
[email protected]# sh /home/ipsec.secrets
/home/ipsec.secrets: line 1:?192.168.11.45: not found
[email protected]# sh /home/ipsec.secrets
/home/ipsec.secrets: line 1:?192.168.11.45: not found
[email protected]# sh /home/start_ipsec.sh
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: stop ordered, but IPsec appears to be already stopped!
ipsec_setup: doing cleanup anyway...
ipsec_setup: Starting Openswan IPsec U2.6.33/K2.6.37-svn2529...
104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: ignoring unknown Vendor ID payload [4f456d406b6753464548407f]
003 "test" #1: received Vendor ID payload [Dead Peer Detection]
003 "test" #1: received Vendor ID payload [RFC 3947] method set to=109
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
no NAT detected
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "test" #1: received Vendor ID payload [CAN-IKEv2]
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha
group=modp2048}
117 "test" #2: STATE_QUICK_I1: initiate
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0x0f41cfe1 <0x083a512b xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=none DPD=none}

[email protected]# /etc/init.d/ipsec status
IPsec running ?- pluto pid: 477
pluto pid 477
2 tunnels up
some eroutes exist
[email protected]# ping 192.168.11.45
PING 192.168.11.45 (192.168.11.45): 56 data bytes
^C
--- 192.168.11.45 ping statistics ---
68 packets transmitted, 0 packets received, 100% packet
loss------------>after ipsec.