exclusive access to can interface

exclusive access to can interface

[Alexander Stein]

Hello,

is there a way to get exclusive (write) access to a CAN interface, so that only one bound socket can write CAN frames on the bus?

Best regards,
Alexander

Re: exclusive access to can interface

[Marc Kleine-Budde]

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

On 01/07/2013 05:52 PM, Alexander Stein wrote:
> is there a way to get exclusive (write) access to a CAN interface, so
> that only one bound socket can write CAN frames on the bus?

No, what's the use case?

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: 261 bytes --]

Re: exclusive access to can interface

[Oliver Hartkopp]

On 07.01.2013 17:52, Alexander Stein wrote:

> is there a way to get exclusive (write) access to a CAN interface, so that only one bound socket can write CAN frames on the bus?
> 


Not really.

In a very early SocketCAN implementation we had the possibility to define the capabilities to access CAN sockets. See

http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/net/can/raw.c?op=log&op=log&peg=1258&page=2

We removed it in:

http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/net/can/raw.c?op=revision&rev=489&peg=1258

http://svn.berlios.de/wsvn/socketcan/trunk/kernel/2.6/net/can/raw.c?op=revision&rev=490&peg=1258

You might think about re-introducing some capability checking, e.g. that only root or some other special user may write on CAN RAW sockets.

E.g. see "if (!capable(CAP_NET_RAW))"

http://lxr.linux.no/#linux+v3.7.1/net/packet/af_packet.c#L2480

in packet_create() ...

Regards,
Oliver

Re: exclusive access to can interface

[Alexander Stein]

Hello Marc,

On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
> On 01/07/2013 05:52 PM, Alexander Stein wrote:
> > is there a way to get exclusive (write) access to a CAN interface, so
> > that only one bound socket can write CAN frames on the bus?
> 
> No, what's the use case?

This was a customers request in order to prevent multiple applications (or 
instances) to send CAN frames on a specific CAN interface at the same time 
with the very same CAN-IDs. Concurrent reads shall still be allowed!

Best regards,
Alexander

Re: exclusive access to can interface

[Marc Kleine-Budde]

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

On 01/08/2013 10:23 AM, Alexander Stein wrote:
> Hello Marc,
> 
> On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
>> On 01/07/2013 05:52 PM, Alexander Stein wrote:
>>> is there a way to get exclusive (write) access to a CAN interface, so
>>> that only one bound socket can write CAN frames on the bus?
>>
>> No, what's the use case?
> 
> This was a customers request in order to prevent multiple applications (or 
> instances) to send CAN frames on a specific CAN interface at the same time 
> with the very same CAN-IDs. Concurrent reads shall still be allowed!

Sending CAN frames is proper serialized by the networking subsystem :)
If back to back CAN frames are a problem it seems the design of the
application is fishy.

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: 261 bytes --]

Re: exclusive access to can interface

[Alexander Stein]

Hello,

On Tuesday 08 January 2013 10:32:25, Marc Kleine-Budde wrote:
> On 01/08/2013 10:23 AM, Alexander Stein wrote:
> > Hello Marc,
> > 
> > On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
> >> On 01/07/2013 05:52 PM, Alexander Stein wrote:
> >>> is there a way to get exclusive (write) access to a CAN interface, so
> >>> that only one bound socket can write CAN frames on the bus?
> >>
> >> No, what's the use case?
> > 
> > This was a customers request in order to prevent multiple applications (or 
> > instances) to send CAN frames on a specific CAN interface at the same time 
> > with the very same CAN-IDs. Concurrent reads shall still be allowed!
> 
> Sending CAN frames is proper serialized by the networking subsystem :)
> If back to back CAN frames are a problem it seems the design of the
> application is fishy.

I don't think serializaton or back to back frames are the problem. Think of CANopen there would be the same Node-ID twice on the bus.

Alexander

Re: exclusive access to can interface

[Wolfgang Grandegger]

On 01/08/2013 10:23 AM, Alexander Stein wrote:
> Hello Marc,
> 
> On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
>> On 01/07/2013 05:52 PM, Alexander Stein wrote:
>>> is there a way to get exclusive (write) access to a CAN interface, so
>>> that only one bound socket can write CAN frames on the bus?
>>
>> No, what's the use case?
> 
> This was a customers request in order to prevent multiple applications (or 
> instances) to send CAN frames on a specific CAN interface at the same time 
> with the very same CAN-IDs. Concurrent reads shall still be allowed!

Application == CANopen?! It's like giving exclusive access to a network
device. Isn't that possible? Well, at a first glance I have not found
anything like that.

Wolfgang.

Re: exclusive access to can interface

[Oliver Hartkopp]

Am 08.01.2013 10:48, schrieb Alexander Stein:
> Hello,
>
> On Tuesday 08 January 2013 10:32:25, Marc Kleine-Budde wrote:
>> On 01/08/2013 10:23 AM, Alexander Stein wrote:
>>> Hello Marc,
>>>
>>> On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
>>>> On 01/07/2013 05:52 PM, Alexander Stein wrote:
>>>>> is there a way to get exclusive (write) access to a CAN interface, so
>>>>> that only one bound socket can write CAN frames on the bus?
>>>>
>>>> No, what's the use case?
>>>
>>> This was a customers request in order to prevent multiple applications (or
>>> instances) to send CAN frames on a specific CAN interface at the same time
>>> with the very same CAN-IDs. Concurrent reads shall still be allowed!
>>
>> Sending CAN frames is proper serialized by the networking subsystem :)
>> If back to back CAN frames are a problem it seems the design of the
>> application is fishy.
>
> I don't think serializaton or back to back frames are the problem. Think of CANopen there would be the same Node-ID twice on the bus.
>

This should be solved by the system setup.

E.g. if you start two applications using/providing identical resources at the 
same time, you'll always get into trouble.

If you start two inetd daemons, the second one would fail as he would like to 
bind the same IP ports. But this kind of mechanic is not available with CAN 
sockets.

I would tend to make sure that the Node-ID is always unique in your system.
What would happen, if you start a Node-ID on your host that already exists on 
the CAN networks attached to the system? You have to deal with that too:
E.g. terminate myself with some error logging if i see my own Node-ID

Even if i don't think you should go that way, you can use the can-gw routings 
and let the applications work on different (virtual) CAN interfaces.

One CAN interface, that can write to the real CAN and one that only reads from 
the real CAN:

ip link add dev can0_rw type vcan
ip link add dev can0_ro type vcan

cangw -A -s can0 -d can0_rw -e
cangw -A -s can0_rw -d can0 -e
cangw -A -s can0 -d can0_ro -e

Then let the sending app run on can0_rw and the others on can0_ro.

You might also add CAN filters to these routing rules.

Regards,
Oliver

Re: exclusive access to can interface

[Heinz-Jürgen Oertel]

Am Dienstag, 8. Januar 2013, 11:08:36 schrieb Wolfgang Grandegger:
> On 01/08/2013 10:23 AM, Alexander Stein wrote:
> > Hello Marc,
> > 
> > On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
> >> On 01/07/2013 05:52 PM, Alexander Stein wrote:
> >>> is there a way to get exclusive (write) access to a CAN interface,
> >>> so
> >>> that only one bound socket can write CAN frames on the bus?
> >> 
> >> No, what's the use case?
> > 
> > This was a customers request in order to prevent multiple applications
> > (or instances) to send CAN frames on a specific CAN interface at the
> > same time with the very same CAN-IDs. Concurrent reads shall still be
> > allowed!
> Application == CANopen?! It's like giving exclusive access to a network
> device. Isn't that possible? Well, at a first glance I have not found
> anything like that.
> 
> Wolfgang.

It of course should be possible to start two or more instances of a CAN or 
CANopen application. Sending out the same CAN Id  by the applications should 
inhibited by the application or the system designer starting the CAN(open) 
applications. Like in real life.
In real CAN network each of the CANopen nodes has to have different Node-Ids 
and properly configured PDOs in order to prevent sending the same CAN Id by 
different devices.
Starting two CANopen applications on a Linux box using the same physical CAN
will not disturb the CAN frames, but is wrong by design.
I see no need for the OPs request.

Regards
   Heinz

Re: exclusive access to can interface

[Heinz-Jürgen Oertel]

Am Dienstag, 8. Januar 2013, 11:09:28 schrieb Oliver Hartkopp:
> .....
> This should be solved by the system setup.
 +1
> E.g. if you start two applications using/providing identical resources at
> the same time, you'll always get into trouble.
> 
> If you start two inetd daemons, the second one would fail as he would like
> to bind the same IP ports. But this kind of mechanic is not available with
> CAN sockets.
>
> I would tend to make sure that the Node-ID is always unique in your system.
> What would happen, if you start a Node-ID on your host that already exists
> on the CAN networks attached to the system? You have to deal with that too:
> E.g. terminate myself with some error logging if i see my own Node-ID

that is the point, correct.
 
> .....

regards
   Heinz

Re: exclusive access to can interface

[Alexander Stein]

Hello again,

On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
> On 01/07/2013 05:52 PM, Alexander Stein wrote:
> > is there a way to get exclusive (write) access to a CAN interface, so
> > that only one bound socket can write CAN frames on the bus?
> 
> No, what's the use case?

I have now a more detailed view about the customers request and background: The problem runs some (time consuming) tests using CAN and they want to prohibit CAN write access meanwhile in order to prevent e.g. some (mis-)configuration of CAN devices or firmware updates. In such a case the test might shutdown and needs to be restarted. During the test nobody alse should be allowed to write to the CAN bus. I think this is justified.
It seems this is unrelated to CANopen or user application started twice, like I've expected and written before.

Best regards,
Alexander

Re: exclusive access to can interface

[Kurt Van Dijck]

On 22 Jan 2013, at 10:41, Alexander Stein <alexander.stein@systec-electronic.com> wrote:

> Hello again,
> 
> On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
>> On 01/07/2013 05:52 PM, Alexander Stein wrote:
>>> is there a way to get exclusive (write) access to a CAN interface, so
>>> that only one bound socket can write CAN frames on the bus?
>> 
>> No, what's the use case?
> 
> I have now a more detailed view about the customers request and background: The problem runs some (time consuming) tests using CAN and they want to prohibit CAN write access meanwhile in order to prevent e.g. some (mis-)configuration of CAN devices or firmware updates. In such a case the test might shutdown and needs to be
exclusive access could be used to prevent possible race conditions, not to solve configuration of the local software.
 
> restarted. During the test nobody alse should be allowed to write to the CAN bus. I think this is justified.
"Nobody should write to the CAN bus" != "Nobody should be allowed to write to the CAN bus"

The exclusive access is only enforce on the local system. Other participants on the CAN bus
still are able to write to the CAN bus.
Your problem won't be solved.

> It seems this is unrelated to CANopen or user application started twice, like I've expected and written before.
> 
> Best regards,
> Alexander
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: exclusive access to can interface

[Alexander Stein]

On Tuesday 22 January 2013 13:53:22, Kurt Van Dijck wrote:
> On 22 Jan 2013, at 10:41, Alexander Stein <alexander.stein@systec-electronic.com> wrote:
> 
> > Hello again,
> > 
> > On Monday 07 January 2013 19:16:20, Marc Kleine-Budde wrote:
> >> On 01/07/2013 05:52 PM, Alexander Stein wrote:
> >>> is there a way to get exclusive (write) access to a CAN interface, so
> >>> that only one bound socket can write CAN frames on the bus?
> >> 
> >> No, what's the use case?
> > 
> > I have now a more detailed view about the customers request and background: The problem runs some (time consuming) tests using CAN and they want to prohibit CAN write access meanwhile in order to prevent e.g. some (mis-)configuration of CAN devices or firmware updates. In such a case the test might shutdown and needs to be
> exclusive access could be used to prevent possible race conditions, not to solve configuration of the local software.
>  
> > restarted. During the test nobody alse should be allowed to write to the CAN bus. I think this is justified.
> "Nobody should write to the CAN bus" != "Nobody should be allowed to write to the CAN bus"
> 
> The exclusive access is only enforce on the local system. Other participants on the CAN bus
> still are able to write to the CAN bus.
> Your problem won't be solved.

As this specific CAN interface is the only access to this CAN network it is enough. It is obvious that you can't lock this bus completly, the same is for file locking on networking file systems, they either don't work at all or just locally.

Best regards,
Alexander