[Swan-dev] my early Monday test results

[Paul Wouters]

On Mon, 7 Sep 2015, D. Hugh Redelmeier wrote:

> 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)

I think this is the test system. It receives a bunch of packets but
doesnt deliver them in time, and then they all flow out anyway and
we see a bunch of retransmits in strange order.

> newoe-18-poc-cop
>
> east:
> +169.254.0.0/16 dev eth0  scope link  metric 1002
>
> Should our sanitizers just filter out these messages?

I'm okay with that, since none of our tests actually use or need this
range.

> ================
>
> 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.

these are all timing differences too. Sometimes the dpd has just not yet
kicked in and sometimes it just has kicked in, showing the difference in
tunnel vs trap.

Paul