[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