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

[David McCullough]

Jivin Ruben Laban lays it down ...
> 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 

Yep,  I am byteswapping a field twice,  try this patch.  I don't see it
because my klips host id big endian :-)

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proto.diff
Type: text/x-diff
Size: 537 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20100826/0eb19f48/attachment.bin