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
| ||
|
Message-ID: <20221126102840.GA21761@pengutronix.de> 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