using can-j1939

using can-j1939

[Kurt Van Dijck]

On Thu, Dec 01, 2011 at 11:54:34AM +0100, Wolfgang Wagner wrote:
> Hi,
> 
> thank you very much for your fast response. Glad that you will help me.
> 
> I want to run the can-j1939 for linux on a Phytec phycore MPC5121e with kernel release 2.6.33.5-rt2x-ptx-pcm046-3.
I'm not that much used with specific drivers & releases. I included linux-can
mailing list, maybe they can help to use out-of-tree CAN modules on your system.
> 
> I managed to download the 3 thing you told me, but now I don't know to move on - I am really desperated because I can't find any proper documentation.
Did you read Documentation/networking/can/j1939.txt from the can-j1939-modules?

The Documentation is a currently a weak point. I've had some busy months,
and j1939 dissappeared from my priorities since our system is working
properly.

Oliver Hartkopp has already proposed to work out some use-cases, but as said,
I've not found time for that yet.
Maybe this is a good opportunity to do so...

Kurt Van Dijck
> 
> I would be really pleased about your help!
> 
> Kind regards,
> 
> Wolfgang Wagner
> 
> 
> 
> -------- Original-Nachricht --------
> Datum: Thu, 1 Dec 2011 10:07:03 +0100
> Von: Gitorious <no-reply@gitorious.org>
> An: wutz@unterderbruecke.de
> Betreff: New message: Re: j1939
> 
> 
> 
> Hello wutzol
> 
> Kurt Van Dijck has sent you a message on Gitorious:
> ----------------------------------------------------
> 
> Hi,
> 
> Thanks for your interest in can-j1939 for linux.
> In order to use our can-j1939 for linux, you will need 3 things:
> * can-j1939 kernel stack on https://gitorious.org/~kurt-vd/linux-can/can-j1939-modules
>   I've had a patchset to patch the net-next-2.6 linux branch, but it is a bit outdated.
> * can-j1939 utilities on https://gitorious.org/~kurt-vd/linux-can/can-j1939-utils
>   This branch of can-utils contains some additional j1939 specific programs
> * iproute2-j1939 on https://gitorious.org/~kurt-vd/linux-can/iproute2-j1939
>   This replaces iproute2, and adds j1939 specific commands:
>   * turn j1939 on for a specific can device
>   * manage j1939 addressing info for a can device
> 
> Since linux-can moved to gitorious only recently, I'm not sure all my repositories are already up to date. I will check that.
> 
> In the kernel modules, a Documentation/networking/j1939.txt (or similar) is provided.
> I'll be interested in helping you using the j1939 stack. Therefore, you may
> participate in linux-can@vger.kernel.org (linux-can mailing list) or email me directly
> (you'll find my email in the git repositories).
> 
> Kind regards,
> Kurt Van Dijck
> 
> 
> ----------------------------------------------------
> View and reply to this message at https://gitorious.org/messages/118259
> 
> PLEASE DO NOT reply to this email directly as it will go
> nowhere. Instead, use the above link to reply.
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: using can-j1939

[Kurt Van Dijck]

Wolfgang,

> Did you read Documentation/networking/can/j1939.txt from the can-j1939-modules?
In order to not overload you too much, can you (high-level) describe what
you're about to do?
* using dynamic address claiming vs. static addresses
* writing own programs vs. using some predefined cansend/candump.
* sending & receiving vs. receive only.
....

Kind regards,
Kurt Van Dijck

Re: using can-j1939

[Oliver Hartkopp]

On 01.12.2011 12:52, Kurt Van Dijck wrote:

> On Thu, Dec 01, 2011 at 11:54:34AM +0100, Wolfgang Wagner wrote:
>> Hi,
>>
>> thank you very much for your fast response. Glad that you will help me.
>>
>> I want to run the can-j1939 for linux on a Phytec phycore MPC5121e with kernel release 2.6.33.5-rt2x-ptx-pcm046-3.
> I'm not that much used with specific drivers & releases. I included linux-can
> mailing list, maybe they can help to use out-of-tree CAN modules on your system.
>>
>> I managed to download the 3 thing you told me, but now I don't know to move on - I am really desperated because I can't find any proper documentation.
> Did you read Documentation/networking/can/j1939.txt from the can-j1939-modules?
> 
> The Documentation is a currently a weak point. I've had some busy months,
> and j1939 dissappeared from my priorities since our system is working
> properly.
> 
> Oliver Hartkopp has already proposed to work out some use-cases, but as said,
> I've not found time for that yet.
> Maybe this is a good opportunity to do so...


Yeah. Some things continuously pop up after some time :-)

@Wolfgang W.: We had a quite interesting and long discussion about Kurts
suggested implementation. Especially on how to deal with address claiming.
Currently the AUTOSAR J1939 specifications nearly ignore the AC which provides
the possibility of having a simple PDU interface.
But if we want to do AC the discussion comes up how much of it we put into the
kernel-space and how much we do in user-space (e.g. with an AC daemon).

I think Kurt also asked you about your planned setup. Is address claiming also
part of it?

Regards,
Oliver

using can-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 01:43:30PM +0000, Wolfgang wrote:
> I copied all things as you told me, I think/hope the hardest part is over now.
> Thank you!!
> 
> 
> What do I have to do afterwards I did
> 
> $ echo can0 /proc/net/can-j1939/net
$ echo can0 > /proc/net/can-j1939/net

> 
> because if I do '$ifconfig can0 up' it responses with 
> 
> mpc52xx_can 80001300.mscan: bit-timing not yet defined
> ifconfig: SIOCSIFFLAGS: Invalid argument

try:

$ ip link set can0 up type can bitrate 250000
> 
> 
> (Just for information this time different answer:
> $ ip link set can0 j1939 on
> RTNETLINK answers: Invalid argument )
> 

now, you can:

$ jspy -P
to see all j1939 packets. Transport Protocol sessions are assembled into big packets.

> Is there any documentation
There isn't much documenation yet of jspy & jsr, but they are basic tools.

$ jspy -?
produces:
jspy: An SAE J1939 spy utility
Usage: jspy [OPTION...] [[IFACE:][NAME|SA][,PGN]]

  -v, --verbose         Increase verbosity
  -P, --promisc         Run in promiscuous mode
                        (= receive traffic not for this ECU)
  -b, --block=SIZE      Use a receive buffer of SIZE (default 1024)
  -t, --time[=a|d|z|A]  Show time: (a)bsolute, (d)elta, (z)ero, (A)bsolute w date

$ jsr -?
produces:
jsr: An SAE J1939 send/recv utility
Usage: jsr [OPTION...] SOURCE [DEST]

  -v, --verbose         Increase verbosity
  -p, --priority=VAL    J1939 priority (0..7, default 6)
  -S, --serialize       Strictly serialize outgoing packets
  -s, --size            Packet size, default autodetected

  SOURCE        [IFACE:][NAME|SA][,PGN]
  DEST                  [NAME|SA]

jsr allows you to put stdin into transmitted j1939 packets, and received j1939 packets
onto stdout.

jacd is used for dynamic address claiming. I believe it's a bit early to start with.

$ ip
can now be used to:
* add SA 0x80 to can0

$ ip addr add j1939 0x80 dev can0

from that point, 0x80 can be used to send packets with.

and likewise
$ ip addr del j1939 0x80 dev can0

$ ip addr
may show things like:

4: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN qlen 10
    link/can 
    can-j1939 0x80 scope link 

> or is it possible to use cangw with API?
cangw (like can-j1939) is not present in your 2.6.31 kernel.
Since you managed importing can-j1939, importing cangw will succeed definitely.
cangw requires less modification in userspace tools ...

Before proceeding however, what exactly is the application?
Will you bridge j1939 packets unmodified?
Are transport sessions involved?
Is information repacked into different packets?

...
Kurt

Re: using can-j1939

[Wolfgang]

> Before proceeding however, what exactly is the application?
> Will you bridge j1939 packets unmodified?

I want read from one bus modify the data field of the j1939 frame and write the
modified packet on the other bus.

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 02:49:44PM +0000, Wolfgang wrote:
> > Before proceeding however, what exactly is the application?
> > Will you bridge j1939 packets unmodified?
> 
> I want read from one bus modify the data field of the j1939 frame and write the
> modified packet on the other bus.
So only 1 PGN is bridged? No other PGN's.

Kurt

Re: using can-j1939

[Wolfgang]

> So only 1 PGN is bridged? No other PGN's.

For the first steps I would be happy with 1 but finally and if it isn't 
'impossible' 3.

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 03:16:05PM +0000, Wolfgang wrote:
> > So only 1 PGN is bridged? No other PGN's.
> 
> For the first steps I would be happy with 1 but finally and if it isn't 
> 'impossible' 3.
ok. a limited number :-)

Do you relay them (on the second bus) using the same source address, i.e.
to all 3 PGN's use the same source address when sent out?
The source addresses of the 3 received PGN's (on the first bus) do not matter.

In fact, a limited number here is fine too.
The thing is, my can-j1939 stack is (BSD sockets alike) assigned a limited
number of J1939 source addresses. Only those source addresses are allowed
in outgoing packets (a bit like IP networks, and probably others)

You can do unmodified relaying even from the command line
by piping 2 instances of jsr, like

$ ip addr add j1939 0x80 dev can1
$ jsr can0:80,feda | jsr can1:80,feda

This should do some basics already.

Kurt

Re: using can-j1939

[Wolfgang]

> Do you relay them (on the second bus) using the same source address, 
>i.e.to all 3 PGN's use the same source address when sent out?
> The source addresses of the 3 received PGN's (on the first bus) 
>do not matter.
 
 In fact, a limited number here is fine too.
 The thing is, my can-j1939 stack is (BSD sockets alike) assigned a 
limited number of J1939 source addresses. Only those source addresses 
are allowed in outgoing packets (a bit like IP networks, 
and probably others)


No, all 3 PGNs are sent by one sender(source)!

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

> I want read from one bus modify the data field of the j1939 frame and write the
> modified packet on the other bus.
Are the packets 'broadcasted' or destination specific?

Kurt

Re: using can-j1939

[Wolfgang]

> Are the packets 'broadcasted' or destination specific?

The packets are destination specific. But I was wrong the, it should read and
write from both bus' - sorry, but only 2 specific address'!

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Fri, Dec 16, 2011 at 09:00:45AM +0000, Wolfgang wrote:
> > Are the packets 'broadcasted' or destination specific?
> 
> The packets are destination specific.
> But I was wrong the, it should read and
> write from both bus' - sorry, but only 2 specific address'!
Even that is no problem...

Re: using can-j1939

[Wolfgang]

> > The packets are destination specific.
> > But I was wrong the, it should read and
> > write from both bus' - sorry, but only 2 specific address'!
> Even that is no problem...

OK, this sounds great. I am just browsing through the documentation and wondering
if it is possible to activate j1939 per default, that it would be possible to use
the target as stand alone.

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Fri, Dec 16, 2011 at 02:29:45PM +0000, Wolfgang wrote:
> > > The packets are destination specific.
> > > But I was wrong the, it should read and
> > > write from both bus' - sorry, but only 2 specific address'!
> > Even that is no problem...
> 
> OK, this sounds great. I am just browsing through the documentation and wondering
> if it is possible to activate j1939 per default,
Of course this is possible, but unwanted.
This choice is comparable to "not setting 250Kb per default".
Read more below.

> that it would be possible to use
> the target as stand alone.
You should initialize the CAN bus(ses) on powerup:
* set baudrate
* set j1939 on
* set iface up.

Typically this is done in some init scripts.

Kind regards,
Kurt

using can-j1939

[Kurt Van Dijck]

On Wed, Dec 21, 2011 at 10:46:44AM +0000, Wolfgang wrote:
> 
> It is working, the ID is composed 18FFD080, thanks. I also tried recv() - it is 
> working as well. 
Great!!

> Is it possible to implement only the bytes you really need from the data array,
> because the dlc is always 8.
I bet len (= sizeof(frame.data) in your example) is 8.
If you want to send 3 bytes, then supply 3 bytes to the kernel!
> So sendto() is used to send to a specific address, at the moment I am always
> doing broadcast?
yes.
> 
> --Wolfgang
> 
> 
> --
> 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: using can-j1939

[Wolfgang]

> I bet len (= sizeof(frame.data) in your example) is 8.
> If you want to send 3 bytes, then supply 3 bytes to the kernel!
OK, so I set the unused bytes 0 and don't care.


> > So sendto() is used to send to a specific address, at the moment I am always
> > doing broadcast?
> yes.
Maybe you can give me a hint what I did wrong
...
addr.can_addr.j1939.name = 0x81;
....
if (sendto(s, frame.data, strlen(frame.data), 0, (void *)&addr, \
sizeof(frame.data))<0)
    {
    	perror ("sendto failed");
    }


One general question, am I right, you have to create for every different
struct sockaddr_can (different pgn etc.) one socket per 
interface?

Gratefully,
Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Wed, Dec 21, 2011 at 03:11:30PM +0000, Wolfgang wrote:
> > I bet len (= sizeof(frame.data) in your example) is 8.
> > If you want to send 3 bytes, then supply 3 bytes to the kernel!
> OK, so I set the unused bytes 0 and don't care.
you should not have unused bytes, but I believe you get the picture...
> 
> 
> > > So sendto() is used to send to a specific address, at the moment I am always
> > > doing broadcast?
> > yes.
> Maybe you can give me a hint what I did wrong
> ...
> addr.can_addr.j1939.name = 0x81;
> ....
> if (sendto(s, frame.data, strlen(frame.data), 0, (void *)&addr, \
> sizeof(frame.data))<0)
sendto(s, frame.data, strlen(frame.data), 0, (void *)&addr, sizeof(addr)/*!!!*/)
you supplied the sizeof frame.data, where you should supply the size of addr.

>     {
>     	perror ("sendto failed");
>     }
> 
> 
> One general question, am I right, you have to create for every different
> struct sockaddr_can (different pgn etc.) one socket per 
> interface?
You will want to create 1 socket per interface and per used source address.

You bind with can_addr.j1939.addr = 0x80 and can_addr.j1939.pgn = J1939_NO_PGN
then you can do sendto with dest_addr.j1939.sa = DEST address &
dest_addr.j1939.pgn = YOUR_PGN.

So, the latter YOUR_PGN may vary with each call.
The option to preset a PGN during bind() allows to use write & send on the socket
but is an inferior option in this regard.

Kurt

Re: using can-j1939

[Wolfgang]

> You will want to create 1 socket per interface and per used source address.

OK, 2 source address, 2 interfaces = 4 sockets?!
 
> You bind with can_addr.j1939.addr = 0x80 and can_addr.j1939.pgn = J1939_NO_PGN
> then you can do sendto with dest_addr.j1939.sa = DEST address &
> dest_addr.j1939.pgn = YOUR_PGN.

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>
#include <sys/types.h>


int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	{
    		perror ("bind failed");
        	}     	
   
  		struct sockaddr_can dest_addr;
  		
  		memset(&dest_addr, 0, sizeof(dest_addr));
		dest_addr.can_addr.j1939.name = 0x9ABCDEFULL;
    	        dest_addr.can_addr.j1939.pgn = 0x12300;

	
	if (sendto(s, frame.data, sizeof (frame.data), 0, (void *)&dest_addr, \
sizeof(dest_addr))<0)
		{
			perror ("sendto failed");
		       }
  		 
 return 0;
}

I hope I get that right, with the new struct sockaddr_can. But anything is wrong
$sendto failed: Invalid argument. Sure I got the solution?!?


Thanks,
--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Thu, Dec 22, 2011 at 01:06:06PM +0000, Wolfgang wrote:
> > You will want to create 1 socket per interface and per used source address.
> 
> OK, 2 source address, 2 interfaces = 4 sockets?!
I assume you utilize 2 source addresses, one on each interface? In that case, you
need only 2 sockets.
>  
> > You bind with can_addr.j1939.addr = 0x80 and can_addr.j1939.pgn = J1939_NO_PGN
> > then you can do sendto with dest_addr.j1939.sa = DEST address &
> > dest_addr.j1939.pgn = YOUR_PGN.
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
> #include <linux/can/j1939.h>
> #include <linux/can.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
> #include <sys/types.h>
> 
> 
> int main (void)
> {
> 	int s;
> 	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
> 	struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = J1939_NO_NAME;    
>     addr.can_addr.j1939.addr = 0x80;
>     addr.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr.can_family = AF_CAN;  
>    
>    
>     if (bind(s, (void *)&addr, sizeof(addr))<0)
>     	{
>     		perror ("bind failed");
>         	}     	
>    
>   		struct sockaddr_can dest_addr;
>   		
>   		memset(&dest_addr, 0, sizeof(dest_addr));
please set the can_family type, to avoid EINVAL
		dest_addr.can_family = AF_CAN;  
Since I suppose you do not use dynamic address claiming, do:
		dest_addr.can_addr.j1939.name = J1939_NO_NAME;
for broadcasted messages:
		dest_addr.can_addr.j1939.addr = J1939_NO_ADDR;
for destination specific messages, set .addr to the destination address.

> 		dest_addr.can_addr.j1939.name = 0x9ABCDEFULL;
>     	        dest_addr.can_addr.j1939.pgn = 0x12300;
> 
> 	
> 	if (sendto(s, frame.data, sizeof (frame.data), 0, (void *)&dest_addr, \
> sizeof(dest_addr))<0)
> 		{
> 			perror ("sendto failed");
> 		       }
>   		 
>  return 0;
> }
> 
> I hope I get that right, with the new struct sockaddr_can. But anything is wrong
> $sendto failed: Invalid argument. Sure I got the solution?!?
We're getting there ...
Kurt
> 
> 
> Thanks,
> --Wolfgang
> 
> 
> 
> 
> --
> 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: using can-j1939

[Wolfgang]

Hi,

am I right, if I start for every pgn I want to bridge a new process? Or will it
work if all pgns to be bridged are in one process? I'm just wondering what will
bring a better performance? 

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Wed, Dec 28, 2011 at 10:49:39AM +0000, Wolfgang wrote:
> Hi,
> 
> am I right, if I start for every pgn I want to bridge a new process? Or will it
> work if all pgns to be bridged are in one process? I'm just wondering what will
> bring a better performance? 
A third option is to start 1 process, with different sockets, each socket bridging 1 pgn.

They all work.
I have no idea what will bring the best performance.
I think your second option will bring:
* the most understandable source code...
* less memory consumption
* less scheduler load
* more transparency (FIFO operation is lost when using different processes)

Kurt
> 
> --Wolfgang
> 
> --
> 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