netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Zhang Changzhong <zhangchangzhong@huawei.com>
Cc: Maxime Jayat <maxime.jayat@mobile-devices.fr>,
	Robin van der Gracht <robin@protonic.nl>,
	linux-kernel@vger.kernel.org,
	Oleksij Rempel <linux@rempel-privat.de>,
	netdev@vger.kernel.org, Marc Kleine-Budde <mkl@pengutronix.de>,
	kernel@pengutronix.de, Oliver Hartkopp <socketcan@hartkopp.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-can@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net] can: j1939: j1939_xtp_rx_dat_one(): cancel session if receive TP.DT with error length
Date: Mon, 11 Oct 2021 08:35:07 +0200	[thread overview]
Message-ID: <20211011063507.GI29653@pengutronix.de> (raw)
In-Reply-To: <556a04ed-c350-7b2b-5bbe-98c03846630b@huawei.com>

On Sat, Oct 09, 2021 at 04:43:56PM +0800, Zhang Changzhong wrote:
> On 2021/10/8 19:00, Oleksij Rempel wrote:
> > On Fri, Oct 08, 2021 at 05:22:12PM +0800, Zhang Changzhong wrote:
> >> Hi Kurt,
> >> Sorry for the late reply.
> >>
> >> On 2021/9/30 15:42, Kurt Van Dijck wrote:
> >>> On Thu, 30 Sep 2021 11:33:20 +0800, Zhang Changzhong wrote:
> >>>> According to SAE-J1939-21, the data length of TP.DT must be 8 bytes, so
> >>>> cancel session when receive unexpected TP.DT message.
> >>>
> >>> SAE-j1939-21 indeed says that all TP.DT must be 8 bytes.
> >>> However, the last TP.DT may contain up to 6 stuff bytes, which have no meaning.
> >>> If I remember well, they are even not 'reserved'.
> >>
> >> Agree, these bytes are meaningless for last TP.DT.
> >>
> >>>
> >>>>
> >>>> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
> >>>> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
> >>>> ---
> >>>>  net/can/j1939/transport.c | 7 +++++--
> >>>>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
> >>>> index bb5c4b8..eedaeaf 100644
> >>>> --- a/net/can/j1939/transport.c
> >>>> +++ b/net/can/j1939/transport.c
> >>>> @@ -1789,6 +1789,7 @@ static void j1939_xtp_rx_dpo(struct j1939_priv *priv, struct sk_buff *skb,
> >>>>  static void j1939_xtp_rx_dat_one(struct j1939_session *session,
> >>>>  				 struct sk_buff *skb)
> >>>>  {
> >>>> +	enum j1939_xtp_abort abort = J1939_XTP_ABORT_FAULT;
> >>>>  	struct j1939_priv *priv = session->priv;
> >>>>  	struct j1939_sk_buff_cb *skcb, *se_skcb;
> >>>>  	struct sk_buff *se_skb = NULL;
> >>>> @@ -1803,9 +1804,11 @@ static void j1939_xtp_rx_dat_one(struct j1939_session *session,
> >>>>  
> >>>>  	skcb = j1939_skb_to_cb(skb);
> >>>>  	dat = skb->data;
> >>>> -	if (skb->len <= 1)
> >>>> +	if (skb->len != 8) {
> >>>>  		/* makes no sense */
> >>>> +		abort = J1939_XTP_ABORT_UNEXPECTED_DATA;
> >>>>  		goto out_session_cancel;
> >>>
> >>> I think this is a situation of
> >>> "be strict on what you send, be tolerant on what you receive".
> >>>
> >>> Did you find a technical reason to abort a session because the last frame didn't
> >>> bring overhead that you don't use?
> >>
> >> No technical reason. The only reason is that SAE-J1939-82 requires responder
> >> to abort session if any TP.DT less than 8 bytes (section A.3.4, Row 7).
> > 
> > Do you mean: "BAM Transport: Ensure DUT discards BAM transport when
> > TP.DT data packets are not correct size" ... "Verify DUT discards the
> > BAM transport if any TP.DT data packet has less than 8 bytes"?
> 
> Yes.

OK, then I have some problems to understand this part:
- 5.10.2.4 Connection Closure
  The “connection abort” message is not allowed to be used by responders in the
  case of a global destination (i.e. BAM).

My assumption would be: In case of broadcast transfer, multiple MCU are
receivers. If one of MCU was not able to get complete TP.DT, it should
not abort BAM for all.

So, "DUT discards the BAM transport" sounds for me as local action.
Complete TP would be dropped locally.

Regards
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2021-10-11  6:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  3:33 [PATCH net] can: j1939: j1939_xtp_rx_dat_one(): cancel session if receive TP.DT with error length Zhang Changzhong
2021-09-30  7:42 ` Kurt Van Dijck
2021-10-08  9:22   ` Zhang Changzhong
2021-10-08 11:00     ` Oleksij Rempel
2021-10-08 17:09       ` Kurt Van Dijck
2021-10-09  9:12         ` Zhang Changzhong
2021-10-09  8:43       ` Zhang Changzhong
2021-10-11  6:35         ` Oleksij Rempel [this message]
2021-10-11  7:18           ` Kurt Van Dijck
2021-10-11 10:40           ` Zhang Changzhong
2021-10-12 10:21             ` Oleksij Rempel
2021-10-12 10:41               ` Kurt Van Dijck
2021-10-12 11:09 ` Oleksij Rempel
2021-10-17 10:32 ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211011063507.GI29653@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=davem@davemloft.net \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rempel-privat.de \
    --cc=maxime.jayat@mobile-devices.fr \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=robin@protonic.nl \
    --cc=socketcan@hartkopp.net \
    --cc=zhangchangzhong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).