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: <467EA11A.7040109@hartkopp.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ