netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: IPSec: IPv6 random failures
@ 2003-05-23 15:42 Tom Lendacky
  2003-05-23 20:50 ` David S. Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Tom Lendacky @ 2003-05-23 15:42 UTC (permalink / raw)
  To: David S. Miller; +Cc: kuznet, netdev


> Can someone review and stress test out this patch for me?

I had been testing on 2.5.69 so I used the 2.5.69-bk16 patch to test out
the fix.  I was getting a hang at random times during my tests.  I didn't
know if it was the result of this fix or something else in the bk16 patch.
So I got the bk15 patch (which doesn't have your fix) and tested on that
and again received a hang at random times during my tests.  Although both
levels didn't consistently fail on the same test case, though both seemed
to hang the system right after flushing the SPs and SAs.  So while it
doesn't appear that your fix is causing the hang, something is wrong.  I'll
try and do some debugging and see if I can find the problem.

Thanks,
Tom

toml@us.ibm.com

^ permalink raw reply	[flat|nested] 5+ messages in thread
* IPSec: IPv6 random failures
@ 2003-05-22 18:15 Tom Lendacky
  2003-05-22 22:54 ` David S. Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Tom Lendacky @ 2003-05-22 18:15 UTC (permalink / raw)
  To: netdev; +Cc: davem, kuznet

Every now and then I see some failures in the TAHI tests that I am running
on IPv6.  The scenario has to do with two tunnel SP entries and the
corresponding SA entries on a system and sending an echo reply to each
(unique) destination in each SP.  The first echo reply is successfully
processed, but the second one is not.  After looking further, it appears
that the following occurs:

- For the first echo reply, during the xfrm_lookup a flow lookup is
performed and a flow cache entry created.
- For the second echo reply (to a different destination than the first
one), during the xfrm_lookup a flow lookup is performed and matches the
previously created flow cache entry, even though it shouldn't.

It turns out that the flowi structure uses pointers to the IPv6 addresses
(whereas IPv4 uses the actual address) and that even though the actual
destination IPv6 addresses are different between the first and second echo
reply, the pointers are not (actually the pointers to both the source and
destination in6_addr structures are the same).  Since the pointers are the
same the flowi compare is successful and the cache entry is used, which,
for the second echo reply, does not point to the correct policy.

It would seem that the flowi structure should use the actual IPv6 addresses
instead of pointers to them, like the IPv4 section does.  Feedback?

Thanks,
Tom

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-05-23 20:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-23 15:42 IPSec: IPv6 random failures Tom Lendacky
2003-05-23 20:50 ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-05-22 18:15 Tom Lendacky
2003-05-22 22:54 ` David S. Miller
2003-05-23  0:43   ` David S. Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).