* Raw CAN socket support in LXC?
@ 2015-05-08 8:12 John Ernberg
2015-05-08 8:28 ` Marc Kleine-Budde
0 siblings, 1 reply; 12+ messages in thread
From: John Ernberg @ 2015-05-08 8:12 UTC (permalink / raw)
To: linux-can; +Cc: Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 8:12 Raw CAN socket support in LXC? John Ernberg
@ 2015-05-08 8:28 ` Marc Kleine-Budde
2015-05-08 8:45 ` John Ernberg
0 siblings, 1 reply; 12+ messages in thread
From: Marc Kleine-Budde @ 2015-05-08 8:28 UTC (permalink / raw)
To: John Ernberg, linux-can; +Cc: Adam Engström
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 8:28 ` Marc Kleine-Budde
@ 2015-05-08 8:45 ` John Ernberg
2015-05-08 8:54 ` Marc Kleine-Budde
0 siblings, 1 reply; 12+ messages in thread
From: John Ernberg @ 2015-05-08 8:45 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can; +Cc: Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 8:45 ` John Ernberg
@ 2015-05-08 8:54 ` Marc Kleine-Budde
2015-05-08 11:17 ` John Ernberg
0 siblings, 1 reply; 12+ messages in thread
From: Marc Kleine-Budde @ 2015-05-08 8:54 UTC (permalink / raw)
To: John Ernberg, linux-can; +Cc: Adam Engström
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 8:54 ` Marc Kleine-Budde
@ 2015-05-08 11:17 ` John Ernberg
2015-05-08 11:54 ` Marc Kleine-Budde
2015-05-11 11:45 ` Pavel Pisa
0 siblings, 2 replies; 12+ messages in thread
From: John Ernberg @ 2015-05-08 11:17 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can; +Cc: Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 11:17 ` John Ernberg
@ 2015-05-08 11:54 ` Marc Kleine-Budde
2015-05-08 12:24 ` John Ernberg
2015-05-11 11:45 ` Pavel Pisa
1 sibling, 1 reply; 12+ messages in thread
From: Marc Kleine-Budde @ 2015-05-08 11:54 UTC (permalink / raw)
To: John Ernberg, linux-can; +Cc: Adam Engström
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 11:54 ` Marc Kleine-Budde
@ 2015-05-08 12:24 ` John Ernberg
2015-05-08 12:31 ` Marc Kleine-Budde
0 siblings, 1 reply; 12+ messages in thread
From: John Ernberg @ 2015-05-08 12:24 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can; +Cc: Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 12:24 ` John Ernberg
@ 2015-05-08 12:31 ` Marc Kleine-Budde
2015-05-08 12:40 ` John Ernberg
0 siblings, 1 reply; 12+ messages in thread
From: Marc Kleine-Budde @ 2015-05-08 12:31 UTC (permalink / raw)
To: John Ernberg, linux-can; +Cc: Adam Engström
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 12:31 ` Marc Kleine-Budde
@ 2015-05-08 12:40 ` John Ernberg
0 siblings, 0 replies; 12+ messages in thread
From: John Ernberg @ 2015-05-08 12:40 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can; +Cc: Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-08 11:17 ` John Ernberg
2015-05-08 11:54 ` Marc Kleine-Budde
@ 2015-05-11 11:45 ` Pavel Pisa
2015-05-11 13:06 ` John Ernberg
1 sibling, 1 reply; 12+ messages in thread
From: Pavel Pisa @ 2015-05-11 11:45 UTC (permalink / raw)
To: John Ernberg; +Cc: Marc Kleine-Budde, linux-can, Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-11 11:45 ` Pavel Pisa
@ 2015-05-11 13:06 ` John Ernberg
2015-05-12 18:09 ` Oliver Hartkopp
0 siblings, 1 reply; 12+ messages in thread
From: John Ernberg @ 2015-05-11 13:06 UTC (permalink / raw)
To: Pavel Pisa; +Cc: Marc Kleine-Budde, linux-can, Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Raw CAN socket support in LXC?
2015-05-11 13:06 ` John Ernberg
@ 2015-05-12 18:09 ` Oliver Hartkopp
0 siblings, 0 replies; 12+ messages in thread
From: Oliver Hartkopp @ 2015-05-12 18:09 UTC (permalink / raw)
To: John Ernberg, Pavel Pisa; +Cc: Marc Kleine-Budde, linux-can, Adam Engström
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-05-12 18:09 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-08 8:12 Raw CAN socket support in LXC? John Ernberg
2015-05-08 8:28 ` Marc Kleine-Budde
2015-05-08 8:45 ` John Ernberg
2015-05-08 8:54 ` Marc Kleine-Budde
2015-05-08 11:17 ` John Ernberg
2015-05-08 11:54 ` Marc Kleine-Budde
2015-05-08 12:24 ` John Ernberg
2015-05-08 12:31 ` Marc Kleine-Budde
2015-05-08 12:40 ` John Ernberg
2015-05-11 11:45 ` Pavel Pisa
2015-05-11 13:06 ` John Ernberg
2015-05-12 18:09 ` Oliver Hartkopp
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.