netdev - Re: [PATCH V2 net-next] LISP: Locator/Identifier Separation Protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 17 Jun 2014 13:52:46 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Christopher White <chris@...icalelegance.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>,
	"Vina Ermagan (vermagan)" <vermagan@...co.com>,
	"Lorand Jakab -X (lojakab - M SQUARED CONSULTING INC. at Cisco)" 
	<lojakab@...co.com>
Subject: Re: [PATCH V2 net-next] LISP: Locator/Identifier Separation Protocol

On Tue, Jun 17, 2014 at 1:41 PM, Christopher White
<chris@...icalelegance.com> wrote:
> Thanks Tom, some quick questions as I wrap this up….
>
> On Jun 5, 2014, at 3:12 PM, Tom Herbert <therbert@...gle.com> wrote:
>
>>
>>> +static inline struct rtable *find_route(struct net *net,
>>> +                                       __be32 *saddr, __be32 daddr,
>>> +                                       u8 ipproto, u8 tos, u32 skb_mark)
>>> +{
>>> +       struct rtable *rt;
>>> +
>>> +       /* Tunnel configuration keeps DSCP part of TOS bits, But Linux
>>> +        * router expect RT_TOS bits only.
>>> +        */
>>> +       struct flowi4 fl = { .daddr             = daddr,
>>> +                            .saddr             = *saddr,
>>> +                            .flowi4_tos        = RT_TOS(tos),
>>> +                            .flowi4_mark       = skb_mark,
>>> +                            .flowi4_proto      = ipproto };
>>> +
>>> +       rt = ip_route_output_key(net, &fl);
>>> +       *saddr = fl.saddr;
>>> +       return rt;
>>> +}
>>> +
>> Looks like a function that should be in common header file?
>>
>
> I’m not certain where the right place would be for this. A new file perhaps?
>
It should be in include/net/route.h. There is already ip_route_output
and ip_route_output_gre which are very similar to this.

>>
>>> +static int create_v4_sock(struct net *net, __be16 port, struct socket **psock,
>>> +                         u32 flags)
>>> +{
>>> +       struct sock *sk;
>>> +       struct socket *sock;
>>> +       struct sockaddr_in lisp_addr = {
>>> +               .sin_family             = AF_INET,
>>> +               .sin_addr.s_addr        = htonl(INADDR_ANY),
>>> +               .sin_port               = port,
>>> +       };
>>> +       int rc;
>>> +
>>> +       /* Create UDP socket for encapsulation receive. */
>>> +       rc = sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
>>> +       if (rc < 0) {
>>> +               pr_debug("UDP socket create failed\n");
>>> +               return rc;
>>> +       }
>>> +
>>> +       /* Put in proper namespace */
>>> +       sk = sock->sk;
>>> +       sk_change_net(sk, net);
>>> +
>>> +       rc = kernel_bind(sock, (struct sockaddr *)&lisp_addr,
>>> +                        sizeof(lisp_addr));
>>> +       if (rc < 0) {
>>> +               pr_debug("bind for UDP socket %pI4:%u (%d)\n",
>>> +                        &lisp_addr.sin_addr, ntohs(lisp_addr.sin_port), rc);
>>> +               sk_release_kernel(sk);
>>> +               return rc;
>>> +       }
>>> +
>>> +       *psock = sock;
>>> +       /* Disable multicast loopback */
>>> +       inet_sk(sk)->mc_loop = 0;
>>> +
>>> +       if (!(flags & LISP_F_UDP_CSUM))
>>> +               sock->sk->sk_no_check_tx = 1;
>>> +       return 0;
>>> +}
>> Another function that is common among UDP tunneling protocols and
>> should be in common code.
>
> In udp.c perhaps? udp_tunnel_create_v4_sock()?
>
It might make sense for this to udp_offload.c (along with
skb_udp_tunnel_segment).

> Thanks!
> -Chris
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html