On Sun, Apr 03, 2016 at 07:03:09PM -0400, Willem de Bruijn wrote:
> On Thu, Mar 31, 2016 at 7:39 PM, Stephen Hemminger
> <step...@networkplumber.org> wrote:
>
> > Rather than bodge AF_PACKET onto TUN, why not just create a new device type
> > and control it from something modern like netlink.
Do we really want to introduce a whole new device type? The tun device
is working perfectly fine, except for the fact that there is no way to
send/receive multiple packets in one go.
> Depending on the use-case, it may be sufficient to extend AF_PACKET
> with limited tap functionality:
>
> - add a po->xmit mode that reinjects into the kernel receive path,
> analogous to pktgen's M_NETIF_RECEIVE mode.
>
> - optionally drop packets in __netif_receive_skb_core and xmit_one
> if any of the registered packet sockets accepted the packet and has
> a new intercept feature flag enabled.
>
> This can be applied to a dummy device, but much more interesting
> is to interpose on the flow of a normal nic. It is clearly not a drop-in
> replacement for a tap (let alone tun) device. I have some preliminary
> code.
It's not really tinc's use case, but I did try using socket(AF_PACKET)
bound to a tun interface, just to see if sendmmsg()/recvmmsg() works
then. It does, but indeed for packets that are sent to the socket, they
need to be reinjected into the kernel receive path. So I'll be happy to
test out your preliminary code.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
