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

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.

Is there a reason why you have a separate tool rather than modifying
iproute2?

I wrote an own tool for testing. At development I wanted to concentrate
on the driver and not how to modify iproute2. But when the driver
becomes stable and may be included I will add it to iproute2.

I don't know if you are aware of this older etherip patch by Lennert
Buytenhek: http://www.wantstofly.org/~buytenh/etherip/

I found this patch after I wrote my own and read the discussions
about it. The patch by Lennert Buytenhek has the same problem of
identifing tunnel devices. Futhermore, his driver handles ICMP and cares
about the payload of the Ethernet packet it transmits (it looks, if the
payload ist IPv4 or IPv6). Further it is configurable to set the DF flag
in outgoing packets. First I think the handling of layer 3 protocols is
beyond the scope of tunnel which transmits layer 2 packets. Second this
behavior may break the transport of non-IP payload in the Ethernet
packets since the Ethernet payload protocol may not know the concept of
a path MTU and needs the full Ethernet MTU of 1500. This is the reason
my driver never sets the DF flag in outgoing packets.

Regards,
Joerg Roedel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: MAC bridging and sniffing packets with specific Ethertype
    ... That is, the Ethernet adapters are bound to the Mbridge driver (which, since ... Mbridge handles the bridging of packets between the adapters. ...
    (microsoft.public.windowsce.embedded)
  • Re: making ppp interface on motfcc END
    ... the FCC device of a MPC8260 and supports 100Mbps ethernet. ... make this a M2_ifType_ppp type interface. ... The driver is a generic END ... 2189 unicast packets received ...
    (comp.os.vxworks)
  • Re: Degradation of TCP connection
    ... Gigabit ethernet. ... D card's data buffer can only hold about 64K samples worth of data ... link you posted is for an older version of VxWorks that used a BSD- ... but a bug in the ethernet driver. ...
    (comp.os.vxworks)
  • Re: [PATCH][5/5] RapidIO support: net driver over messaging
    ... It's nothing like Ethernet, the only relation is that an Ethernet network ... It gives easy access to RIO messaging from userspace ... ARP works by the driver emulating a broadcast over RIO by sending the ...
    (Linux-Kernel)
  • Re: Degradation of TCP connection
    ... Gigabit ethernet. ... D card's data buffer can only hold about 64K samples worth of data ... link you posted is for an older version of VxWorks that used a BSD- ... but a bug in the ethernet driver. ...
    (comp.os.vxworks)