netdev - [CAN] [RFC] skb->iif usage and vcan driver background

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 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:	Sun, 24 Jun 2007 18:51:38 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Patrick McHardy <kaber@...sh.net>, j.hadi123@...il.com
CC:	David Miller <davem@...emloft.net>,
	Urs Thuermann <urs@...ogud.escape.de>,
	Thomas Gleixner <tglx@...utronix.de>, netdev@...r.kernel.org
Subject: [CAN] [RFC] skb->iif usage and vcan driver background

Hello Patrick and Jamal,

as i felt a bit misunderstood in the discussion about the usage of
skb->iif and the idea behind the virtual CAN driver i created four
PDF-slides to clarify some issues. The slides may give you the
appropriate background why the incoming (receiving) interface is
relevant at user level (which is unusual e.g. for PF_INET). Additionally
i collected some points what the VCAN driver does - and especially what
it is not for. So you will see, that approaches like VLAN (regarding
IEEE 802.1Q) is nothing that can be done with the CAN bus by design. The
PDF can be found at the BerliOS OSS server:

http://download.berlios.de/socketcan/iif_and_vcan.pdf

After reading the PDF ...

@Jamal: Please give me some feedback, if the (currently implemented)
transport of the iif-information inside the skb up to socket level is ok
for you.

@Patrick: The (optional) loading of the vcan module and the
specification of the needed number of vcan devices (for the wanted
use-case) was a very easy thing up to now that did not require any
additional configuration nor additional userspace tools (except saying
'ifconfig vcan0 up'). As only the use-case required number of interfaces
are allocated at module load time, i do not see a need for an extra
netlink interface to implement an IMHO obsolete vcan add/remove
mechanism. What could the implementation of the netlink API bring for
the vcan driver use-case?

Thanks for your review!
Oliver

-
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