[RFC PATCH 0/4] Net namespaces for SocketCAN

[RFC PATCH 0/4] Net namespaces for SocketCAN

[Andri Yngvason]

Hi all,

I've added net namespace support for raw and gw sockets. BCM needs work.

I've done some preliminary testing and everything seems to work, but I would
like to have some input from you guys before continuing.

In particular I'm worried that I might have missed something with regard to
receive lists. Devices still share the same "rcv_cache" across namespaces.

Please tell me what you think.

Thanks,
Andri

Andri Yngvason (4):
  net: can: make af_can header global
  net: can: rename structures
  net: can: move shared data into net namespace
  net: can: remove net namespace restrictions

 include/linux/can/core.h    |   4 +-
 include/net/af_can.h        | 131 +++++++++++++++++++
 include/net/net_namespace.h |   4 +
 include/net/netns/can.h     |  20 +++
 net/can/af_can.c            | 183 ++++++++++++++------------
 net/can/af_can.h            | 126 ------------------
 net/can/bcm.c               |  29 +++--
 net/can/gw.c                |  13 +-
 net/can/proc.c              | 307 ++++++++++++++++++++++++--------------------
 net/can/raw.c               |  34 +++--
 10 files changed, 466 insertions(+), 385 deletions(-)
 create mode 100644 include/net/af_can.h
 create mode 100644 include/net/netns/can.h
 delete mode 100644 net/can/af_can.h

-- 
2.5.3

Re: [RFC PATCH 0/4] Net namespaces for SocketCAN

[Oliver Hartkopp]

Hi Andri,

On 27.09.2015 20:22, Andri Yngvason wrote:

> I've added net namespace support for raw and gw sockets. BCM needs work.
>
> I've done some preliminary testing and everything seems to work, but I would
> like to have some input from you guys before continuing.
>
> In particular I'm worried that I might have missed something with regard to
> receive lists. Devices still share the same "rcv_cache" across namespaces.

What I know from net namespaces is that you can create virtual interfaces 
(veth) which are 'peered' to another veth and can be 'bridged' to a real 
interface.

As the receive lists are interface specific (for real and virtual CAN 
interfaces, see dev->ml_priv in find_dev_rcv_lists()) you would need to make 
the virtual CAN driver namespace aware.

And you would need to implement some 'bind' and 'peering' between the 
interfaces to connect your virtual CAN to other vcan's or real CAN interfaces.

Net namespaces sounds fancy but I wonder what kind of use case you have in 
mind that cannot be realized by virtual CAN interfaces and can-gw routing 
assigments?

Regards,
Oliver

>
> Please tell me what you think.
>
> Thanks,
> Andri
>
> Andri Yngvason (4):
>    net: can: make af_can header global
>    net: can: rename structures
>    net: can: move shared data into net namespace
>    net: can: remove net namespace restrictions
>
>   include/linux/can/core.h    |   4 +-
>   include/net/af_can.h        | 131 +++++++++++++++++++
>   include/net/net_namespace.h |   4 +
>   include/net/netns/can.h     |  20 +++
>   net/can/af_can.c            | 183 ++++++++++++++------------
>   net/can/af_can.h            | 126 ------------------
>   net/can/bcm.c               |  29 +++--
>   net/can/gw.c                |  13 +-
>   net/can/proc.c              | 307 ++++++++++++++++++++++++--------------------
>   net/can/raw.c               |  34 +++--
>   10 files changed, 466 insertions(+), 385 deletions(-)
>   create mode 100644 include/net/af_can.h
>   create mode 100644 include/net/netns/can.h
>   delete mode 100644 net/can/af_can.h
>

Re: [RFC PATCH 0/4] Net namespaces for SocketCAN

[Andri Yngvason]

Hi Oliver,

Quoting Oliver Hartkopp (2015-09-28 17:54:35)
> Hi Andri,
> 
> On 27.09.2015 20:22, Andri Yngvason wrote:
> 
> > I've added net namespace support for raw and gw sockets. BCM needs work.
> >
> > I've done some preliminary testing and everything seems to work, but I would
> > like to have some input from you guys before continuing.
> >
> > In particular I'm worried that I might have missed something with regard to
> > receive lists. Devices still share the same "rcv_cache" across namespaces.
> 
> What I know from net namespaces is that you can create virtual interfaces 
> (veth) which are 'peered' to another veth and can be 'bridged' to a real 
> interface.
>
Yes. I'm not actually interested in that though. I just want to be able to run
vcan on LXC.
> 
> As the receive lists are interface specific (for real and virtual CAN 
> interfaces, see dev->ml_priv in find_dev_rcv_lists()) you would need to make 
> the virtual CAN driver namespace aware.
> 
> And you would need to implement some 'bind' and 'peering' between the 
> interfaces to connect your virtual CAN to other vcan's or real CAN interfaces.
>
Actually, it's also possible to connect the two interfaces via a TCP connection.
That's what I'm doing.
> 
> Net namespaces sounds fancy but I wonder what kind of use case you have in 
> mind that cannot be realized by virtual CAN interfaces and can-gw routing 
> assigments?
> 
I can't use vcan under LXC unless namespaces are supported.

Cheers,
Andri
> 
> >
> > Please tell me what you think.
> >
> > Thanks,
> > Andri
> >
> > Andri Yngvason (4):
> >    net: can: make af_can header global
> >    net: can: rename structures
> >    net: can: move shared data into net namespace
> >    net: can: remove net namespace restrictions
> >
> >   include/linux/can/core.h    |   4 +-
> >   include/net/af_can.h        | 131 +++++++++++++++++++
> >   include/net/net_namespace.h |   4 +
> >   include/net/netns/can.h     |  20 +++
> >   net/can/af_can.c            | 183 ++++++++++++++------------
> >   net/can/af_can.h            | 126 ------------------
> >   net/can/bcm.c               |  29 +++--
> >   net/can/gw.c                |  13 +-
> >   net/can/proc.c              | 307 ++++++++++++++++++++++++--------------------
> >   net/can/raw.c               |  34 +++--
> >   10 files changed, 466 insertions(+), 385 deletions(-)
> >   create mode 100644 include/net/af_can.h
> >   create mode 100644 include/net/netns/can.h
> >   delete mode 100644 net/can/af_can.h
> >

Re: [RFC PATCH 0/4] Net namespaces for SocketCAN

[Oliver Hartkopp]

Hi Andri,

On 29.09.2015 12:30, Andri Yngvason wrote:
> Quoting Oliver Hartkopp (2015-09-28 17:54:35)
>> On 27.09.2015 20:22, Andri Yngvason wrote:
>>
>>> I've added net namespace support for raw and gw sockets. BCM needs work.

Do you think about the procfs stuff?

>>> I've done some preliminary testing and everything seems to work, but I would
>>> like to have some input from you guys before continuing.

I'm not a namespace specialist though. But at least it looks consistent.

>>> In particular I'm worried that I might have missed something with regard to
>>> receive lists. Devices still share the same "rcv_cache" across namespaces.

AFAIK the rcv_cache is just a better API to handle small data structures like 
the can_receiver. As the devices are separated and inside their specific 
namespace (right?) the ml_priv is per interface anyway.

So why not use a common rcv_cache ?

>>
>> What I know from net namespaces is that you can create virtual interfaces
>> (veth) which are 'peered' to another veth and can be 'bridged' to a real
>> interface.
>>
> Yes. I'm not actually interested in that though. I just want to be able to run
> vcan on LXC.

Ok - and when you create a vcan inside a namespace with

ip netns add myns

ip link add dev vcan0 type vcan

ip link set vcan0 netns myns

This just works inside the namespace 'myns' ??

---

Generally I appreciate your work after trying to understand it ;-)
So hopefully it doesn't break things we've overlooked.

How do you bridge two vcans over TCP?

Do you have an example for that?

Regards,
Oliver

Re: [RFC PATCH 0/4] Net namespaces for SocketCAN

[Andri Yngvason]

Hi Oliver,

Quoting Oliver Hartkopp (2015-09-29 17:56:13)
> Hi Andri,
> 
> On 29.09.2015 12:30, Andri Yngvason wrote:
> > Quoting Oliver Hartkopp (2015-09-28 17:54:35)
> >> On 27.09.2015 20:22, Andri Yngvason wrote:
> >>
> >>> I've added net namespace support for raw and gw sockets. BCM needs work.
> 
> Do you think about the procfs stuff?
>
I've handled the procfs stuff in af_can, but BCM has a lot of that too. I've not
changed to proc stuff in BCM to use namespaces.
> 
> >>> I've done some preliminary testing and everything seems to work, but I would
> >>> like to have some input from you guys before continuing.
> 
> I'm not a namespace specialist though. But at least it looks consistent.
>
Neither am I! ;)
> 
> >>> In particular I'm worried that I might have missed something with regard to
> >>> receive lists. Devices still share the same "rcv_cache" across namespaces.
> 
> AFAIK the rcv_cache is just a better API to handle small data structures like 
> the can_receiver. As the devices are separated and inside their specific 
> namespace (right?) the ml_priv is per interface anyway.
> 
> So why not use a common rcv_cache ?
>
That's what I though, but I don't feel like I have the whole picture, so I'm
afraid of side-effects and race-conditions.

I've been experiencing some unstability on my workstation while using CAN under
LXC. Things don't crash under the same conditions in a non-SMP qemu machine so I
reckon there might be something racy going on. It might also be that the patches
didn't apply properly to the kernel I'm running because it's a different
version. I haven't had time to test these theories yet, but we'll see.
> 
> >>
> >> What I know from net namespaces is that you can create virtual interfaces
> >> (veth) which are 'peered' to another veth and can be 'bridged' to a real
> >> interface.
> >>
> > Yes. I'm not actually interested in that though. I just want to be able to run
> > vcan on LXC.
> 
> Ok - and when you create a vcan inside a namespace with
> 
> ip netns add myns
> 
> ip link add dev vcan0 type vcan
> 
> ip link set vcan0 netns myns
> 
> This just works inside the namespace 'myns' ??
> 
Yep, that's about right. A convenient way to test this without LXC is to add a
namespace and then run a screen/tmux session within the namespace. Something
like this:

# ip netns add myns
# ip netns exec myns tmux

Then you can add a vcan interface within the session and check that it appears
in "ip link show". Other things to try: candump any, candump vcan0, cangen vcan,
cat /proc/net/can/stats, cat /proc/net/can/rcvlists_*, ...

It's also good to run these in another namespace or the default namespace at the
same time to verify that nothing bleeds through.
> ---
> 
> Generally I appreciate your work after trying to understand it ;-)
> So hopefully it doesn't break things we've overlooked.
> 
> How do you bridge two vcans over TCP?
> 
> Do you have an example for that?
> 
I don't have any code to show you at the moment. What I have is a part of a
larger project that is not ready for release. I'll tell you how it works
instead.

TCP server:
 * Open can/vcan.
 * Listen on socket.
 * On connection:
   - Set up a callback to forward data from the bus to the client.
   - Set up a callback to forward data from the client to the bus.

TCP client:
 * Open can/vcan.
 * Connect to server.
 * On success:
   - Set up a callback to forward data from the bus to the server.
   - Set up a callback to forward data from the server to the bus.

The data is sent over as packets of "struct can_frame" with "can_id" in network
byte-order.

My LXC instance is already bridged to the network, so getting the TCP through is
no problem.

This sort of thing is probably not very nice with regard to real-time
performance but it's good enough when you're developing a CAN application on a
linux container.

Now, you might ask why I'm developing applications in an LXC instance, but
that's a whole different story. ;)

Cheers,
Andri