lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 26 Nov 2022 11:28:40 +0100
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     Devid Antonio Filoni <devid.filoni@...uetechnologies.com>
Cc:     Robin van der Gracht <robin@...tonic.nl>,
        Oleksij Rempel <linux@...pel-privat.de>, kernel@...gutronix.de,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, linux-can@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] can: j1939: do not wait 250 ms if the same addr was
 already claimed

On Fri, Nov 25, 2022 at 06:04:18PM +0100, Devid Antonio Filoni wrote:
> The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states:
>   d) No CF shall begin, or resume, transmission on the network until 250
>      ms after it has successfully claimed an address except when
>      responding to a request for address-claimed.
> 
> But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
> prioritization" show that the CF begins the transmission after 250 ms
> from the first AC (address-claimed) message even if it sends another AC
> message during that time window to resolve the address contention with
> another CF.
> 
> As stated in "4.4.2.3 - Address-claimed message":
>   In order to successfully claim an address, the CF sending an address
>   claimed message shall not receive a contending claim from another CF
>   for at least 250 ms.
> 
> As stated in "4.4.3.2 - NAME management (NM) message":
>   1) A commanding CF can
>      d) request that a CF with a specified NAME transmit the address-
>         claimed message with its current NAME.
>   2) A target CF shall
>      d) send an address-claimed message in response to a request for a
>         matching NAME
> 
> Taking the above arguments into account, the 250 ms wait is requested
> only during network initialization.
> 
> Do not restart the timer on AC message if both the NAME and the address
> match and so if the address has already been claimed (timer has expired)
> or the AC message has been sent to resolve the contention with another
> CF (timer is still running).
> 
> Signed-off-by: Devid Antonio Filoni <devid.filoni@...uetechnologies.com>

Acked-by: Oleksij Rempel <o.rempel@...gutronix.de>

> ---
>  v1 -> v2: Added ISO 11783-5 standard references
> 
>  net/can/j1939/address-claim.c | 40 +++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/net/can/j1939/address-claim.c b/net/can/j1939/address-claim.c
> index f33c47327927..ca4ad6cdd5cb 100644
> --- a/net/can/j1939/address-claim.c
> +++ b/net/can/j1939/address-claim.c
> @@ -165,6 +165,46 @@ static void j1939_ac_process(struct j1939_priv *priv, struct sk_buff *skb)
>  	 * leaving this function.
>  	 */
>  	ecu = j1939_ecu_get_by_name_locked(priv, name);
> +
> +	if (ecu && ecu->addr == skcb->addr.sa) {
> +		/* The ISO 11783-5 standard, in "4.5.2 - Address claim
> +		 * requirements", states:
> +		 *   d) No CF shall begin, or resume, transmission on the
> +		 *      network until 250 ms after it has successfully claimed
> +		 *      an address except when responding to a request for
> +		 *      address-claimed.
> +		 *
> +		 * But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim
> +		 * prioritization" show that the CF begins the transmission
> +		 * after 250 ms from the first AC (address-claimed) message
> +		 * even if it sends another AC message during that time window
> +		 * to resolve the address contention with another CF.
> +		 *
> +		 * As stated in "4.4.2.3 - Address-claimed message":
> +		 *   In order to successfully claim an address, the CF sending
> +		 *   an address claimed message shall not receive a contending
> +		 *   claim from another CF for at least 250 ms.
> +		 *
> +		 * As stated in "4.4.3.2 - NAME management (NM) message":
> +		 *   1) A commanding CF can
> +		 *      d) request that a CF with a specified NAME transmit
> +		 *         the address-claimed message with its current NAME.
> +		 *   2) A target CF shall
> +		 *      d) send an address-claimed message in response to a
> +		 *         request for a matching NAME
> +		 *
> +		 * Taking the above arguments into account, the 250 ms wait is
> +		 * requested only during network initialization.
> +		 *
> +		 * Do not restart the timer on AC message if both the NAME and
> +		 * the address match and so if the address has already been
> +		 * claimed (timer has expired) or the AC message has been sent
> +		 * to resolve the contention with another CF (timer is still
> +		 * running).
> +		 */
> +		goto out_ecu_put;
> +	}
> +
>  	if (!ecu && j1939_address_is_unicast(skcb->addr.sa))
>  		ecu = j1939_ecu_create_locked(priv, name);
>  
> -- 
> 2.34.1
> 
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ