Discussion:
vether(4)
(too old to reply)
Roy Marples
2016-04-20 20:59:32 UTC
Permalink
Hi List!

There was some discussion recently about introducing vether(4) in a
thread about bridging here:
http://mail-index.netbsd.org/tech-net/2016/02/10/msg005588.html

Attached is a patch which ports the OpenBSD vether(4) driver to NetBSD.
It seems to function well as an endpoint to a bridge(4) interface and is
a lot simpler than tap(4).

Commentary welcome.

Would also welcome some discussion on extending vether(4) to allow it to
be paired (like a crossover cable) to another vether or to just import
pair(4) (again from OpenBSD). The argument for extending vether is that
both code bases are very similar.

I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).

Roy
Taylor R Campbell
2016-04-20 21:38:58 UTC
Permalink
Date: Wed, 20 Apr 2016 21:59:32 +0100
From: Roy Marples <***@marples.name>

Attached is a patch which ports the OpenBSD vether(4) driver to NetBSD.
It seems to function well as an endpoint to a bridge(4) interface and is
a lot simpler than tap(4).

What does vether(4) do that tap(4) doesn't?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Roy Marples
2016-04-21 08:09:27 UTC
Permalink
Post by Taylor R Campbell
Date: Wed, 20 Apr 2016 21:59:32 +0100
Attached is a patch which ports the OpenBSD vether(4) driver to NetBSD.
It seems to function well as an endpoint to a bridge(4) interface and is
a lot simpler than tap(4).
What does vether(4) do that tap(4) doesn't?
By itself, nothing which is why I added this to the original email:

Would also welcome some discussion on extending vether(4) to allow it to
be paired (like a crossover cable) to another vether or to just import
pair(4) (again from OpenBSD). The argument for extending vether is that
both code bases are very similar.

I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).

Rpy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2016-04-22 15:31:28 UTC
Permalink
Hi,
Post by Roy Marples
I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).
why don't they?

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Roy Marples
2016-04-22 15:41:08 UTC
Permalink
Hi
Post by Ignatios Souvatzis
Post by Roy Marples
I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).
why don't they?
Because the bridge doesn't multicast to member interfaces when packets
originate locally - they are just send to the member interface output.

I sent a patch to tech-net early this morning to fix this, the subject
is: bridge(4) - feedback local packets into ether_input()

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2016-04-22 15:44:36 UTC
Permalink
Post by Roy Marples
Hi
Post by Ignatios Souvatzis
Post by Roy Marples
I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).
why don't they?
Because the bridge doesn't multicast to member interfaces when packets
originate locally - they are just send to the member interface output.
I sent a patch to tech-net early this morning to fix this, the subject
is: bridge(4) - feedback local packets into ether_input()
Oh, this is probably why this DOMU can't IPv6 to its DOM0...
I think I've opened a PR about this. Preliminary thanks!

Regards,
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...