From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: bug in ip -s xfrm state list
Date: Wed, 30 May 2012 08:13:38 -0700
Message-ID: <20120530081338.1904c604@nehalam.linuxnetplumber.net>
References: <1938601.tRGYljKHkq@notebook>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: netdev@vger.kernel.org
To: Jaroslav =?utf-8?B?xaBhZmth?= <jaroslav.safka@siemens.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail.vyatta.com ([76.74.103.46]:45015 "EHLO mail.vyatta.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752671Ab2E3PNl convert rfc822-to-8bit (ORCPT
	<rfc822;netdev@vger.kernel.org>); Wed, 30 May 2012 11:13:41 -0400
In-Reply-To: <1938601.tRGYljKHkq@notebook>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, 30 May 2012 15:00:05 +0200
Jaroslav =C5=A0afka <jaroslav.safka@siemens.com> wrote:

> Hello guys,
> I found small problem in printing "seq" number.
> I think the problem is visible in diff below ;-)
>=20
> Best regards
> Jarek
>=20
> diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
> index c7b3420..67fe838 100644
> --- a/ip/ipxfrm.c
> +++ b/ip/ipxfrm.c
> @@ -843,7 +843,7 @@ void xfrm_state_info_print(struct xfrm_usersa_inf=
o=20
> *xsinfo,
>         fputs(buf, fp);
>         fprintf(fp, "replay-window %u ", xsinfo->replay_window);
>         if (show_stats > 0)
> -               fprintf(fp, "seq 0x%08u ", xsinfo->seq);
> +               fprintf(fp, "seq %08u ", ntohl(xsinfo->seq));
>         if (show_stats > 0 || xsinfo->flags) {
>                 __u8 flags =3D xsinfo->flags;
> =20
>=20
>=20

Moving to netdev list for more feedback.
Your change has two components:
  1. printing sequence number in decimal notation with 0x prefix.
  2. doing ntohl().

The first is an obvious bug in the original code. Not sure about
the second. It looks like sequence numbers generated by the kernel
come from xfrm_get_acqseq() which generates sequence numbers in host
byte order. But sequence numbers entered from user space (vi xfrm_seq_p=
arse)
are encoded in network byte order. This looks like a flaw in the origin=
al design.

The kernel networking code tries to be careful about documenting networ=
k
verus host byte order via the typedef __be32 vs __u32.  Given that the =
kernel
is using __u32 for sequence number in xfrm fairly consistently; my opni=
non
is that iproute2 should change and go with the kernel practice and
use host byte order.