15 May
2013
15 May
'13
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 ;)