Expose filtered CAN interface to processes

Expose filtered CAN interface to processes

[Osborne, Paul]

Hello,

I am currently trying to figure out the best way to present a couple
CAN devices to a process in such a way that will allow for filtering
rules for sends on the exposed interface to be filtered according to
some set of rules.

cangw works great for the basic parts of this use case.  That is, I
have traffic coming from vcan<x> to can<x> after filtering and it
works as expected.  The problem I have now is that for the user
process can see both CAN buses.  I would only like them to see the
vcan devices.

Is there a solution for this available in the kernel today or would
this only work with network namespaces (which are not supported for
can right now)?

More accurately, it appears that network namespaces work on CAN
interfaces but there does not appear to be the required support
present for bridging vcan devices as can be done with veth devices
(i.e. ip link add veth0 type veth peer name veth1).

I am new to network namespaces; Am I missing something?  Is this a
real use case for network namespace support?  It sounded like there
was uncertainty on this point with the RFC that was posted back in
September by Andri: http://comments.gmane.org/gmane.linux.can/8589.

Thanks,
Paul

Re: Expose filtered CAN interface to processes

[Oliver Hartkopp]

Hello Paul,

On 01/29/2016 08:06 PM, Osborne, Paul wrote:

> I am currently trying to figure out the best way to present a couple
> CAN devices to a process in such a way that will allow for filtering
> rules for sends on the exposed interface to be filtered according to
> some set of rules.
> 
> cangw works great for the basic parts of this use case.  That is, I
> have traffic coming from vcan<x> to can<x> after filtering and it
> works as expected.  The problem I have now is that for the user
> process can see both CAN buses.  I would only like them to see the
> vcan devices.
> 
> Is there a solution for this available in the kernel today or would
> this only work with network namespaces (which are not supported for
> can right now)?

Right.

> More accurately, it appears that network namespaces work on CAN
> interfaces but there does not appear to be the required support
> present for bridging vcan devices as can be done with veth devices
> (i.e. ip link add veth0 type veth peer name veth1).

I already took a look into the veth stuff and what to do to make (virtual) CAN
interfaces support namespaces - but veth ist pretty different to what we need
for CAN.

> I am new to network namespaces; Am I missing something?  Is this a
> real use case for network namespace support?  It sounded like there
> was uncertainty on this point with the RFC that was posted back in
> September by Andri: http://comments.gmane.org/gmane.linux.can/8589.

Yes. I think this would be the right way to go.

My current idea regarding namespace aware virtual CAN interfaces is to create
virtual CAN interfaces inside a network namespace. These 'vcan with namespace'
interfaces could then be connected via cangw in the initial (real world)
namespace to other can/vcan interfaces (with/without namespace) with cangw rules.

The good thing about this approach is that you can use the filter and
modification capabilities from cangw at the same time.

Regards,
Oliver

Re: Expose filtered CAN interface to processes

[Osborne, Paul]

Hello Oliver/Andri,

>> I am new to network namespaces; Am I missing something?  Is this a
>> real use case for network namespace support?  It sounded like there
>> was uncertainty on this point with the RFC that was posted back in
>> September by Andri: http://comments.gmane.org/gmane.linux.can/8589.
>
> Yes. I think this would be the right way to go.
>
> My current idea regarding namespace aware virtual CAN interfaces is to create
> virtual CAN interfaces inside a network namespace. These 'vcan with namespace'
> interfaces could then be connected via cangw in the initial (real world)
> namespace to other can/vcan interfaces (with/without namespace) with cangw rules.
>
> The good thing about this approach is that you can use the filter and
> modification capabilities from cangw at the same time.

Alright, good to know I am not barking up the wrong tree.  As I am
needing this functionality in the not-too-distant future, I may take a
shot at putting something together based on the work Andri has done
and your comments.

I am also putting together a change to allow for filtering on the data
of CAN messages (in combination with the can_id/mask).  I'm a bit more
skeptical of that change but may submit an RFC for that as well if the
changes end up not being too unpalatable.

Paul

Re: Expose filtered CAN interface to processes

[Oliver Hartkopp]

Hello Paul,

On 01/29/2016 10:53 PM, Osborne, Paul wrote:

>>> I am new to network namespaces; Am I missing something?  Is this a
>>> real use case for network namespace support?  It sounded like there
>>> was uncertainty on this point with the RFC that was posted back in
>>> September by Andri: http://comments.gmane.org/gmane.linux.can/8589.
>>
>> Yes. I think this would be the right way to go.
>>
>> My current idea regarding namespace aware virtual CAN interfaces is to create
>> virtual CAN interfaces inside a network namespace. These 'vcan with namespace'
>> interfaces could then be connected via cangw in the initial (real world)
>> namespace to other can/vcan interfaces (with/without namespace) with cangw rules.
>>
>> The good thing about this approach is that you can use the filter and
>> modification capabilities from cangw at the same time.
> 
> Alright, good to know I am not barking up the wrong tree.  As I am
> needing this functionality in the not-too-distant future, I may take a
> shot at putting something together based on the work Andri has done
> and your comments.

Cool!

> I am also putting together a change to allow for filtering on the data
> of CAN messages (in combination with the can_id/mask).  I'm a bit more
> skeptical of that change but may submit an RFC for that as well if the
> changes end up not being too unpalatable.

Oh - I proposed this idea of using the cangw with a namespace aware
configuration as I did not see the standard way creating vcan peers with

	ip link add vcan0 type vcan peer name vcan1

	ip link set vcan0 netns mynamespace

won't work that way. If you have a 'standard' solution I would be happy to see it.

Using the cangw with filtering would help to have some kind of CAN ID firewall
directly - but this might be done in the global namespace too when connecting
the peered vcan1 to some real can0 ...

You can hopefully follow my thoughts as namespaces are new to me too :-)

Best regards,
Oliver

Re: Expose filtered CAN interface to processes

[Andri Yngvason]

On Fri, Jan 29, 2016 at 09:53:01PM +0000, Osborne, Paul wrote:
> 
> Hello Oliver/Andri,
> 
> >> I am new to network namespaces; Am I missing something?  Is this a
> >> real use case for network namespace support?  It sounded like there
> >> was uncertainty on this point with the RFC that was posted back in
> >> September by Andri: http://comments.gmane.org/gmane.linux.can/8589.
> >
> > Yes. I think this would be the right way to go.
> >
> > My current idea regarding namespace aware virtual CAN interfaces is to create
> > virtual CAN interfaces inside a network namespace. These 'vcan with namespace'
> > interfaces could then be connected via cangw in the initial (real world)
> > namespace to other can/vcan interfaces (with/without namespace) with cangw rules.
> >
> > The good thing about this approach is that you can use the filter and
> > modification capabilities from cangw at the same time.
> 
> Alright, good to know I am not barking up the wrong tree.  As I am
> needing this functionality in the not-too-distant future, I may take a
> shot at putting something together based on the work Andri has done
> and your comments.
>
That would be much appreciated. My patch set crashes on my SMP system but not on
a non-SMP qemu VM.

Feel free to ask me questions. I'll try to answer to the best of my knowledge.

Thanks,
Andri