<meta charset="utf-8"><div>Hi Mitar,</div><div><br></div>>Our proposal is to make on a node one virtual network device you<br>>configure (with ioctl for example) with unlimited number of other<br>>nodes (ip:port pairs) and kernel module makes a switch to all those<br>
>nodes. So it still does IPinUDP but we generalize the idea to multiple<br>>nodes on other side. And we need bridge logic to not duplicate traffic<br>>too much (only for broadcast data this would be the case then, like<br>
>OLSR traffic).<br><br><div>this is what I was thinking of. From my GSoC proposal:</div><div><br></div><div>"One or more virtual interfaces can be export to user-space so that packets </div><div>routed through them will be intercepted by IP/UDP_send() function (as for other </div>
<div>encapsulation modules, e.g.: IP/IP, IP/GRE) and encapsulated. Encapsulation</div><div> header fields are retrieved in 2 ways: (A) Fixed: each virtual iface has a fixed </div><div>IP/UDP encapsulation header; (B) Dynamic: the encapsulation header is retrieved</div>
<div> from a forwarding table implemented as a hash table..."</div><div><br></div><div>What I mean with "Dynamic virtual interface" is a iface for which I can dinamically</div><div>configure a set of different encapsulating/forwarding rules in a table.</div>
<div>In this way if we have 50 peers we are communicating with (and thus 50 different </div><div>IP/UDP tunnels), we don't need 50 virtual ifaces.</div><div><br></div><div>The configuration will be performed by NETLINK socket. From my GSoC:</div>
<div>"Advanced ad-hoc configuration (tunnel registration and parameters configuration, </div><div>forwarding table management, etc...) will be provided by a generic NETLINK socket. </div><div>Moreover, integration with standard configuration tools (e.g: ip, ifconfig) is possible."</div>
<div><br></div><div>Does this support your idea?</div><div><br></div><div>Marco</div><div><br><div class="gmail_quote">On Thu, Apr 15, 2010 at 2:14 AM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi!<br>
<div class="im"><br>
On Tue, Apr 6, 2010 at 11:28 PM, ZioPRoTo (Saverio Proto)<br>
<<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>> wrote:<br>
> So instead of sticking people to a gateway inside the mesh, just make<br>
> all the traffic to Internet be tunneled to a fast server and then from<br>
> there all the traffic exits with the same IP address.<br>
> Users see more bandwidth (especially in upload) and they exploit for<br>
> the better an eventual route flap :)<br>
<br>
</div>This is exactly what we are doing in wlan ljubljana. We have a lot of<br>
fiber connections and we make use of them a lot. Currently we are<br>
using OpenVPN to connect to central server but this have big<br>
drawbacks: our connections are mostly CPU limited and central server<br>
is what is then single point of failure.<br>
<br>
We were discussing this idea and we really started to like it. I think<br>
this is something wonderful. But as we have quite a lot of experience<br>
with practical deployment of such network combined with WiFi and OLSR<br>
I would like to propose an enhancement to original idea. It makes it a<br>
little bit more complicated but what you get is something great.<br>
<br>
Our proposal is to make on a node one virtual network device you<br>
configure (with ioctl for example) with unlimited number of other<br>
nodes (ip:port pairs) and kernel module makes a switch to all those<br>
nodes. So it still does IPinUDP but we generalize the idea to multiple<br>
nodes on other side. And we need bridge logic to not duplicate traffic<br>
too much (only for broadcast data this would be the case then, like<br>
OLSR traffic).<br>
<br>
So on one extreme you could add all known other nodes to the list of<br>
other sides to virtual network device on every node. Some of those<br>
connections would work, some of them would not, but this would then<br>
OLSR on top of all this recognize and set routes properly.<br>
<br>
Of course this extreme would not be useful for big meshes but having<br>
this possibility some higher logic (from userspace) could take a<br>
subset of all nodes and just those configure on network device. But<br>
having this generalization would be really useful.<br>
<br>
So this would make topology completely decentralized and also traffic<br>
which would go between nodes could go directly and not over the<br>
central server.<br>
<br>
In this way our networks would really become link-level independent.<br>
Whatever we use, all would work.<br>
<font color="#888888"><br>
<br>
Mitar<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
WLANware mailing list<br>
<a href="mailto:WLANware@freifunk.net">WLANware@freifunk.net</a><br>
Abonnement abbestellen? -> <a href="https://freifunk.net/mailman/listinfo/wlanware" target="_blank">https://freifunk.net/mailman/listinfo/wlanware</a><br>
<br>
Weitere Infos zu den <a href="http://freifunk.net" target="_blank">freifunk.net</a> Mailinglisten und zur An- und Abmeldung unter <a href="http://freifunk.net/mailinglisten" target="_blank">http://freifunk.net/mailinglisten</a><br>

</div></div></blockquote></div><br></div>