<div>Hi,</div><div><br></div><div>>Yes. There should be only one interface. But I do not understand what</div><div>>you mean by forwarding rule? I would like to configure only</div><div>>destination IPs and ports of all peers I would like to communicate</div>
<div>>with and interface itself should handle to which peer it should send a</div><div>>packet. Like switch is doing.</div><div><br></div><div>I think we are saying the same thing. In fact, with "forwarding rule" I mean a rule </div>
<div>that binds the packet to be encapsulated (i.e.: the inner packet) to the tunnel we want </div><div>to use (i.e.: the proper encapsulation header).</div><div>This can be done in different ways. In my proposal I considered "per-application"</div>
<div>filtering rules. For example:</div><div><br></div><div>if inner packet has (IP.src = 1.2.3.4, IP.dst = 1.2.3.5, IP.proto=tcp, TCP.sport= 3000, TCP.dport=40000) </div><div>use tunnel X, where tunnel X has:</div><div><br>
</div><div>IP.src = 160.80.103.147, IP.dst = 90.0.0.1, UDP.sport = 20000, UDP.dport = 30000</div><div><br></div><div>Now, I'm doing this because I considered a more complex scenario. If we want</div><div>to consider only the destination IP address (of the inner packet), the "Forwarding Table" </div>
<div>will be simpler. For example:</div><div><br></div><div>if IP.dst = 1.2.3.5 ==>> TunnelX</div><div>if IP.dst = 1.2.3.6 ==>> TunnelY</div><div><br></div><div>and so on...</div><div><br></div><div><br></div>
<div>>You will define new netlink protocol? Special for this virtual interface?</div><div><br></div><div>Yes, new protocol over a generic netlink socket (so we don't need a new family).</div><div><br></div><div>>In which sense? Virtual interface should be fully configurable with ip</div>
<div>>and ifconfig from the point of view of virtualized interface. Or do</div><div>>you think that also internal configuration (links to peers and such)</div><div>>would be configured with those tools?</div><div>
The basic configuration (IP address, netmask, MTU, ecc) is possible with ip</div><div>and ifconfig. As you said, the "internal configuration" needs a new tool. </div><div>Anyway,  if we want, we can extend "ip" to support this. </div>
<div><br></div><div>Marco</div><br><div class="gmail_quote">On Thu, Apr 15, 2010 at 10:59 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 Thu, Apr 15, 2010 at 10:37 AM, marco bonola <<a href="mailto:marco.bonola@gmail.com">marco.bonola@gmail.com</a>> wrote:<br>
> "One or more virtual interfaces can be export to user-space<br>
<br>
</div>From that I thought you will be doing only point-to-point connections<br>
and that you will have to make multiple virtual interfaces for each.<br>
<div class="im"><br>
> What I mean with "Dynamic virtual interface" is a iface for which I can<br>
> dinamically configure a set of different encapsulating/forwarding rules in a table.<br>
> In this way if we have 50 peers we are communicating with (and thus 50<br>
> different IP/UDP tunnels), we don't need 50 virtual ifaces.<br>
<br>
</div>Yes. There should be only one interface. But I do not understand what<br>
you mean by forwarding rule? I would like to configure only<br>
destination IPs and ports of all peers I would like to communicate<br>
with and interface itself should handle to which peer it should send a<br>
packet. Like switch is doing.<br>
<div class="im"><br>
> will be provided by a generic NETLINK socket.<br>
<br>
</div>You will define new netlink protocol? Special for this virtual interface?<br>
<div class="im"><br>
> Moreover, integration with standard configuration tools (e.g: ip, ifconfig)<br>
> is possible."<br>
<br>
</div>In which sense? Virtual interface should be fully configurable with ip<br>
and ifconfig from the point of view of virtualized interface. Or do<br>
you think that also internal configuration (links to peers and such)<br>
would be configured with those tools?<br>
<div class="im"><br>
> Does this support your idea?<br>
<br>
</div>It seems so. This is really great! Just some scrambling added and it is perfect.<br>
<br>
(I am sorry if I am using bad terminology.)<br>
<div><div></div><div class="h5"><br>
<br>
Mitar<br>
_______________________________________________<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></div>
</div></blockquote></div><br>