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>
