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

[Joerg Roedel <joro-lkml@zlug.org>]

On Fri, Sep 15, 2006 at 09:06:02AM +1000, Philip Craig wrote:
> 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?

The problem is that the ethip0 device also uses ARPHDR_ETHER. The usage
of that device is also unsafe. As I see the situation there are 2
solutions for this problem. First use some other Type identifier for
ethip0. But this is only a quick hack. I think about a new device type
ARPHRD_ETHERIP. This makes the tunnel devices incompatible with the
bridging code. But I think it is possible to convince the bridge code to
accept the special tunnel devices too.
Unfortunately I didn't saw the problem when implementing the driver...

Regards,
    Joerg Roedel