On Wed, 15 Dec 2004, Daniel Carosone wrote:

> As I said elsewhere, on a number of occasions I've wished to be able
> to bridge(4) between a local ethernet and a gre tunnel, for transport
> of layer2 frames across a WAN to a remote site.

It sounds like you are talking about etherip. I would also like to see 
this functionality in NetBSD.

> So the current ethfoo/tap/tun/whatever interface semantics are
> partially relevant, but don't get me all the way there - I'd still
> need some userspace process (or perhaps ipf fastroute hackery?) to
> copy the frames from this device to the gre interface and back again.

OpenBSD's gif(4) can do etherip. One just adds the gif(4) interface as a 
bridge(4) member.

Maybe this functionality would be best accomplished from changes to our 
gif(4) device rather than extending ethfoo (or whatever it's going to be 
called).


(shamelessly copying and pasting from an old email):


From the gif(4) OpenBSD man page:
http://www.openbsd.org/cgi-bin/man.cgi?query=gif

----------------------------------------------------------------------------
  Finally, the gif interface may be used as a bridge(4) member.  Ethernet
  frames forwarded by the bridge to the gif interface are encapsulated in-
  side an IPv4 or IPv6 header (depending on how the interface is config-
  ured), with transport protocol number 97 (etherip).  IPv4 or IPv6 packets
  carrying transport protocol 97 are delivered to the gif interface whose
  "physical" addresses match the source/destination addresses of the packet
  (the source address of the packet must match the destination "physical"
  address, and vice versa).
----------------------------------------------------------------------------

Unfortunately it seems that the bridge and gif counterparts in NetBSD are
more limited in this respect.



-- 
Best Regards,
Patrick Mackey

------------------------------------------
     A hype free, multi-architectural OS
        NetBSD: http://www.netbsd.org 
------------------------------------------