On 05/01/18 18:47, Guillaume Nault wrote:
> The "offset" option has been removed by
> commit 900631ee6a26 ("l2tp: remove configurable payload offset").
>
> Signed-off-by: Guillaume Nault <g.na...@alphalink.fr>
> ---
>  include/uapi/linux/l2tp.h | 2 +-
>  net/l2tp/l2tp_core.c      | 7 +++----
>  2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/l2tp.h b/include/uapi/linux/l2tp.h
> index f78eef4cc56a..71e62795104d 100644
> --- a/include/uapi/linux/l2tp.h
> +++ b/include/uapi/linux/l2tp.h
> @@ -65,7 +65,7 @@ struct sockaddr_l2tpip6 {
>   * TUNNEL_MODIFY     - CONN_ID, udpcsum
>   * TUNNEL_GETSTATS   - CONN_ID, (stats)
>   * TUNNEL_GET                - CONN_ID, (...)
> - * SESSION_CREATE    - SESSION_ID, PW_TYPE, offset, data_seq, cookie, 
> peer_cookie, offset, l2spec
> + * SESSION_CREATE    - SESSION_ID, PW_TYPE, data_seq, cookie, peer_cookie, 
> l2spec
>   * SESSION_DELETE    - SESSION_ID
>   * SESSION_MODIFY    - SESSION_ID, data_seq
>   * SESSION_GET               - SESSION_ID, (...)
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index 786cd7f6a5e8..62285fc6eb59 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -662,10 +662,9 @@ static int l2tp_recv_data_seq(struct l2tp_session 
> *session, struct sk_buff *skb)
>   * |x|S|x|x|x|x|x|x|              Sequence Number                  |
>   * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   *
> - * Cookie value, sublayer format and offset (pad) are negotiated with
> - * the peer when the session is set up. Unlike L2TPv2, we do not need
> - * to parse the packet header to determine if optional fields are
> - * present.
> + * Cookie value and sublayer format are negotiated with the peer when
> + * the session is set up. Unlike L2TPv2, we do not need to parse the
> + * packet header to determine if optional fields are present.
>   *
>   * Caller must already have parsed the frame and determined that it is
>   * a data (not control) frame before coming here. Fields up to the

Acked-by: James Chapman <jchap...@katalix.com>


Reply via email to