All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Ernberg <john.ernberg@actia.se>
To: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Cc: "Marc Kleine-Budde" <mkl@pengutronix.de>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	"Adam Engström" <adam.engstrom@actia.se>
Subject: Re: Raw CAN socket support in LXC?
Date: Mon, 11 May 2015 13:06:26 +0000	[thread overview]
Message-ID: <5550A95B.1000605@actia.se> (raw)
In-Reply-To: <201505111345.51998.pisa@cmp.felk.cvut.cz>

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

  reply	other threads:[~2015-05-11 13:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2015-05-12 18:09             ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5550A95B.1000605@actia.se \
    --to=john.ernberg@actia.se \
    --cc=adam.engstrom@actia.se \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=pisa@cmp.felk.cvut.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.