On Thu, 11 Nov 2004, Justino Santos e Alfredo Matos wrote: -> We have also encountered the same problem in our -> captures. -> We are using Ethereal. (version 0.10.7). -> Here's what we see in the ESP Packets: -> -> 16:18:32.983149 3ffe::2 > 3ffe::3: -> ESP(spi=0x554fbe32,seq=0xb5) -> 16:18:32.983520 -> 71d4:c22d:f12e:7785:d8e2:9ea1:2be3:918a > -> 5291:cea2:5d13:287d:faeb:27ef:148c:1af8: -> ESP(spi=0xcac1f47e,seq=0x9e) -> 16:18:33.284871 3ffe::2 > 3ffe::3: -> ESP(spi=0x554fbe32,seq=0xb6) -> 16:18:33.285262 -> 71d4:c22d:f12e:7785:d8e2:9ea1:2be3:918a > -> 5291:cea2:5d13:287d:faeb:27ef:148c:1af8: -> ESP(spi=0xcac1f47e,seq=0x9f) -> -> We see HIT's in one direction (both src and dst) and -> IP's in the reverse direction (both src and dst also). -> This is a different situation from that presented before. -> Is this the cosmetic problem you talked about in -> earlier mails, or is it something else ? I was finally able to see this issue myself where there are only HITs or IP addresses in both of the the src/dst. I do not consider this to be so serious issue (until proven otherwise, that is). -> We assume that the capture is being done before the -> HIT's are replaced, but where and why does this happen ? All of this is related to where the packet delivery to the raw sockets (which are needed when capturing the packets) are implemented in the kernel and the architectural changes needed in the kernel for HIP traffic. On inbound traffic, it looks like the raw sockets get the packet after the IP addresses are replaced with HITs. On outbound traffic, the raw sockets get the packet when the transport layer data is encapsulated into ESP. Before the encapsulation the HITs are replaced by IP addresses. Moving the raw socket delivery somewhere else in the kernel might break existing applications, so my current plan is not to change anything related to the raw sockets.