netdev - Re: Ethernet-over-UDP virtual network interface

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: <CAKLmikOVydmSJEBWwDc=Jv4XPMi3dsS+Pn9=BP_bBePD0L7K8A@mail.gmail.com>
Date:	Tue, 6 Mar 2012 00:58:44 +0100
From:	Mitar <mmitar@...il.com>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	netdev@...r.kernel.org, Nejc Skoberne <nejc@...berne.net>,
	Jernej Kos <kostko@...matrix-one.org>, gw.2012@...de.com
Subject: Re: Ethernet-over-UDP virtual network interface

Hi!

On Sun, Mar 4, 2012 at 6:01 PM, Benjamin LaHaise <bcrl@...ck.org> wrote:
> Why not use L2TP?  It can operate over UDP (v2 or v3) or directly over IP
> if needed (v3).  L2TPv3 also supports ethernet pseudo-wires.

I would like something state-less. I see L2TPv3 has support for
unmanaged tunnels, but they still require tunnel id and session id
what (if I assume that they have to be unique) makes it useless for
our case. We have (if I simplify) a star-shaped topology with a
central server in the middle. To the central server WiFi nodes
(hundreds of them) connect. But we do not really want to require from
a central server to know each WiFi node and prepare its tunnel
endpoint for each node. We would just like that there would be virtual
interface and UDP port and any packet send to the UDP port would be
decapsulated and output through that virtual interface. The only thing
which we would have to make sure is that each WiFi node has a virtual
interface with unique MAC address.

Mitar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html