So I have tried both IPsec ESP in transport mode with aes-gcm and aes-cbc
and it does encrypt properly.
In the test I'm using VPP 19.01 release with software cryptodevs and the
built-in packet-generator:
00:00:07:563578: ipsec4-output-feature
spd 1
00:00:07:563595: dpdk-esp4-encrypt
cipher aes-cbc-128 auth sha1-96
IPSEC_ESP: 192.168.100.1 -> 192.168.200.1
tos 0x00, ttl 63, length 168, checksum 0xcdd0
fragment id 0x0000
ESP: spi 1001, seq 1
Packet 2
00:00:07:563658: dpdk-crypto-input
status: success
00:00:07:563701: pg0-output
pg0
IP4: 02:fe:1e:3a:8f:6a -> de:ad:be:ef:ca:fe
IPSEC_ESP: 192.168.100.1 -> 192.168.200.1
tos 0x00, ttl 63, length 168, checksum 0xcdd0
fragment id 0x0000
00:00:07:563707: pg0-tx
buffer 0x4e9f: current data -38, length 182, free-list 0, clone-count
0, totlen-nifb 0, trace 0x1
IP4: 02:fe:1e:3a:8f:6a -> de:ad:be:ef:ca:fe
IPSEC_ESP: 192.168.100.1 -> 192.168.200.1
tos 0x00, ttl 63, length 168, checksum 0xcdd0
fragment id 0x0000
As you can observe, in the interface -output and -tx the trace shows the
proper Ethernet and IPv4 layers, where as in your trace the ethertype is
already wrong:
00:03:07:167310: dpdk-crypto-input
status: success
00:03:07:167371: VirtualFunctionEthernet1/0/2-output
VirtualFunctionEthernet1/0/2
0x0000: 02:0f:b7:00:00:00 -> 02:0f:b7:00:00:01
00:03:07:167392: VirtualFunctionEthernet1/0/2-tx
VirtualFunctionEthernet1/0/2 tx queue 1
buffer 0x2a02: current data -24, length 102, buffer-pool 0,
clone-count 0, totlen-nifb 0, trace 0x0
ext-hdr-valid
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 0, nb_segs 1, pkt_len 102
buf_len 2176, data_len 102, ol_flags 0x180, data_off 104,
phys_addr 0x40150200
packet_type 0x210 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
0x0000: 02:0f:b7:00:00:00 -> 02:0f:b7:00:00:01
It looks like the crypto device is writing at the wrong offset, so you
probably need to gdb and look at the packet before encrypt
(esp-encrypt node) and after being read from the cryptodev
(dpdk-crypto-input node).
On Thu, Feb 7, 2019 at 2:22 PM <manuel.alo...@cavium.com> wrote:
> Yes I did, OpenSSL backend is working.
> I can see the esp4-encrypt and esp4-decrypt counters incrementing and
> there are no errors. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12206): https://lists.fd.io/g/vpp-dev/message/12206
> Mute This Topic: https://lists.fd.io/mt/29538345/682142
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1498673
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [
> sergio.gonzalez.mon...@outlook.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12212): https://lists.fd.io/g/vpp-dev/message/12212
Mute This Topic: https://lists.fd.io/mt/29538345/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
