On 31 August 2015 at 17:00, D. Hugh Redelmeier <[email protected]> wrote:
> | On 30 August 2015 at 14:40, Paul Wouters <[email protected]> wrote: > > | > This message has appeared a long time ago when Andrew redid our CBC-only > | > crypto to CBC/CTR/GCM. > > I think that this failure is unstable and that the test is marked as if it > should pass. Here are some results from recent runs: > > Jul 20 00:33 tests.LOG16.results west:bad,east:ok > Jul 20 14:56 tests.LOG17.results west:bad,east:ok > Jul 22 01:17 tests.LOG18.results good > Jul 24 00:50 tests.LOG19.results west:ok,east:bad > Jul 25 03:04 tests.LOG20.results dunno > Jul 26 10:29 tests.LOG21.results west:bad,east:ok > Jul 27 12:57 tests.LOG23.results good > Jul 28 09:47 tests.LOG24.results good > Aug 24 09:00 tests.LOG26.results west:bad,east:ok > Aug 29 11:12 tests.LOG27.results good > Aug 30 00:38 tests.LOG28.results west:bad,east:ok > Aug 31 10:59 tests.LOG29.results west:bad,east:ok > > It isn't always the same side that fails. > > This isn't a good situation. Would you know what the pad byte was for each of these cases? Or at least the case that passed? In pluto look for the line: | payload after decryption: and then the last byte of the dump: | 29 00 00 0c 02 00 00 00 65 61 73 74 27 00 00 08 [....] | 67 31 34 58 e3 cf 5e 9e f9 5f 10 e4 b8 41 0f 23 "westnet-eastnet-ikev2" #2: invalid padding-length octet: 0x23 I suspect that racooon, when the real payload is block aligned, completely forgets to do any padding at all. Perhaps, if we receive a packet that validates, but has too-big padding, we simply soldier on. I don't like it, however it is probably what happened before the check was added. If nothing else, since the test is unstable, it should be disabled. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
