netdev - Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Jul 2007 18:00:27 +0200
From:	Oliver Hartkopp <oliver@...tkopp.net>
To:	Patrick McHardy <kaber@...sh.net>
CC:	Urs Thuermann <urs@...ogud.escape.de>,
	David Miller <davem@...emloft.net>,
	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>,
	j.hadi123@...il.com, netdev@...r.kernel.org
Subject: Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>   
>> the people get the loopback functionality in ANY case. There is indeed
>> no difference from the view of the users, if you change this switch.
>>
>> The possibility to enable the loopback on vcan driver level is only to ...
>>
>> 1. Test the loopback fallback code in af_can.c
>> 2. Show, how a correct loopback handling is to be implemented
>>
>> ... nothing more.
>>     
>
>
> So its the "correct" handling and the other one is only fallback? That
> still sounds like it wants proper configuration. How does loopback work
> without this driver?
>   

As the addressing in CAN consist of a CAN-identifier and a CAN-interface
you always have at least one available CAN-interface you are working on.
In our case we may have several virtual CAN-interfaces.

On the CAN bus there is a CSMA/CA access with arbitration by the
CAN-identifier.
Due to the arbitration on the CAN bus the _transmission_ of a low prio
CAN-ID
may be delayed from the _receipition_ of a high prio CAN frame. To
reflect the correct traffic on the node the loopback of the sent
data has to be performed right _after_ a successful transmission. If
the CAN network interface is not capable to perform the loopback for
some reason the PF_CAN core can do this task as a fallback solution.

There are low cost adapters that are connected via some kind of ASCII
protocol on a serial line. These low cost adapters do not provide any TX
acknowledge that may be used to initiate the loopback receiption for the
sent CAN-frame . They are really dumb.

So you can divide the CAN controller drivers into two classes:

1. With an ACK (e.g. a valid TX interrupt) to trigger the loopback of
the sent frame
2. Without any feedback (the dumb one)

The intelligent ones (1.) do set dev->flags = (IFF_NOARP | IFF_LOOPBACK);
The dumb ones (2.) only set dev->flags = IFF_NOARP;

If a CAN-frame has to be looped back (the default), the function
can_send() in af_can.c looks whether the interface is capable to perform
the loopback or not (by checking the IFF_LOOPBACK flag in dev->flags).
In the case of a dumb interface the CAN-frame is looped back
immediately. In the case of an intelligent interface the CAN core keeps
it's hands off and lets the interface do the loopback. This should be
the usual case.

The loopback module parameter in the vcan driver enables or disables the
loopback on driver level, to test whether the fallback functionality for
'dumb interfaces' in af_can.c is working properly or not. Maybe it
should therefore be renamed to 'testloopback' or it should be removed
completely.

>From the functional side the user is not able to feel any difference
whether the loopback test is enabled in the vcan driver or not.

Thanks very much for your feedback!

Best regards,
Oliver

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html