* 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.