From: Filippo Storniolo <fstornio@redhat.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
Robin van der Gracht <robin@protonic.nl>,
Oleksij Rempel <o.rempel@pengutronix.de>,
kernel@pengutronix.de,
Urs Thuermann <urs.thuermann@volkswagen.de>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
linux-can@vger.kernel.org, Davide Caratti <dcaratti@redhat.com>
Subject: Re: [PATCH can-next v3 0/3] Introduce diag support for CAN
Date: Wed, 21 Oct 2026 10:26:00 +0200 [thread overview]
Message-ID: <atfFeR_OEaWrcQSS@storniolo-redhat> (raw)
In-Reply-To: <d23196e0-6307-458b-ba31-15f54ef46b73@hartkopp.net>
On Tue, Oct 20, 2026 at 06:20:22PM +0200, Oliver Hartkopp wrote:
>
>
>On 20.10.26 17:50, Marc Kleine-Budde wrote:
>>On 04.09.2026 16:12:54, Filippo Storniolo wrote:
>>>An example of the output given by ss -cpe:
>>>
>>>Netid Recv-Q Send-Q Local Address:Port Peer Address:Port Process
>>>CAN_ISOTP 0 0 vcan1:1110 vcan1:291 uid:1001 ino:50324 sk:0 users:(("can2",pid=9210,fd=4))
>>>CAN_ISOTP 0 0 vcan1:291 vcan1:1110 uid:1001 ino:50323 sk:0 users:(("can2",pid=9210,fd=3))
>
Hi Oliver
>The fact that the inode number of the socket is visible fits great to
>the upcoming CAN procfs output:
>
>https://lore.kernel.org/linux-can/20261018164417.1540449-8-mkl@pengutronix.de/
>
>But I'm not sure about "Local Address:Port" being "vcan1:1110".
>
You are right and probably the example in the cover letter does not
fit the best use for the netlink message.
This is just how ss show numbers. I used this tool as proof of
concept during development and I didn't put too much effort on it.
>A CAN-ID together with a CAN interface is a unique "content address"
>to identify the content which is in the CAN frames data.
>
>I assume "1110" to be the decimal representation of an 11 bit SFF CAN
>ID 0x456, right?
Yes, it comes from 0x456. During development, I was using some C
program to just create CAN sockets. The socket configuration for the
shown example was the following:
`
addr_send.can_family = addr_recv.can_family = AF_CAN;
addr_send.can_ifindex = addr_recv.can_ifindex = if_nametoindex("vcan1");
addr_send.can_addr.tp.tx_id = addr_recv.can_addr.tp.rx_id = 0x123;
addr_send.can_addr.tp.rx_id = addr_recv.can_addr.tp.tx_id = 0x456;
`
>
>Having a CAN ID in decimal representation is generally unusual -
>especially in Linux. Additionally you can have 29 bit EFF CAN IDs
>which does not fit into a 16 bit port value.
>
>And 29 bit IDs have to be marked as you can have the value 0x456 in 11
>bit and 29 bit CAN IDs. We usually do this with 456 and 00000456 to
>indicate 11/29 bit IDs.
>
>So the "Local Address:Port" output does not really fit to CAN here ...
>
I can update the ss example in the cover letter with something
that better fits a real case scenario if you want.
>Best regards,
>Oliver
Best regards,
Filippo
>
>
next prev parent reply other threads:[~2026-10-21 8:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 14:12 [PATCH can-next v3 0/3] Introduce diag support for CAN Filippo Storniolo
2026-09-04 14:12 ` [PATCH can-next v3 1/3] af_can: ensure sk_protocol is always set on socket creation Filippo Storniolo
2026-10-20 15:26 ` Marc Kleine-Budde
2026-09-04 14:12 ` [PATCH can-next v3 2/3] af_can: store socket pointers in struct netns_can Filippo Storniolo
2026-09-04 14:12 ` [PATCH can-next v3 3/3] can: add can diag interface Filippo Storniolo
2026-09-04 14:26 ` sashiko-bot
2026-10-16 16:00 ` Filippo Storniolo
2026-10-17 10:10 ` Marc Kleine-Budde
2026-10-19 20:45 ` Jakub Kicinski
2026-10-20 12:27 ` Marc Kleine-Budde
2026-10-20 16:33 ` Filippo Storniolo
2026-10-21 9:11 ` Marc Kleine-Budde
2026-10-20 15:50 ` [PATCH can-next v3 0/3] Introduce diag support for CAN Marc Kleine-Budde
2026-10-20 16:20 ` Oliver Hartkopp
2026-10-21 7:37 ` Marc Kleine-Budde
2026-10-21 8:26 ` Filippo Storniolo [this message]
2026-10-21 8:35 ` Oliver Hartkopp
2026-10-21 16:34 ` Filippo Storniolo
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=atfFeR_OEaWrcQSS@storniolo-redhat \
--to=fstornio@redhat.com \
--cc=dcaratti@redhat.com \
--cc=horms@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=robin@protonic.nl \
--cc=socketcan@hartkopp.net \
--cc=urs.thuermann@volkswagen.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.