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

Re: backporting can & can-j1939

[Kurt Van Dijck]

On Tue, Dec 13, 2011 at 03:20:24PM +0000, Wolfgang wrote:
> > It appears quite complex. It may be better to start over
> > with a fresh kernel, and copy those files from my
> > can-j1939-modules, since this repository contains
> > #if KERNEL_VERSION macros that will make it work on 2.6.31.
> 
> I am not really sure, so I ask, should I build a new kernel and after building
> replace the things from can-j1939-modules or should I place the things from
> can-j1939-modules before building the kernel?
> And what particular things should I copy?

Ok, Maybe I did explain it a bit fuzzy.

Like Oliver suggested earlier, you will ultimately build a new kernel.
1. You extract the kernel source (I believe $ptxdist prepare <kernel>).
2. You copy from can-j1939-modules into the extracted kernel sources:
   $ cp -r <can-j1939>/net/can/* <kernel>/net/can/
   $ cp <can-j1939>/include/socketcan/can.h <kernel>/include/linux/can.h
   $ cp <can-j1939>/include/socketcan/can/{bcm,core,error,gw,isotp,j1939,netlink,raw}.h \
	<kernel>/include/linux/can/
   and replace all "#include <socketcan/xxx.h>"
   with "#include <linux/xxx.h>".
   This "#include" thing will appear in files you just copies (net/can/* and include/linux/can*)
3. Continue the build process

Sorry for not making this clear the first time :-).
I hope it is clear now?

Kurt

Re: backporting can & can-j1939

[Wolfgang]

Your proposal worked perfect, I can still hardly believe it.

on the target:

$ dmesg | fgrep -i can

mpc52xx_can 80001300.mscan: MSCAN at 0xd1080300, irq 16, clock 100000000 Hz
mpc52xx_can 80001380.mscan: MSCAN at 0xd1084380, irq 17, clock 100000000 Hz
can: controller area network core (rev 20090105 abi 8)
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
can: netlink gateway (rev 20101209)
can: SAE J1939


but when I type (according  to the j1939.txt)

$ ip link set can0 j1939 on

it says:

Error: either "dev" is duplicate, or "j1939" is a garbage.

What have I done wrong, or how is it made right?


Thank you very much so far!!

--Wolfgang

Re: backporting can & can-j1939

[Kurt Van Dijck]

On Wed, Dec 14, 2011 at 01:29:08PM +0000, Wolfgang wrote:
> Your proposal worked perfect, I can still hardly believe it.

Ok, that relieves a bit the pressure.
> 
> on the target:
> 
> $ dmesg | fgrep -i can
> 
> mpc52xx_can 80001300.mscan: MSCAN at 0xd1080300, irq 16, clock 100000000 Hz
> mpc52xx_can 80001380.mscan: MSCAN at 0xd1084380, irq 17, clock 100000000 Hz
> can: controller area network core (rev 20090105 abi 8)
> can: raw protocol (rev 20090105)
> can: broadcast manager protocol (rev 20090105 t)
> can: netlink gateway (rev 20101209)
> can: SAE J1939
> 
> 
> but when I type (according  to the j1939.txt)
> 
> $ ip link set can0 j1939 on

Hold here: Your 2.6.31 is too old for this feature.
You must do : $ echo can0 > /proc/net/can-j1939/net
as a legacy measure.

You will be able to use $ip for adding/removing addressing info.

> 
> it says:
> 
> Error: either "dev" is duplicate, or "j1939" is a garbage.

This makes me think you have the original 'stock' iproute2, and not
the iproute2-j1939 one (but I'm not sure yet today).

I'll come back on this tomorrow...
Kurt

> 
> Thank you very much so far!!

Thank you for the patience with operating as a 'test user'!

Kurt

Re: backporting can & can-j1939

[Wolfgang]

> Hold here: Your 2.6.31 is too old for this feature.
> You must do : $ echo can0 > /proc/net/can-j1939/net
> as a legacy measure.
> 
> You will be able to use $ip for adding/removing addressing info.

Ok, I will try that.

> > Error: either "dev" is duplicate, or "j1939" is a garbage.
> 
> This makes me think you have the original 'stock' iproute2, and not
> the iproute2-j1939 one (but I'm not sure yet today).

Yes, you are right I was using the 'stock' iproute2, should I replace the stock 
with the j1939 iproute2, before compiling the kernel? I think I understood that 
wrong. 
Do I have to replace the can-utils as well; I am still not complete aware how
the respitories differ from each other


--Wolfgang

Using can & can-j1939

[Kurt Van Dijck]

On Wed, Dec 14, 2011 at 06:19:45PM +0000, Wolfgang wrote:
> > > Error: either "dev" is duplicate, or "j1939" is a garbage.
> > 
> > This makes me think you have the original 'stock' iproute2, and not
> > the iproute2-j1939 one (but I'm not sure yet today).
> 
> Yes, you are right I was using the 'stock' iproute2
That explains things :-)

> should I replace the stock 
> with the j1939 iproute2, before compiling the kernel?
No, not before 'compiling' the kernel.
But before 'using' the j1939 options from the newly compiled kernel.
> I think I understood that wrong. 
Not really..., see below

> Do I have to replace the can-utils as well;
Yes,
> I am still not complete aware how
> the respitories differ from each other
I did never really explain this, therefore:
I added j1939 into the kernel => recompile kernel.
I added j1939 configuration to iproute2 => replace iproute2 for using j1939
I added some specific j1939 support & monitoring tools (jacd, ...) => 
	replace can-utils for using j1939

Summarize: the real core of j1939 is in kernel space.
To get it up & running, you need some (smaller) userspace modifications.

I hope this demistifies a tiny bit

Kind regards,
Kurt

Re: Using can & can-j1939

[Wolfgang]

> I hope this demistifies a tiny bit

OK, I think things got a bit clearer for me.

1. You have to get the j1939 'into' the kernel space (check).
2. You have to cross compile the utils (check) and iproute2(remaining) and copy 
   it in the running target user space.

Hope I got that right!?


Now let's handle the problem with compilation of the iproute2, 
I did,
$make CC=powerpc-603e-linux-gnu-gcc error:

powerpc-603e-linux-gnu-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall 
-I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -I/usr//usr/include  -o 
arpd arpd.c ../lib/libnetlink.a ../lib/libutil.a -ldb -lpthread
/opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/gcc-4.3.2-glibc-2.8-binutils-
2.18-kernel-2.6.27-sanitized/lib/gcc/powerpc-603e-linux-gnu/4.3.2/../../../..
/powerpc-603e-linux-gnu/bin/ld: cannot find -ldb
collect2: ld returned 1 exit status
make[1]: *** [arpd] Error 1
make[1]: Leaving directory `/home/wolfgang/iproute2-j1939/misc'
make: *** [all] Error 2

Could that be a problem, because of an previous error a copied the db_185 header 
from the host to the toolchain usr/include directory?

--Wolfgang

Cross-compiling iproute2-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 08:35:30AM +0000, Wolfgang wrote:
> > I hope this demistifies a tiny bit
> 
> OK, I think things got a bit clearer for me.
> 
> 1. You have to get the j1939 'into' the kernel space (check).
> 2. You have to cross compile the utils (check) and iproute2(remaining) and copy 
>    it in the running target user space.
> 
> Hope I got that right!?
Yes, that's it.
You summarized it well, I'll reuse this for documentation eventually.
> 
> 
> Now let's handle the problem with compilation of the iproute2, 
> I did,
> $make CC=powerpc-603e-linux-gnu-gcc error:
> 
> powerpc-603e-linux-gnu-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall 
> -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -I/usr//usr/include  -o 
> arpd arpd.c ../lib/libnetlink.a ../lib/libutil.a -ldb -lpthread
> /opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/gcc-4.3.2-glibc-2.8-binutils-
> 2.18-kernel-2.6.27-sanitized/lib/gcc/powerpc-603e-linux-gnu/4.3.2/../../../..
> /powerpc-603e-linux-gnu/bin/ld: cannot find -ldb
> collect2: ld returned 1 exit status
> make[1]: *** [arpd] Error 1
> make[1]: Leaving directory `/home/wolfgang/iproute2-j1939/misc'
> make: *** [all] Error 2
> 
> Could that be a problem, because of an previous error a copied the db_185 header 
> from the host to the toolchain usr/include directory?
I think you got really far now, and reached 'arpd' (on my system, 'ip' is compiled then).
'arpd' needs 'libdb'. I don't think copying the db_185 header is a problem, but the
libdb.so or libdb.a remains absent.

I think Pengutronix supports compiling iproute2 _with_ some patches. I think you
better apply those too.
As an alternative, you could get rid of arpd (I'm not using it on our target) with following
patch or similar:

Kurt

Index: iproute2-2.6.35/misc/Makefile
===================================================================
--- iproute2-2.6.35.orig/misc/Makefile	2010-08-25 16:27:27.000000000 +0200
+++ iproute2-2.6.35/misc/Makefile	2010-08-25 16:29:58.000000000 +0200
@@ -1,10 +1,10 @@
 SSOBJ=ss.o ssfilter.o
 LNSTATOBJ=lnstat.o lnstat_util.o
 
-TARGETS=ss nstat ifstat rtacct arpd lnstat
-
 include ../Config
 
+TARGETS=ss nstat ifstat rtacct lnstat $(MISC_EXTRA)
+
 all: $(TARGETS)
 
 ss: $(SSOBJ) $(LIBUTIL)

Re: Cross-compiling iproute2-j1939

[Wolfgang]

> I think Pengutronix supports compiling iproute2 _with_ some patches. 
>think you better apply those too. 
When you can use it I could send you the bash compiling iproute2 with pengutronix

I don't know which or what they patched, so I applied your proposal (I had to
change it in the iproute2-j1939, not in the BSP?) - and it worked.

When I have it to change it in the BSP, I am wondering how it get reference, 
because I do $make KERNEL_INCLUDE=<KERNEL_HEADER_PATH> CC=...

but the kernel header path is .../built-target/linux-2.6.31 and the
iproute2 path is ../built-target/iproute2-2.6.29-1 so they aren't 
in touch, as I understand that.

But I hope I did it right!! So can I now copy and/or replace the 
things which I created from compiling iproute2-j1939 and can-utils-j1939 
to the target or all of it?

(iproute2 created 6 directories etc, lib, sbin, share, usr, var)

--Wolfgang

replacing iproute2 & can-utils with j1939 variants

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 11:24:13AM +0000, Wolfgang wrote:
> 
> but the kernel header path is .../built-target/linux-2.6.31 and the
> iproute2 path is ../built-target/iproute2-2.6.29-1 so they aren't 
> in touch, as I understand that.
Kernel does not alter the ABI in an incompatible way. So iprout2-2.6.29
will work with linux-2.6.29 and higher.

The other way (like iproute2-2.6.35 on linux-2.6.31) works as long
as iproute2 does not use features introduced since 2.6.31 :-)

> 
> But I hope I did it right!! So can I now copy and/or replace the 
> things which I created from compiling iproute2-j1939 and can-utils-j1939 
> to the target or all of it?
You can.
To be more precise, you :
* _must_ replace the original 'ip' with the one from iproute2-j1939
* _must_ add 'jacd', 'jspy' and 'jsr' from can-j1939-utils

You _may_ replace other binaries, but that is not necessary.

Kurt

Re: replacing iproute2 & can-utils with j1939 variants

[Wolfgang]

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

because if I do '$ifconfig can0 up' it responses with 

mpc52xx_can 80001300.mscan: bit-timing not yet defined
ifconfig: SIOCSIFFLAGS: Invalid argument


(Just for information this time different answer:
$ ip link set can0 j1939 on
RTNETLINK answers: Invalid argument )

Is there any documentation or is it possible to use cangw with API?

--Wolfgang

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

API calls

[Wolfgang]

Hi Kurt,

I am sorry, but I am not too much in socket programming yet, and I can't find 
much information about socketCAN. I am using the j1939.txt.

I am trying to create a socket and send something, the addr 0x80 I have defined
before. What have I done wrong or how is it made right?

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



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

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = ifindex("can0");
    addr.can_addr.j1939.name = TEST;
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = 0x12300;

    bind(s, (void *)&addr, sizeof(addr));
    
    sendto(s, data, sizeof(data), 0, (void *)&addr, sizeof(addr));
    
}


Kind regards,
Wolfgang

Re: API calls

[Kurt Van Dijck]

On Tue, Dec 20, 2011 at 10:35:05AM +0000, Wolfgang wrote:
> Hi Kurt,
> 
> I am sorry, but I am not too much in socket programming yet, and I can't find 
> much information about socketCAN. I am using the j1939.txt.
man socket
man bind
man sendto
man recv
....

Socket programming (not CAN specific) wasn't very easy for me neither the first time.

Since you seem to have gottten pretty far with a first test program,
I've corrected some mistakes/bad practices.

> 
> I am trying to create a socket and send something, the addr 0x80 I have defined
> before. What have I done wrong or how is it made right?
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
#include <linux/can.h>
> #include <linux/can/j1939.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
/* for if_nametoindex() */
#include <net/if.h>
> 
> 
> 
> int main ()
> {
>     int s;
>     s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
>     struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = ifindex("can0");
     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = TEST;
@name is used for dynamic addressing.
If you're using static addressing, assign J1939_NO_NAME (== 0, so leaving is fine too).
      addr.can_addr.j1939.name = J1939_NO_NAME;

>     addr.can_addr.j1939.addr = 0x80;
>     addr.can_addr.j1939.pgn = 0x12300;
> 
>     bind(s, (void *)&addr, sizeof(addr));
better is:
	int ret;

	if (bind(...) < 0)
		perror("bind failed");
	
	if (send(s, data, sizeof(data), 0) < 0)
		perror("send failed");

If sizeof(data) <= 8, then this
will broadcast a message with _can_id_ 0x1923ff80:
* (/*priority*/6 << 26) | (/*pgn*/0x12300 << 8) | (/*source*/0x80).
* PGN 0x123 is of type PDU1 => destination address in PDU-specific
* no destination given => broadcast (0xff).

>     
>     sendto(s, data, sizeof(data), 0, (void *)&addr, sizeof(addr));
likewise, this would send the message to ..., yourself again.
can_id will be 0x19238080

I hope this clears up a bit.
J1939 isn't very transparent on the composition of it's CAN identifiers.
The can-j1939 stack deals with all issues, safeguarding you from protocol violations
on the bus, but the stack may return error codes when you try something illegal.
You should check them (i.e. doing "if (send(...) < 0) perror(...);")

Kind regards,
Kurt

Re: API calls

[Wolfgang]

> man socket
> man bind
> man sendto
> man recv

I've forgotten those, thanks.

 
#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>



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 = 0x12300;
              
       
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    {
    perror ("bind failed");
    }

    
    if (send(s, data, sizeof(data), 0) < 0)
    {
    perror ("send failed");
    }
    
return 0;
}

I changed the program, but I am wondering how to send an entire j1939 frame with
the data?

--Wolfgang

Re: API calls

[Kurt Van Dijck]

On Tue, Dec 20, 2011 at 02:49:43PM +0000, Wolfgang wrote:
> 
> I changed the program, but I am wondering how to send an entire j1939 frame with
> the data?

send(s, data, sizeof(data), 0) does send. But I see 'data' not defined?

I'm afraid I don't really understand the question this time ...
Can you explain a bit more?

Kurt

Re: API calls

[Wolfgang]

I was a bit hasty. It is not working, but I don't get it. Eclipse is saying 
bind failed: Invalid argument
send failed: Destination address required

How is a frame send with id and data, like when you do $cansend can0 
-ei0x123ff80 0xFF. Because only data is sent now?


#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>



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 = 0x12300;
      
   
   struct can_frame frame;
   frame.data[1] = 0xFF;   
   
       
      
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    {
    perror ("bind failed");
    }
    
    
   if (send(s, frame.data, sizeof(frame.data), 0) < 0)
   {
   perror ("send failed");
   }
    
return 0;
}

Re: API calls

[Kurt Van Dijck]

On Tue, Dec 20, 2011 at 03:43:13PM +0000, Wolfgang wrote:
> I was a bit hasty. It is not working, but I don't get it. Eclipse is saying 
> bind failed: Invalid argument
I went into the code. I forgot to add:
     addr.can_family = AF_CAN;
I think this is what is missing.

> send failed: Destination address required
Yep, since bind failed, you will not be able to use the socket already (man socket).

I just pushed a commit into linux-can-j1939. You may decide to merge it into
your kernel. I found that the test for 'bind succeeded' is wrong in sendmsg.
Therefore, you get some error because you really did not bind yet, but
after the patch, you will get the error ENOTCONN, which is very appropriate.
> 
> How is a frame send with id and data, like when you do $cansend can0 
> -ei0x123ff80 0xFF. Because only data is sent now?

The ID is composed from the address information you supplied earlier
with bind(), connect() and/or sendto().
This is different with CAN raw, but remind that CAN raw does not imply addressing
on the bus neither. 

can-j1939 does export an address concept to userspace, and verifies that
you're not cheating on the bus. And the modules thus allow to
do transport protocol with addressing verified.

So, to summarize, you may later on start using sendto(), and supply
an address structure with destination address and/or PGN set.

Kurt

Re: API calls

[Wolfgang]

#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>


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 = 0xFFD0;
    addr.can_family = AF_CAN;  
   
	struct can_frame frame;
	   
      
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    {
    perror ("bind failed");
    }
      		
	  if (send(s, frame.data, sizeof(frame.data), 0)<0)
   		{
  		 perror ("send failed");
  		 }
   
return 0;
}

It is working, the ID is composed 18FFD080, thanks. I also tried recv() - it is 
working as well. 
Is it possible to implement only the bytes you really need from the data array,
because the dlc is always 8.
So sendto() is used to send to a specific address, at the moment I am always
doing broadcast?

--Wolfgang

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