[Patch] Allows tun_mainloop to handle multiple packets in single read.

[David Woodhouse]

On Wed, 2011-11-23 at 01:43 +0900, Kazuyoshi Aizawa wrote:
> [Issue]
> It seems tun_mainloop() assumes that reading data from /dev/tun
> device only have one packet, and the data must start from the
> beginning of the packet.
> But Solaris's tun driver could include multiple packets into single
> read(2), and the last packet would be truncated because buffer has
> only 2,000 byte of the size. Thus, next read(2) would return middle
> of packet data.
> It gets packet data corrupted, and results in lowering a performance. 

Hm, this concerns me a little, and it's not just the fact that you're
reading the packet length from the low 16 bits of the 'flow label' field
of an IPv6 packet. Fixing it for IPv6 would be easy enough, but I wonder
if that's actually a symptom of a *bigger* problem — that perhaps you
shouldn't be looking at the length encoded *within* the packet at all.

What happens if you receive an Ethernet packet which is longer than it
needs to be, so it has trailing bytes *after* the IP packet?

Then that packet gets routed or bridged to the tuntap device. Will the
trailing bytes end up being passed to userspace too? If userspace then
looks at the length field of the IP packet, it won't really skip to the
next packet; it'll skip to the trailing bytes of the offending packet,
and try to interpret *those* as a packet header.

So at the very *least* this looks like it needs to be fixed to handle
IPv6, but I worry that even that isn't enough...

(The buffer size probably wants increasing too, while we're at it. If
the network is busy a 2000-byte buffer fairly much guarantees that we'll
be splitting packets and having to read the second half in a separate
read() call almost all of the time).

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111123/cabea605/attachment.bin>