netdev - Re: [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 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: <467F9AED.1010309@trash.net>
Date:	Mon, 25 Jun 2007 12:37:33 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
CC:	j.hadi123@...il.com, David Miller <davem@...emloft.net>,
	Urs Thuermann <urs@...ogud.escape.de>,
	Thomas Gleixner <tglx@...utronix.de>, netdev@...r.kernel.org
Subject: Re: [CAN] [RFC] skb->iif usage and vcan driver background

Oliver Hartkopp wrote:
> 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


I normally wouldn't have gone reading some PDF to explain a patch,
but this one was really worth it .. a couple of pictures of cars
with four applications using can0-can3 :)


> After reading the PDF ...
> 
> @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?


You keep talkign about "the use-case". This is *your* usage case
any just because *you* need four interfaces doesn't mean everyone
else on the world does too.

Your last slide brings it to the point: "... configured at module
load time for the needed use-case:
- number of created vcan devices (current default=4)
- perform the loopback on driver level (current default=off)"

So you *do* have parameters for configuration and you're using the
wrong interface. Either drop them or use the correct interface.


-
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