[Unstrung-hackers] [[NET-NEXT]] Added dump function to recognise rpl extension header option(63)

Stefan Schmidt stefan at osg.samsung.com
Thu May 4 07:56:42 EDT 2017


Hello.

Glad to see that you are working on this. :)

I take it that this is basically a quick fix / RFC for now.
Once you are goping to submit this upstream please make sure you send
it to netdev and please cc linux-wpan as well here so I can give it a
proper review and testing.

On Thu, 2017-05-04 at 13:40, Andreas Bardoutsos wrote:
> Signed-off-by: Andreas Bardoutsos <bardoutsos at ceid.upatras.gr>
> ---
> I have added a dump function(always return true) to recognise RPL extension
> header(RFC6553)
> Otherwise packet was dropped by kernel resulting in impossible communication
> in RPL DAG's between
> linux running border routers and devices in the graph,which may run
> different OS(contiki os for example)

The information above is important and should be in the commit message itself.

>  include/uapi/linux/in6.h |  1 +
>  net/ipv6/exthdrs.c       | 13 +++++++++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index 46444f8fbee4..5cc12d309dfe 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
> @@ -146,6 +146,7 @@ struct in6_flowlabel_req {
>  #define IPV6_TLV_CALIPSO	7	/* RFC 5570 */
>  #define IPV6_TLV_JUMBO		194
>  #define IPV6_TLV_HAO		201	/* home address option */
> +#define IPV6_TLV_RPL	99	/* RFC 6553 */
> 
>  /*
>   *	IPV6 socket options
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index b636f1da9aec..82ed60d3180e 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
> @@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff *skb, int
> optoff)
>  	return false;
>  }
> 
> +/* RPL RFC 6553 */
> +
> +static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
> +{
> +	/*Dump function which always return true
> +	*when rpl option is detected*/
> +	return true;


Michael, is there more that needs doing in the kernel? Some basic sanity checking
of the packet maybe?

> +}
> +
>  static const struct tlvtype_proc tlvprochopopt_lst[] = {
>  	{
>  		.type	= IPV6_TLV_ROUTERALERT,
> @@ -798,6 +807,10 @@ static const struct tlvtype_proc tlvprochopopt_lst[] =
> {
>  		.type	= IPV6_TLV_CALIPSO,
>  		.func	= ipv6_hop_calipso,
>  	},
> +	{
> +		.type	= IPV6_TLV_RPL,
> +		.func	= ipv6_hop_rpl,


Is the RPL option considered an hop-by-hop extension? I wonder about the *_hop_*
naming here.

regards
Stefan Schmidt


More information about the Unstrung-hackers mailing list