Allowing space for packet headers in Wintun Tx/Rx

[David Woodhouse]

My initial port of OpenConnect to use Wintun has a fairly simple
implementation for sending and receiving packets.

The transmit function is basically this:

   WintunAllocateSendPacket()
   memcpy()
   WintunSendPacket()

I don't like the memcpy very much. I'd like to receive and decrypt
incoming VPN packets from the public network directly into the Wintun
ring.

But packets have *headers*. Cisco AnyConnect, for example, has a single
byte of 'type' field at the beginning of its DTLS packets. We decrypt
the packet we receive from the public network, and *if* the first byte
indicates that it's a data packet, we deliver the packet data starting
from the second byte onwards into the tun device.

So even if I were to receive and decrypt into a buffer allocated with
WintunAllocateSendPacket(), I couldn't *send* that without a memmove()
to move it all down by one byte.

If WintunSendPacket took an additional 'offset' argument to disregard a
certain number of bytes at the beginning of the buffer, that would
probably suffice. Or is it possible to simply add to the pointer
returned by WintunAllocateSendPacket()?

Receiving is slightly more complex, as it's too late by the time
WintunReceivePacket() is called; the data have already been received
into the top of the available space. Perhaps the header reservation for
Rx could be an additional parameter to WintunStartSession(), and the
requested amount of space would always be available before the pointer
returned from WintunReceivePacket()? (It's not clear how to *use* that
knowledge in valid and safe C though.)

Are there better options?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210407/621d0252/attachment.bin>