Cryptoapi: H/W accelerator/ IPsec interfaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
++++++++++++++++
root@R3BTS-CP-PFS1.0# 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

root@R3BTS-CP-PFS1.0# 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
root@R3BTS-CP-PFS1.0# cp /home/ipsec.secrets /etc/
root@R3BTS-CP-PFS1.0# sh /home/ipsec.secrets
/home/ipsec.secrets: line 1: 192.168.11.45: not found
root@R3BTS-CP-PFS1.0# sh /home/ipsec.secrets
/home/ipsec.secrets: line 1: 192.168.11.45: not found
root@R3BTS-CP-PFS1.0# 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}

root@R3BTS-CP-PFS1.0# /etc/init.d/ipsec status
IPsec running  - pluto pid: 477
pluto pid 477
2 tunnels up
some eroutes exist
root@R3BTS-CP-PFS1.0# 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux