RE: J1939 message length

[<pfifre.ext@orange.com>]

Thanks a lot Kurt

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 19 mai 2015 23:02
À : laurent vaudoit
Cc : zze-Open the box FIFRE P ext IMT/OLPS; linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hey,

--- Original message ---
> Date: Tue, 19 May 2015 15:40:38 +0200
> From: laurent vaudoit <laurent.vaudoit@gmail.com>
> To: pfifre.ext@orange.com
> Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>,
> 	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: Re: J1939 message length
> 
> Hi Pascal,
> 
> i think you're mentionning the bug i have seen a few time ago.
> the pgn request is allways sent with 8 bytes instead of only 3 bytes.

I think that now too.

> i think the padding should be done in the transport layer instead of 
> in the main.c file.
> you can have a look at the beginning of this mail thread.

You could change the patch mentioned earlier as:

diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c index 7edf843..1479de4 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -156,7 +156,9 @@ static int j1939_send_can(struct sk_buff *skb)
 		canid |= ((sk_addr->pgn & 0x3ffff) << 8);
 
 	msg->can_id = canid;
+	if ((dlc < 8) && sk_addr->pgn != 0x0ea00)) {
+		memset(msg->data+dlc, 0xff, 8 - dlc);
+		dlc = 8;
+	}
 	msg->can_dlc = dlc;
  
 	/* set net_device */
 	ret = -ENODEV;
	

--
This should fix the request PGN bug.

Due to the interest, I just worked out a different patch that _only_ pads transport protocol data frames.
This only solves problems when the receiver is intolerant for transport protocol frames, and not for regular frames.

Note that it makes not real sense to apply both patches.

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index 2b50902..187aaad 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -369,8 +369,9 @@ static int j1939tp_tx_dat(struct session *related,
 	/* fix pgn */
 	skb_cb->pgn = related->extd ? etp_pgn_dat : tp_pgn_dat;
 
-	skdat = skb_put(skb, len);
+	skdat = skb_put(skb, 8);
 	memcpy(skdat, dat, len);
+	memset(skdat+len, 0xff, 8-len);
 	ret = j1939_send_normalized_pkt(skb);
 	if (ret < 0)
 		kfree_skb(skb);


Kind regards,
Kurt

> 
> Regards
> 
> Laurent
> 
> On Tue, May 19, 2015 at 3:27 PM, <pfifre.ext@orange.com> wrote:
> 
> > Thanks for your answer Kurt.
> >
> > Yes, I refer to "Request for address claimed" PGN, wich is normally 
> > 3 bytes.
> > When I send it with a length of 3, like jacd do, the request is sent 
> > with
> > 8 bytes (the others are padded with 0xFF).
> > When I try with jacd, it sends the same frame.
> >
> > I think it's a bug, I'm right?
> > I think, that the driver doesn't analyse the PGN and pad the frame 
> > systemically.
> >
> > I can't use the send function to send the frame, because I need to 
> > specify the PGN in the address.
> >
> > Then one of devices on the bus doesn't answer to the request.
> >
> > Regards,
> >
> > Pascal
> >
> > -----Message d'origine-----
> > De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> > Envoyé : mardi 19 mai 2015 10:46
> > À : zze-Open the box FIFRE P ext IMT/OLPS Cc : 
> > linux-can@vger.kernel.org Objet : Re: J1939 message length
> >
> > Hi Pascal,
> >
> > I apologise for the late answer.
> > Your email has slipped in without drawing my attention.
> >
> > Please find my answer below.
> >
> > --- Original message ---
> > > Date: Mon, 27 Apr 2015 09:22:17 +0000
> > > From: pfifre.ext@orange.com
> > > To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> > > CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> > > Subject: RE: J1939 message length
> > >
> > > Hi Kurt,
> > >
> > > I have an issue on address claim.
> > >
> > > When I call the bind the claim address is send with a DLC of 8 and 
> > > 8
> > bytes sent on the CAN.
> > > But, according to the ISO11783, I need to send and address CLAIM 
> > > by a 3
> > bytes frame.
> >
> > The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
> > I think you refer to the "Request for address claimed" PGN, which is 
> > 3 bytes, with PGN 0x0ea00, and payload 00ee00.
> >
> > >
> > > How can, I do that with existing kernel J1939 stack or where I can
> > modify this?
> > You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)
> >
> > If you want to do the address claiming, then you may take a look at 
> > jacd, a j1939 adddress claim daemon.
> > It does all the userspace handling necessary for address claiming.
> > You can find it at https://github.com/kurt-vd/can-utils.git, in 
> > j1939-v6 branch.
> >
> > Kind regards,
> > Kurt
> >
> >
> > ____________________________________________________________________
> > _____________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre 
> > diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> > ce message par erreur, veuillez le signaler a l'expediteur et le 
> > detruire ainsi que les pieces jointes. Les messages electroniques 
> > etant susceptibles d'alteration, Orange decline toute responsabilite 
> > si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they should not 
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender 
> > and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that 
> > have been modified, changed or falsified.
> > Thank you.
> >
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.