netdev - Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

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]

Message-ID: <ygfabvfrirr.fsf@janus.isnogud.escape.de>
Date:	04 Jun 2007 14:44:40 +0200
From:	Urs Thuermann <urs@...ogud.escape.de>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Oliver Hartkopp <socketcan@...tkopp.net>,
	David Miller <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>,
	netdev@...r.kernel.org
Subject: Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

Patrick McHardy <kaber@...sh.net> writes:

> I was thinking about this, don't CAN frames include the identity
> of the sender? That would be the easiest way to determine whether
> the frame needs to be delivered.

No, CAN is quite a broken networking technology (at least in my view,
coming from tcp/ip).  There is no station addresses and therefore no
sender or receiver addresses.  Everything is broadcast.

> Actually its not unused, it needs to be set on TX frames once the
> packet leaves the protocol specific code.

Oops, yes, this is something still missing in our code.  Needs to be
fixed.

> I don't get why you can't directly check the socket option on the
> TX path.

We have several types of sockets in the PF_CAN family, two of which
are GPL'ed and which are in the patch series.  These are CAN_RAW and
CAN_BCM.  The protocol implementations use can_send() in af_can.c to
send a CAN frame and indicate to can_send() in an int argument,
whether this frame should be looped back.  Only the raw protocol has a
socket option (setsockopt(2)) in struct raw_sock for this, bcm always
sets this to 1 to have the frame looped back.  There is no option in
struct bcm_sock for this.  In can_send() and in the driver we don't
know what type of socket skb->sk points to and can't check that
option.  Changing this would mean we have to add such an option in the
same position in all CAN socket types and set it to fixed values in
some of them (e.g. to 1 for bcm).  While it's doable, I wouldn't like
that very much.

Is there anything that prevents can_send() from using skb->pkt_type to
pass the loopback flag down to the driver?

urs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html