[Swan-dev] my early Monday test results

D. Hugh Redelmeier hugh at mimosa.com
Mon Sep 7 18:25:40 EEST 2015


As usual, I'm comparing the pass/fail results with the previous run.
There are lots of good tests and bad tests that I'm not reporting
because they are not a change.

Changes being tested:

- Paul's change to recognize a delete payload that uses our SPI
  instead of the other side's SPI.  This is to recover from a CISCO
  bug.  Sheesh.

- 5c112596aa8ebb348303f7ce8a1697575dfc9b44
  testing: ikev2-48-nat-cp  fixup inBytes/outBytes output

================

ikev2-48-nat-cp	now passes

Looks like 5c112596aa8ebb348303f7ce8a1697575dfc9b44 succeeded.

================

ikev2-43-init-retransmit now fails

west:
 133 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: initiate
 133 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
+010 "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_PARENT_I1: retransmission; will wait 500ms for response
+002 "westnet-eastnet-ipv4-psk-ikev2" #1: discarding packet received during asynchronous work (DNS or crypto) in STATE_PARENT_I1
+002 "westnet-eastnet-ipv4-psk-ikev2" #1: discarding packet received during asynchronous work (DNS or crypto) in STATE_PARENT_I1
 002 "westnet-eastnet-ipv4-psk-ikev2" #1: discarding packet received during asynchronous work (DNS or crypto) in STATE_PARENT_I1
 134 "westnet-eastnet-ipv4-psk-ikev2" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha group=MODP2048}

east:
 | duplicate IKE_INIT_I message received, retransmiting previous packet
 | sending 424 bytes for ikev2-responder-retransmit IKE_INIT_I through eth1:500 to 192.1.2.45:500 (using #1)
+| duplicate IKE_INIT_I message received, retransmiting previous packet
+| sending 424 bytes for ikev2-responder-retransmit IKE_INIT_I through eth1:500 to 192.1.2.45:500 (using #1)
+| duplicate IKE_INIT_I message received, retransmiting previous packet
+| sending 424 bytes for ikev2-responder-retransmit IKE_INIT_I through eth1:500 to 192.1.2.45:500 (using #1)
 | sending 424 bytes for ikev2-responder-retransmit through eth1:500 to 192.1.2.45:500 (using #1)

================

newoe-18-poc-cop

east:
+169.254.0.0/16 dev eth0  scope link  metric 1002 

Should our sanitizers just filter out these messages?

================

dpd-01

This might matter.  But it might actually be correct since the log
says tunnel should be up and the reference logs don't have a tunnel up.

west:
 Tunnel should be up even without trigger traffic
 west #
  ipsec eroute
-0          192.1.2.45/32      -> 192.1.2.23/32      => %trap
+0          192.1.2.45/32      -> 192.1.2.23/32      => tun0x1002 at 192.1.2.23 
 west #
  ping -q -c 8 -n 192.1.2.23
 PING 192.1.2.23 (192.1.2.23) 56(84) bytes of data.


More information about the Swan-dev mailing list