Re: [B.A.T.M.A.N.] [RFC v2 0/5] batman-adv netlink query API

Sven Eckelmann
2016-03-19T09:19:39Z

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

On Saturday 19 March 2016 16:49:34 Antonio Quartulli wrote:
> On Fri, Mar 18, 2016 at 01:04:50PM +0100, Sven Eckelmann wrote:
> > On Friday 18 March 2016 13:00:54 Matthias Schiffer wrote:
> > [...]
> >
> > > > What about the "socket" file?
> >
> > [...]
> >
> > > Ah, I forgot about that one because it is very different from the
> > > others.
> > >
> > > I think it should be possible to convert "socket" as well by wrapping
> > > the
> > > BATADV_ICMP packets in netlink packets. Or maybe it would be possible to
> > > drop that altogether and just do ping/traceroute in userspace with
> > > AF_PACKET or similar?
> >
> > The latter could be problematic for TP meter implementation [1,2,3,4,5].
> > Antonio, do you have an opinion about that?
>
> Personally I wouldn't mind doing ping/traceroute 100% in userspace.

How can this be implemented 100% in userspace? Lets ignore the
reply/forwarding part for a second and just concentrate on the initiator of
the ping/traceroute. It can use AF_PACKET in userspace to send batadv packets
directly on the hardif. But here comes the first problem... which is the
correct hardif? There can be multiple and the userspace does not really know
which one is the one the kernel would use at a particular time. So you have to
implement the same algorithms in userspace the emulate the kernel part (or you
may do something completely different). And still then you would have problems
when the kernel is tweaked and the userspace didn't receive this tweak.

Maybe it is necessary to ask the kernel before sending the ping by asking him
"hey, what interface would use use right now and what other parameters are now
required". Similar to what "ip route get 8.8.8.8" would do.

Or am I just overcomplicated things now?

Kind regards,
Sven

[-- Attachment #2: This is a digitally signed message part. --]