[LTP] New LTP test for CAN packet flow

[LTP] New LTP test for CAN packet flow

[Oliver Hartkopp]

Dear Subrata,

long time - no update ;-)

But now i created a test that's able to detect a corrupt CAN frame flow inside
the Kernel. So far the correct IFF_ECHO functionality has been accidentally
removed by netdev patches two times.

The latest fix was here:

http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=cff0d6e6edac7672b3f915bb4fb59f279243b7f9

To perform the local echo of CAN frames, the reference to the originating sock
struct has to be passed to the netdevice without orphan of the socketbuffer.

The new test tool 'tst-rcv-own-msgs' can check the correct packet flow by
creating two can-raw sockets.

To extend your test-script in

    network/can/filter-tests/run_ltp-can_tests.sh

the modprobe of the vcan driver needs an additional parameter 'echo=1', which
configures the driver to perform the CAN frame echo on driver level.

This 'echo=1' setting does not have any impact to the filtertest performed in
your script.

The new tool 'tst-rcv-own-msgs' can be found in the same directory in the
SocketCAN SVN where the current 'tst-filter-server' and 'tst-filter-master'
tools are located too.

I'll send the latest fix (see above) to the stable tree, as 2.6.35.3 currently
still *has* this problem.

On 2.6.35.3 you can see 'tst-rcv-own-msgs' ...

   - work correctly when echo=0
   - will fail when echo=1

On 2.6.36-rc1 'tst-rcv-own-msgs' runs successfully regardless of the 'echo'
setting of the vcan driver.

Please give me feedback, if there are still open questions.

Many thanks for your work & best regards,
Oliver


---

Load vcan module with commandline parameter echo=1 :

root@host:~# modprobe vcan echo=1
root@host:~# ip link add dev vcan0 type vcan
root@host:~# ip link set vcan0 up

---

When the test is successful, it looks like this:

user@host:~$ socketcan/trunk/test/tst-rcv-own-msgs vcan0
Starting PF_CAN frame flow test.
checking socket default settings ... ok.
check loopback 0 recv_own_msgs 0 ... ok.
check loopback 0 recv_own_msgs 1 ... ok.
check loopback 1 recv_own_msgs 0 ... ok.
check loopback 1 recv_own_msgs 1 ... ok.
PF_CAN frame flow test was successful.
user@host:~$ echo $?
0
user@host:~$

---

When the test fails, it looks like this:

user@host:~$ socketcan/trunk/test/tst-rcv-own-msgs vcan0
Starting PF_CAN frame flow test.
checking socket default settings ... failure!
user@host:~$ echo $?
1
user@host:~$

---


------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New LTP test for CAN packet flow

[Subrata Modak]

[-- Attachment #1.1: Type: text/plain, Size: 3333 bytes --]

Thanks very much. Not sure why it did not reach the actual LTP mailing list
:-(

Regards--
Subrata

On Mon, Aug 23, 2010 at 11:53 PM, Oliver Hartkopp <socketcan@hartkopp.net>wrote:

> Dear Subrata,
>
> long time - no update ;-)
>
> But now i created a test that's able to detect a corrupt CAN frame flow
> inside
> the Kernel. So far the correct IFF_ECHO functionality has been accidentally
> removed by netdev patches two times.
>
> The latest fix was here:
>
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=cff0d6e6edac7672b3f915bb4fb59f279243b7f9
>
> To perform the local echo of CAN frames, the reference to the originating
> sock
> struct has to be passed to the netdevice without orphan of the
> socketbuffer.
>
> The new test tool 'tst-rcv-own-msgs' can check the correct packet flow by
> creating two can-raw sockets.
>
> To extend your test-script in
>
>    network/can/filter-tests/run_ltp-can_tests.sh
>
> the modprobe of the vcan driver needs an additional parameter 'echo=1',
> which
> configures the driver to perform the CAN frame echo on driver level.
>
> This 'echo=1' setting does not have any impact to the filtertest performed
> in
> your script.
>
> The new tool 'tst-rcv-own-msgs' can be found in the same directory in the
> SocketCAN SVN where the current 'tst-filter-server' and 'tst-filter-master'
> tools are located too.
>
> I'll send the latest fix (see above) to the stable tree, as 2.6.35.3
> currently
> still *has* this problem.
>
> On 2.6.35.3 you can see 'tst-rcv-own-msgs' ...
>
>   - work correctly when echo=0
>   - will fail when echo=1
>
> On 2.6.36-rc1 'tst-rcv-own-msgs' runs successfully regardless of the 'echo'
> setting of the vcan driver.
>
> Please give me feedback, if there are still open questions.
>
> Many thanks for your work & best regards,
> Oliver
>
>
> ---
>
> Load vcan module with commandline parameter echo=1 :
>
> root@host:~# modprobe vcan echo=1
> root@host:~# ip link add dev vcan0 type vcan
> root@host:~# ip link set vcan0 up
>
> ---
>
> When the test is successful, it looks like this:
>
> user@host:~$ socketcan/trunk/test/tst-rcv-own-msgs vcan0
> Starting PF_CAN frame flow test.
> checking socket default settings ... ok.
> check loopback 0 recv_own_msgs 0 ... ok.
> check loopback 0 recv_own_msgs 1 ... ok.
> check loopback 1 recv_own_msgs 0 ... ok.
> check loopback 1 recv_own_msgs 1 ... ok.
> PF_CAN frame flow test was successful.
> user@host:~$ echo $?
> 0
> user@host:~$
>
> ---
>
> When the test fails, it looks like this:
>
> user@host:~$ socketcan/trunk/test/tst-rcv-own-msgs vcan0
> Starting PF_CAN frame flow test.
> checking socket default settings ... failure!
> user@host:~$ echo $?
> 1
> user@host:~$
>
> ---
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>



-- 
Regards & Thanks--
Subrata

[-- Attachment #1.2: Type: text/html, Size: 4378 bytes --]

[-- Attachment #2: Type: text/plain, Size: 392 bytes --]

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] New LTP test for CAN packet flow

[Subrata Modak]

Oliver,

Can you send us a patch to extend this testcase ?

Regards--
Subrata

On Tue, 2010-08-24 at 12:44 +0530, Subrata Modak wrote:
> Thanks very much. Not sure why it did not reach the actual LTP mailing
> list :-(
> 
> Regards--
> Subrata
> 
> On Mon, Aug 23, 2010 at 11:53 PM, Oliver Hartkopp
> <socketcan@hartkopp.net> wrote:
>         Dear Subrata,
>         
>         long time - no update ;-)
>         
>         But now i created a test that's able to detect a corrupt CAN
>         frame flow inside
>         the Kernel. So far the correct IFF_ECHO functionality has been
>         accidentally
>         removed by netdev patches two times.
>         
>         The latest fix was here:
>         
>         http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=cff0d6e6edac7672b3f915bb4fb59f279243b7f9
>         
>         To perform the local echo of CAN frames, the reference to the
>         originating sock
>         struct has to be passed to the netdevice without orphan of the
>         socketbuffer.
>         
>         The new test tool 'tst-rcv-own-msgs' can check the correct
>         packet flow by
>         creating two can-raw sockets.
>         
>         To extend your test-script in
>         
>            network/can/filter-tests/run_ltp-can_tests.sh
>         
>         the modprobe of the vcan driver needs an additional parameter
>         'echo=1', which
>         configures the driver to perform the CAN frame echo on driver
>         level.
>         
>         This 'echo=1' setting does not have any impact to the
>         filtertest performed in
>         your script.
>         
>         The new tool 'tst-rcv-own-msgs' can be found in the same
>         directory in the
>         SocketCAN SVN where the current 'tst-filter-server' and
>         'tst-filter-master'
>         tools are located too.
>         
>         I'll send the latest fix (see above) to the stable tree, as
>         2.6.35.3 currently
>         still *has* this problem.
>         
>         On 2.6.35.3 you can see 'tst-rcv-own-msgs' ...
>         
>           - work correctly when echo=0
>           - will fail when echo=1
>         
>         On 2.6.36-rc1 'tst-rcv-own-msgs' runs successfully regardless
>         of the 'echo'
>         setting of the vcan driver.
>         
>         Please give me feedback, if there are still open questions.
>         
>         Many thanks for your work & best regards,
>         Oliver
>         
>         
>         ---
>         
>         Load vcan module with commandline parameter echo=1 :
>         
>         root@host:~# modprobe vcan echo=1
>         root@host:~# ip link add dev vcan0 type vcan
>         root@host:~# ip link set vcan0 up
>         
>         ---
>         
>         When the test is successful, it looks like this:
>         
>         user@host:~$ socketcan/trunk/test/tst-rcv-own-msgs vcan0
>         Starting PF_CAN frame flow test.
>         checking socket default settings ... ok.
>         check loopback 0 recv_own_msgs 0 ... ok.
>         check loopback 0 recv_own_msgs 1 ... ok.
>         check loopback 1 recv_own_msgs 0 ... ok.
>         check loopback 1 recv_own_msgs 1 ... ok.
>         PF_CAN frame flow test was successful.
>         user@host:~$ echo $?
>         0
>         user@host:~$
>         
>         ---
>         
>         When the test fails, it looks like this:
>         
>         user@host:~$ socketcan/trunk/test/tst-rcv-own-msgs vcan0
>         Starting PF_CAN frame flow test.
>         checking socket default settings ... failure!
>         user@host:~$ echo $?
>         1
>         user@host:~$
>         
>         ---
>         
>         
>         ------------------------------------------------------------------------------
>         Sell apps to millions through the Intel(R) Atom(Tm) Developer
>         Program
>         Be part of this innovative community and reach millions of
>         netbook users
>         worldwide. Take advantage of special opportunities to increase
>         revenue and
>         speed time-to-market. Join now, and jumpstart your future.
>         http://p.sf.net/sfu/intel-atom-d2d
>         _______________________________________________
>         Ltp-list mailing list
>         Ltp-list@lists.sourceforge.net
>         https://lists.sourceforge.net/lists/listinfo/ltp-list 
> 
> 
> 
> -- 
> Regards & Thanks--
> Subrata


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list