[lime-dev] magic icmp
neumann at cgws.de
Wed May 15 20:13:10 UTC 2013
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
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.
> On Wed, May 15, 2013 at 8:59 PM, Gioacchino Mazzurco<gio at 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 ;)
> Dev mailing list
> Dev at lists.libre-mesh.org
More information about the lime-dev