[Openswan dev] Error building klips-ipv6 (missing include?)

[Ruben Laban]

Hello David,

Let me start by expressing my gratitude towards your work on this: thanks!

On Wednesday 25 August 2010 at 07:19 (CET), David McCullough wrote:
> Jivin David McCullough lays it down ...
> ...
> 
> > > This allows the conn to come up, but the tunnel itself I don't have
> > > working yet. Though this might be a problem with my test environment.
> > > I'm interop'ing between "Linux Openswan
> > > 2.6.master-201032.git-ge3b22fe7-dirty (klips)" and "Linux Openswan
> > > U2.6.master-201015.git/K2.6.32-02063202-generic (netkey)" currently.
> > > Encryption seems to work both ways, but decryption seems not. Though
> > > I'll be looking into that in a (hopefull) short while.
> > 
> > I haven't tested interop at all,  so don't expect that everytihng it
> > working.  Although,  based on experience,  pluto should show the tunnel
> > up, it just won't carry traffic if interop is broken.
> 
> Ok,  just finished interop with netkey and pushed the changes.  Give it a
> go and see if it fixes it for you.  Haven't fixed any of the issues about
> with ipsec0 setup though,  might have a look at them soon,

There's some progress. I'm still running various tests and troubleshooting 
some issues. One obvious one is visible when I run tcpdump on ipsec0:

On west (netkey):

# ping6 2a02:bd0:abcd:4::10 -I 2a02:bd0:abcd:1::20 -c 1 -p deadbeef
PATTERN: 0xdeadbeef
PING 2a02:bd0:abcd:4::10(2a02:bd0:abcd:4::10) from 2a02:bd0:abcd:1::20 : 56 
data bytes
64 bytes from 2a02:bd0:abcd:4::10: icmp_seq=1 ttl=64 time=3.18 ms

--- 2a02:bd0:abcd:4::10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.185/3.185/3.185/0.000 ms


On east (klips):

# tcpdump -nvei ipsec0 -s0 -X
tcpdump: listening on ipsec0, link-type EN10MB (Ethernet), capture size 65535 
bytes
12:55:51.671879 00:0c:29:66:94:fd > 00:0c:29:3a:e5:22, ethertype Unknown 
(0xdd86), length 118: 
        0x0000:  6000 0000 0040 3a40 2a02 0bd0 abcd 0001  `....@:@*.......
        0x0010:  0000 0000 0000 0020 2a02 0bd0 abcd 0004  ........*.......
        0x0020:  0000 0000 0000 0010 8000 4d26 091a 0001  ..........M&....
        0x0030:  50fa 744c 2e25 0f00 dead beef dead beef  P.tL.%..........
        0x0040:  dead beef dead beef dead beef dead beef  ................
        0x0050:  dead beef dead beef dead beef dead beef  ................
        0x0060:  dead beef dead beef                      ........
12:55:51.671914 00:0c:29:3a:e5:22 > 00:0c:29:3a:e5:22, ethertype IPv6 
(0x86dd), length 118: (hlim 64, next-header ICMPv6 (58) payload length: 64) 
2a02:bd0:abcd:4::10 > 2a02:bd0:abcd:1::20: [icmp6 sum ok] ICMP6, echo reply, 
length 64, seq 1
        0x0000:  6000 0000 0040 3a40 2a02 0bd0 abcd 0004  `....@:@*.......
        0x0010:  0000 0000 0000 0010 2a02 0bd0 abcd 0001  ........*.......
        0x0020:  0000 0000 0000 0020 8100 4c26 091a 0001  ..........L&....
        0x0030:  50fa 744c 2e25 0f00 dead beef dead beef  P.tL.%..........
        0x0040:  dead beef dead beef dead beef dead beef  ................
        0x0050:  dead beef dead beef dead beef dead beef  ................
        0x0060:  dead beef dead beef                      ........

It seems there's a byte swap regarding the ethertype: 0xdd86 versus 0x86dd. It 
seems to be a purely cosmetic issue, as the ping reply is received by west 
just fine.

Ping6 from east to west doesn't seem to work (yet), but I'm still 
investigating that scenario.

I'll continue my tests and report back.

Regards,
Ruben Laban