linux-kernel - Re: [PATCH] EtherIP tunnel driver (RFC 3378)

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: <4509E05A.7010306@snapgear.com>
Date:	Fri, 15 Sep 2006 09:06:02 +1000
From:	Philip Craig <philipc@...pgear.com>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Joerg Roedel <joro-lkml@...g.org>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] EtherIP tunnel driver (RFC 3378)

Patrick McHardy wrote:
> Joerg Roedel wrote:
>> On Thu, Sep 14, 2006 at 11:21:22AM +1000, Philip Craig wrote:
>>
>>> Joerg Roedel wrote:
>>>
>>>> +	 To configure tunnels an extra tool is required. You can download
>>>> +	 it from http://zlug.fh-zwickau.de/~joro/projects/ under the
>>>> +	 EtherIP section. If unsure, say N.
>>> To obtain a list of tunnels, this tool calls SIOCGETTUNNEL
>>> (SIOCDEVPRIVATE + 0) for every device in /proc/net/dev. I don't think
>>> this is safe, but I don't have a solution for you.
>>
>> You are right. But this is the way the ipip driver does it. In the case
>> of ipip it is safe, because it is visible as a tunnel interface to
>> userspace. But my driver registers its devices as Ethernet (it has to,
>> otherwise the devices will not be usable in a bridge). There is no safe
>> way to distinguish between real Ethernet devices and devices registered
>> by my driver. I think about implementing an ioctl to fetch a list of
>> all EtherIP tunnel devices from the driver.
> 
> 
> Just do what ipip and gre do, use a network device with a fixed name
> for the ioctl (you already have the ethip0 device for this purpose it
> appears).

That fixed name device isn't used to get a list of tunnels. Instead,
ipip and gre read /proc/net/dev, and check for ARPHRD_TUNNEL or
ARPHRD_IPGRE. This won't work for etherip because it uses ARPHRD_ETHER,
which isn't specific to etherip tunnels. A new ioctl to get a list could
be added (this ioctl would use the fixed name device), is that acceptable?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/