Raw CAN socket support in LXC?

Raw CAN socket support in LXC?

[John Ernberg]

Hi

We're working on an embedded system where we're planning on wrapping our 
applications in containers as a resource control safety measurement.
 From our understanding Raw CAN sockets are not yet supported in LXC, 
and now we're wondering why.

Is there any reasoning we should be aware of as to why support has not 
been added? Except possibly "We have not seen the need" or "No one has 
taken the time to".

Our system uses linux kernel 3.10.17.

Thank you in advance for any assistance.

Best regards // John Ernberg

Re: Raw CAN socket support in LXC?

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On 05/08/2015 10:12 AM, John Ernberg wrote:
> We're working on an embedded system where we're planning on wrapping our 
> applications in containers as a resource control safety measurement.
>  From our understanding Raw CAN sockets are not yet supported in LXC, 
> and now we're wondering why.

I don't know - I've never tried to do so. LXC make heavy use of network
namespaces, I think netfilter (NAT, filter) is used to grant access to
the containers.

Can you elaborate your use case in more detail. Do you want to limit the
sending of CAN frames from the containers to the outside? Do you want to
filter on CAN-id or even the contents? What about the receiving side? Do
you want to limit the reception to certain CAN-ids, too?

> Is there any reasoning we should be aware of as to why support has not 
> been added? Except possibly "We have not seen the need" or "No one has 
> taken the time to".

I think all of the above.

regards,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Raw CAN socket support in LXC?

[John Ernberg]

On 2015-05-08 10:28, Marc Kleine-Budde wrote:
> On 05/08/2015 10:12 AM, John Ernberg wrote:
>> We're working on an embedded system where we're planning on wrapping our
>> applications in containers as a resource control safety measurement.
>>   From our understanding Raw CAN sockets are not yet supported in LXC,
>> and now we're wondering why.
> I don't know - I've never tried to do so. LXC make heavy use of network
> namespaces, I think netfilter (NAT, filter) is used to grant access to
> the containers.
>
> Can you elaborate your use case in more detail. Do you want to limit the
> sending of CAN frames from the containers to the outside? Do you want to
> filter on CAN-id or even the contents? What about the receiving side? Do
> you want to limit the reception to certain CAN-ids, too?
>
>> Is there any reasoning we should be aware of as to why support has not
>> been added? Except possibly "We have not seen the need" or "No one has
>> taken the time to".
> I think all of the above.
>
> regards,
> Marc
>
Hi Marc

Thank you for your reply.

Our main use-case is to prevent a possible misbehaving application to 
bring down the entire system through memory leaks, crashes etc.
At this time we have not considered any filtering or blocking of directions.

Best regards // John Ernberg

Re: Raw CAN socket support in LXC?

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On 05/08/2015 10:45 AM, John Ernberg wrote:
> Our main use-case is to prevent a possible misbehaving application to 
> bring down the entire system through memory leaks, crashes etc.
> At this time we have not considered any filtering or blocking of directions.

Can you see the your CAN interface inside of the LXC container? Or are
the RAW sockets the problem?

Marc

btw: you can use systemd to do memory limiting, too. It makes use of the
same feature in the kernel (cgroups).

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Raw CAN socket support in LXC?

[John Ernberg]

On 2015-05-08 10:54, Marc Kleine-Budde wrote:
> On 05/08/2015 10:45 AM, John Ernberg wrote:
>> Our main use-case is to prevent a possible misbehaving application to
>> bring down the entire system through memory leaks, crashes etc.
>> At this time we have not considered any filtering or blocking of directions.
> Can you see the your CAN interface inside of the LXC container? Or are
> the RAW sockets the problem?
>
> Marc
>
> btw: you can use systemd to do memory limiting, too. It makes use of the
> same feature in the kernel (cgroups).
>
Hi

With the experimenting I have been able to do on an Ubuntu 14.04 LTS 
computer, I cannot find any CAN or virtual CAN interfaces inside the 
container.
When I change the config to specifically forward CAN interfaces, like this:
lxc.network.type = can
lxc.network.link = lxcbr0
lxc.network.flags = up
lxc.network.hwaddr = 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
I get a series of parsing errors from LXC and the container cannot be 
created.

Creating a privileged container did not change anything.

We will also take the systemd alternative into consideration, but the 
current state is that we'd like to run with LXC, as they provide us with 
more options for future changes to our use-cases.

Best regards // John Ernberg

Re: Raw CAN socket support in LXC?

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On 05/08/2015 01:17 PM, John Ernberg wrote:
> On 2015-05-08 10:54, Marc Kleine-Budde wrote:
>> On 05/08/2015 10:45 AM, John Ernberg wrote:
>>> Our main use-case is to prevent a possible misbehaving application to
>>> bring down the entire system through memory leaks, crashes etc.
>>> At this time we have not considered any filtering or blocking of directions.
>> Can you see the your CAN interface inside of the LXC container? Or are
>> the RAW sockets the problem?
>>
>> Marc
>>
>> btw: you can use systemd to do memory limiting, too. It makes use of the
>> same feature in the kernel (cgroups).
>>
> Hi
> 
> With the experimenting I have been able to do on an Ubuntu 14.04 LTS 
> computer, I cannot find any CAN or virtual CAN interfaces inside the 
> container.
> When I change the config to specifically forward CAN interfaces, like this:
> lxc.network.type = can
> lxc.network.link = lxcbr0
> lxc.network.flags = up
> lxc.network.hwaddr = 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

You're probably following an ethernet example here, right? So let's
first figure out, that lxc does in the background and see how this
translates into the CAN world.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Raw CAN socket support in LXC?

[John Ernberg]

On 2015-05-08 13:54, Marc Kleine-Budde wrote:
> On 05/08/2015 01:17 PM, John Ernberg wrote:
>> On 2015-05-08 10:54, Marc Kleine-Budde wrote:
>>> On 05/08/2015 10:45 AM, John Ernberg wrote:
>>>> Our main use-case is to prevent a possible misbehaving application to
>>>> bring down the entire system through memory leaks, crashes etc.
>>>> At this time we have not considered any filtering or blocking of directions.
>>> Can you see the your CAN interface inside of the LXC container? Or are
>>> the RAW sockets the problem?
>>>
>>> Marc
>>>
>>> btw: you can use systemd to do memory limiting, too. It makes use of the
>>> same feature in the kernel (cgroups).
>>>
>> Hi
>>
>> With the experimenting I have been able to do on an Ubuntu 14.04 LTS
>> computer, I cannot find any CAN or virtual CAN interfaces inside the
>> container.
>> When I change the config to specifically forward CAN interfaces, like this:
>> lxc.network.type = can
>> lxc.network.link = lxcbr0
>> lxc.network.flags = up
>> lxc.network.hwaddr = 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> You're probably following an ethernet example here, right? So let's
> first figure out, that lxc does in the background and see how this
> translates into the CAN world.
>
> Marc
>
Hi

I first tried to figure out what kind of settings that would be the most 
appropriate to tinker with, but I could not find anything more relevant 
so I copied the ethernet example in the end.
I will dig into the LXC code and see what can be done in terms of 
getting the CAN network interfaces through.

Best regards // John Ernberg

Re: Raw CAN socket support in LXC?

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On 05/08/2015 02:24 PM, John Ernberg wrote:
> I first tried to figure out what kind of settings that would be the most 
> appropriate to tinker with, but I could not find anything more relevant 
> so I copied the ethernet example in the end.
> I will dig into the LXC code and see what can be done in terms of 
> getting the CAN network interfaces through.

It probably sets up an etherner bridge and some kind of virtual ethernet
device between the container and the host.

Can you start a container with a working ethernet setup and post the
output of:

    brctl show

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Raw CAN socket support in LXC?

[John Ernberg]

On 2015-05-08 14:31, Marc Kleine-Budde wrote:
> On 05/08/2015 02:24 PM, John Ernberg wrote:
>> I first tried to figure out what kind of settings that would be the most
>> appropriate to tinker with, but I could not find anything more relevant
>> so I copied the ethernet example in the end.
>> I will dig into the LXC code and see what can be done in terms of
>> getting the CAN network interfaces through.
> It probably sets up an etherner bridge and some kind of virtual ethernet
> device between the container and the host.
>
> Can you start a container with a working ethernet setup and post the
> output of:
>
>      brctl show
>
> Marc
>
Here's what my ifconfig and brctl looks like when I am running a 
container with working ethernet bridging.

$ ifconfig
lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:65536  Metric:1
           RX packets:62708 errors:0 dropped:0 overruns:0 frame:0
           TX packets:62708 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:26174279 (26.1 MB)  TX bytes:26174279 (26.1 MB)

lxcbr0    Link encap:Ethernet  HWaddr fe:8e:ec:8f:13:24
           inet addr:10.0.1.1  Bcast:10.0.1.255  Mask:255.255.255.0
           inet6 addr: fe80::801b:d5ff:fe73:3464/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:121 errors:0 dropped:0 overruns:0 frame:0
           TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:9845 (9.8 KB)  TX bytes:20560 (20.5 KB)

vcan0     Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           UP RUNNING NOARP  MTU:16  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vethTRGO6W Link encap:Ethernet  HWaddr fe:8e:ec:8f:13:24
           inet6 addr: fe80::fc8e:ecff:fe8f:1324/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:39 errors:0 dropped:0 overruns:0 frame:0
           TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:3787 (3.7 KB)  TX bytes:8005 (8.0 KB)


$ brctl show
bridge name    bridge id      STP enabled    interfaces
lxcbr0         8000.fe8eec8f1324   no        vethTRGO6W

Best regards // John Ernberg

Re: Raw CAN socket support in LXC?

[Pavel Pisa]

Hello John,

On Friday 08 of May 2015 13:17:52 John Ernberg wrote:
> Hi
>
> With the experimenting I have been able to do on an Ubuntu 14.04 LTS
> computer, I cannot find any CAN or virtual CAN interfaces inside the
> container.
> When I change the config to specifically forward CAN interfaces, like this:
> lxc.network.type = can
> lxc.network.link = lxcbr0
> lxc.network.flags = up
> lxc.network.hwaddr = 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> I get a series of parsing errors from LXC and the container cannot be
> created.
>
> Creating a privileged container did not change anything.
>
> We will also take the systemd alternative into consideration, but the
> current state is that we'd like to run with LXC, as they provide us with
> more options for future changes to our use-cases.

you cannot use Ethernet bridging. This cannot work.
But you should be able to forward whole interface
to the container

lxc.network.type = phys

I have not tried this for CAN, but it works with Ethernet
and I expect that in this case there is no significant difference
to CAN. But you lose (at least for Ethernet) access to the interface
from the outer system.

If you want to filter frames then you should be able to setup
virtual CAN interface in the outer/host system, then setup CANGW
to route messages in the interrest and the start container
which hides virtual can interface from the outer system
but CANGW setup should continue to work after this move of
interface to other namespace.

I am out of time with teaching now so I do not expect to find
time to test that soon but I hope that hint is in the right
direction. If there is some need to do code adaptations somebody
of my colleagues could have interrest to look at it if we
are sucesfull with gaining one of our partially related grant
or we find other funding.

Best wishes,

               Pavel

Re: Raw CAN socket support in LXC?

[John Ernberg]

On 2015-05-11 13:45, Pavel Pisa wrote:
> Hello John,
>
> On Friday 08 of May 2015 13:17:52 John Ernberg wrote:
>> Hi
>>
>> With the experimenting I have been able to do on an Ubuntu 14.04 LTS
>> computer, I cannot find any CAN or virtual CAN interfaces inside the
>> container.
>> When I change the config to specifically forward CAN interfaces, like this:
>> lxc.network.type = can
>> lxc.network.link = lxcbr0
>> lxc.network.flags = up
>> lxc.network.hwaddr = 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>> I get a series of parsing errors from LXC and the container cannot be
>> created.
>>
>> Creating a privileged container did not change anything.
>>
>> We will also take the systemd alternative into consideration, but the
>> current state is that we'd like to run with LXC, as they provide us with
>> more options for future changes to our use-cases.
> you cannot use Ethernet bridging. This cannot work.
> But you should be able to forward whole interface
> to the container
>
> lxc.network.type = phys
>
> I have not tried this for CAN, but it works with Ethernet
> and I expect that in this case there is no significant difference
> to CAN. But you lose (at least for Ethernet) access to the interface
> from the outer system.
>
> If you want to filter frames then you should be able to setup
> virtual CAN interface in the outer/host system, then setup CANGW
> to route messages in the interrest and the start container
> which hides virtual can interface from the outer system
> but CANGW setup should continue to work after this move of
> interface to other namespace.
>
> I am out of time with teaching now so I do not expect to find
> time to test that soon but I hope that hint is in the right
> direction. If there is some need to do code adaptations somebody
> of my colleagues could have interrest to look at it if we
> are sucesfull with gaining one of our partially related grant
> or we find other funding.
>
> Best wishes,
>
>                 Pavel
Hi Pavel,

I succeeded in forwarding the can interface into the container.
When I tried to open a socket, and bind it to the interface to make a 
test for receiving frames I got an error saying "socket: Address family 
not supported by protocol".
Looking around in LXC, and then the kernel, I discovered that the AF_CAN 
implementation does not support net_namespaces yet, and net_namespaces 
does not implement any handling for CAN, so we cannot open any kind of 
socket to actually read from the interface.

Is there anything quick and dirty I could try to see if socket traffic 
can be forwarded into the container on a phys-forwarded CAN interface? 
Or would a proper net_namespaces implementation for CAN be necessary?

Best regards // John Ernberg

Re: Raw CAN socket support in LXC?

[Oliver Hartkopp]

On 05/11/2015 03:06 PM, John Ernberg wrote:

> I succeeded in forwarding the can interface into the container.
> When I tried to open a socket, and bind it to the interface to make a 
> test for receiving frames I got an error saying "socket: Address family 
> not supported by protocol".
> Looking around in LXC, and then the kernel, I discovered that the AF_CAN 
> implementation does not support net_namespaces yet, and net_namespaces 
> does not implement any handling for CAN, so we cannot open any kind of 
> socket to actually read from the interface.
> 
> Is there anything quick and dirty I could try to see if socket traffic 
> can be forwarded into the container on a phys-forwarded CAN interface? 

You can try to read CAN frames from the CAN netdev via AF_PACKET socket:

https://github.com/linux-can/can-tests/blob/master/tst-packet.c

Or use wireshark which has CAN support too.

> Or would a proper net_namespaces implementation for CAN be necessary?

When you use AF_PACKET you bypass the CAN network layer stuff.

Best regards,
Oliver