The same setup with a 2.6.14.2 kernel (witch the patches are supplied for) works perfectly. So this is 2.6.15 related. BR, Alfredo Matos kslavov@xxxxxxxxx wrote: > Quoting Miika Komu <miika@xxxxxx>: > > >> On Thu, 2 Mar 2006, Alfredo Matos wrote: >> >> >>> Hi, >>> >>> I have a two machine setup: 3ffe::1 and 3ffe::2 . >>> I installed a 2.6.15.4 kernel, with the BEET patches ( the 2.6.14.2 >>> pacthes apply cleanly). I am using IPv6, xfrm_user, aes+des+sha1 all as >>> modules. >>> >>> The problem is when that the Initiator hipd never sends out an I1 >>> packet, although i can see the packets (tcp, from conntest-client-gai) >>> going through the dummy0 interface, but nothing happens. >>> The other strange thing is when i shutdown the Initiator hipd, it send >>> ou a close packet, and this is received and processed at the responder. >>> >>> This happens both with userspace and main branch of the code. >>> >>> Any ideas of what i might be doing wrong ? (Debug is below) >>> >> What is your HIPL version? >> >> We are currently using 2.6.13.1 kernel as it has less problems with >> various IPsec/mobility related issues. Could you try if the same problem >> occurs with 2.6.13.1 kernel, so that we can be 100 % sure that it is a >> kernel issue? >> >> We are currently recommending the use of 2.6.13.1 kernel as we are >> finalizing the support for the BEET IPsec mode. After it is done, we are >> going to upgrade the supported kernel version. >> >> If you still want to use the latest kernel, I think you may want to apply >> the following patches: >> >> patches/kernel/ipv6_addr_del.patch.2.6.14.4.slavov >> patches/kernel/rtnetlink.patch.2.6.14.4-slavov >> > > These patches are incluein 2.6.15 > > > >> I think there was some issue related to some ACQUIRE or SA constants that >> changed in the latest kernels, and I also thought I fixed this already. >> Kristian, can you remember to what this was related? >> > > No, these are purely related to IPv6. First one fixed a problem in IPv6 > address > deletion which caused also flushing of routing table. The other was related to > netlink messages not being passed "correctly". > > BR, >