15 May
2013
15 May
'13
5:21 p.m.
I saw that it depends on libpcap, it is the only way to listen for icmp
messages?
In this case i think it is not the case to use icmp protocol and instad would
be simpler and more performant just a simple udp multicast socket like bmx6 do
15 May
15 May
6:30 p.m.
I don't see the problem of depending in libpcap. I like to have
tcpdump-mini in my nodes and it also depends on it.
I like that with the icmp approach the packet can be send using normal
ping6 command.
Anyway, magic-icmp is more than what we need and I will keep the
development until we don't use it in libremesh. So if you want to
implement it using UDP, for my is completelly fine!
On Wed, May 15, 2013 at 7:21 PM, Gioacchino Mazzurco <gio(a)eigenlab.org> wrote:
I saw that it depends on libpcap, it is the only way
to listen for icmp
messages?
In this case i think it is not the case to use icmp protocol and instad would
be simpler and more performant just a simple udp multicast socket like bmx6 do
6:59 p.m.
On Wednesday 15 May 2013 20:30:59 Pau wrote:
I don't see the problem of depending in libpcap.
I like to have
tcpdump-mini in my nodes and it also depends on it.
yes but i think we doesn't want to depend on things unless are necessary
I like that with the icmp approach the packet can be
send using normal
ping6 command.
yes i liked it too
Anyway, magic-icmp is more than what we need and I
will keep the
development until we don't use it in libremesh. So if you want to
implement it using UDP, for my is completelly fine!
I think that using libpcap just for exchanging some packet is an overkill,
maybe i am wrong but i think it can have a performance hit on routers
because pcap works coping the packets from kernel space to user applying the
filter you provide, i think this more CPU intensive than an udp socket moreover
with udp socket we can use a specific multicast group that i think is a good
thing ;)
7:35 p.m.
I don't think depending on libpcap (which is a known standard) is
something bad, but ok, for me the UDP approach is fine.
However, speaking about performance, take into account that the
magic-icmp code applies a libpcap filter which currently is "icmp6"
and it can be extended to something to filter only icmp6 requests and
comming from a link-local. Since the filter is applied directly to the
libpcap call, the kernel does not copy the non-filtered packets to the
user space.
Cheers
On Wed, May 15, 2013 at 8:59 PM, Gioacchino Mazzurco <gio(a)eigenlab.org> wrote:
On Wednesday 15 May 2013 20:30:59 Pau wrote:
I don't see the problem of depending in
libpcap. I like to have
tcpdump-mini in my nodes and it also depends on it.
yes but i think we doesn't want to depend on things unless are necessary
I like that with the icmp approach the packet can
be send using normal
ping6 command.
yes i liked it too
Anyway, magic-icmp is more than what we need and
I will keep the
development until we don't use it in libremesh. So if you want to
implement it using UDP, for my is completelly fine!
I think that using libpcap just for exchanging some packet is an overkill,
maybe i am wrong but i think it can have a performance hit on routers
because pcap works coping the packets from kernel space to user applying the
filter you provide, i think this more CPU intensive than an udp socket moreover
with udp socket we can use a specific multicast group that i think is a good
thing ;) 
8:13 p.m.
On 05/15/2013 09:35 PM, Pau wrote:
I don't think depending on libpcap (which is a
known standard) is
something bad, but ok, for me the UDP approach is fine.
However, speaking about performance, take into account that the
magic-icmp code applies a libpcap filter which currently is "icmp6"
and it can be extended to something to filter only icmp6 requests and
comming from a link-local. Since the filter is applied directly to the
libpcap call, the kernel does not copy the non-filtered packets to the
user space.
Also consider that bmx6 soon will (very likely) also have a dependency
on libpcap.
It'll be needed for example for the two-way tunnel support that we
discussed in the WCW
and seems the most convenient way to capture packets that indicate that
such a tunnel
was set up or is needed from any tunnel-client node.
/axel
Cheers
On Wed, May 15, 2013 at 8:59 PM, Gioacchino Mazzurco<gio(a)eigenlab.org> wrote:
On Wednesday 15 May 2013 20:30:59 Pau wrote:
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev I don't see the problem of depending in
libpcap. I like to have
tcpdump-mini in my nodes and it also depends on it.
yes but i think we
doesn't want to depend on things unless are necessary
I like that with the icmp approach the packet can
be send using normal
ping6 command.
yes i liked it too
Anyway, magic-icmp is more than what we need and
I will keep the
development until we don't use it in libremesh. So if you want to
implement it using UDP, for my is completelly fine!
I think that using libpcap
just for exchanging some packet is an overkill,
maybe i am wrong but i think it can have a performance hit on routers
because pcap works coping the packets from kernel space to user applying the
filter you provide, i think this more CPU intensive than an udp socket moreover
with udp socket we can use a specific multicast group that i think is a good
thing ;)
11 p.m.
On Wednesday 15 May 2013 22:13:10 Axel Neumann wrote:
Also consider that bmx6 soon will (very likely) also
have a dependency
on libpcap.
It'll be needed for example for the two-way tunnel support that we
discussed in the WCW
and seems the most convenient way to capture packets that indicate that
such a tunnel
was set up or is needed from any tunnel-client node.
I missed that feature discussion, can you explain in what it consist ?
16 May
16 May
7:43 a.m.
On 05/16/2013 01:00 AM, Gioacchino Mazzurco wrote:
On Wednesday 15 May 2013 22:13:10 Axel Neumann wrote:
we discussed two feature requirements for bmx6
1) the support of bidirectional tunnel (currently bmx6 uses two
unidirectional (one-way tunnels) for
gw and network (anycast like) routing over the unicast end-to-end
routing between each gw-client to gw peer.
These tunnels are setup on-demand (only when gw-client's user traffic is
send) and
a benefit here would be that gw-client nodes could trigger the setup of
these tunnels in both direction
and according to the best path perceived by the client.
2) to support virtual (overlay) links on top of an existing network by
specifying a remote ip address instead of a interface for meshing.
This way, it would be easily possible to interconnect clouds that have
no direct link between each other (eg over the internet, similar to what
tinc or other VPNs are doing).
Both features require to react on certain ipv6 header and icmp packets
that are send by other nodes but would normally not be delivered to the
bmx6 process.
Libpcap would allow to capture those packets and let the bmx6 daemon
react respectively.
/axel
Also consider that bmx6 soon will (very likely)
also have a dependency
on libpcap.
It'll be needed for example for the two-way tunnel support that we
discussed in the WCW
and seems the most convenient way to capture packets that indicate that
such a tunnel
was set up or is needed from any tunnel-client node.
I missed that feature
discussion, can you explain in what it consist ?
8:45 a.m.
On Thursday 16 May 2013 09:43:49 Axel Neumann wrote:
1) the support of bidirectional tunnel (currently bmx6
uses two
unidirectional (one-way tunnels) for
gw and network (anycast like) routing over the unicast end-to-end
routing between each gw-client to gw peer.
These tunnels are setup on-demand (only when gw-client's user traffic is
send) and
a benefit here would be that gw-client nodes could trigger the setup of
these tunnels in both direction
and according to the best path perceived by the client.
so at moment just the tunnel from client to gw is according client perspectve
and the one from gw to client is according to gw perspective?
It is not a good thing ?
2) to support virtual (overlay) links on top of an
existing network by
specifying a remote ip address instead of a interface for meshing.
This way, it would be easily possible to interconnect clouds that have
no direct link between each other (eg over the internet, similar to what
tinc or other VPNs are doing).
This would be very good and give to bmx6 a lot of advantages in respect to
other routing protocol :D
17 May
17 May
9:13 a.m.
New subject: BMX features Was: magic icmp
On Thursday 16 May 2013 10:45:10 Gioacchino Mazzurco wrote:
This would also save per packet overhead due to the elimination of the VPN (
tinc for example ) in the middle, this also mean less MTU problem, definely we
want this :D
2) to support
virtual (overlay) links on top of an existing network by
specifying a remote ip address instead of a interface for meshing.
This way, it would be easily possible to interconnect clouds that have
no direct link between each other (eg over the internet, similar to what
tinc or other VPNs are doing).
This would be very good and give to bmx6 a lot of advantages in respect to
other routing protocol :D 
9:48 a.m.
New subject: BMX features Was: magic icmp
I agree :)
Gioacchino Mazzurco <gio(a)eigenlab.org> ha escrit:
On Thursday 16 May 2013 10:45:10 Gioacchino Mazzurco
wrote:
respect to
--
S’ha enviat des del meu telèfon Android amb K-9 Mail. Si us plau, excusa la meva
brevetat.
> 2) to support virtual (overlay) links on top
of an existing network
by
> specifying a remote ip address instead of a
interface for meshing.
> This way, it would be easily possible to interconnect clouds that
have
> no direct link between each other (eg over
the internet, similar to
what
tinc or
other VPNs are doing).
This would be very good and give to bmx6 a lot of advantages in other routing protocol :D
This would also save per packet overhead due to the elimination of the
VPN (
tinc for example ) in the middle, this also mean less MTU problem,
definely we
want this :D
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
19 May
19 May
4:44 p.m.
New subject: BMX features Was: magic icmp
On 05/17/2013 11:13 AM, Gioacchino Mazzurco wrote:
On Thursday 16 May 2013 10:45:10 Gioacchino Mazzurco
wrote:
This would also save per packet overhead due to the
elimination of the VPN (
tinc for example ) in the middle, this also mean less MTU problem, definely we
want this :D
hehe, dont be over optimistic.
it'll be another end-to-end tunnel between the ip addresses of two bmx6
instances with a reduced MTU for all data traversing this virtual link.
Therefore one reason is to react on ICMP MTU exceeded messages which
should then trigger bmx6 to reduce the MTU of the related incoming
interfaces.
Anyway, its just an idea yet and I think it doesnt make sense to discuss
such details before a general design of the concept is available.
Regarding the other question, why libpcap and not ICMP.
Currently the linux kernel silently drops incoming tunnel (ipip) packets
unless a corresponding tunnel interface with proper local and remote
addresses already exists.
But with the automatic bidirectional tunnel setup I want to achieve that
these tunnel interfaces would be setup as a reaction on receiving such
ipip packets.
Libpcap could be used to deliver this packets to the bmx6 process. Bmx6
then creates the needed tunnel interface (with proper local/remote
addresses) and pops the packet back into the linux kernel. I dont know
any alternative way to easily capture such packets.
And another advantage for using libpcap instead of user space RAW
sockets is that with libpcap you could already filter for the desired
packets in kernel space
so that your user space process would not be loaded with all the
uniteresting ICMP packets (think of a ping flood).
/axel
2) to
support virtual (overlay) links on top of an existing network by
specifying a remote ip address instead of a interface for meshing.
This way, it would be easily possible to interconnect clouds that have
no direct link between each other (eg over the internet, similar to what
tinc or other VPNs are doing).
This would be very good and give to bmx6 a lot of
advantages in respect to
other routing protocol :D
4:42 p.m.
On 05/16/2013 10:45 AM, Gioacchino Mazzurco wrote:
On Thursday 16 May 2013 09:43:49 Axel Neumann wrote:
Yes! Normally it is!
When discussing this we had a specific scenario in mind which was about
connecting different mesh
clouds via GW nodes that would export only an aggregation of the
networks available inside each cloud.
But, actually I dont remember the details of the scenario. Maybe Nico or
Gui do?
/axel
1) the support of bidirectional tunnel (currently
bmx6 uses two
unidirectional (one-way tunnels) for
gw and network (anycast like) routing over the unicast end-to-end
routing between each gw-client to gw peer.
These tunnels are setup on-demand (only when gw-client's user traffic is
send) and
a benefit here would be that gw-client nodes could trigger the setup of
these tunnels in both direction
and according to the best path perceived by the client.
so at moment just the
tunnel from client to gw is according client perspectve
and the one from gw to client is according to gw perspective?
It is not a good thing ?
4234
days inactive
4238
days old
11 comments
4 participants
participants (4)
-
Axel Neumann -
Gioacchino Mazzurco -
Pau -
Pau