Hi David,
Actually, I didn't concern ipv6 packet.
And yes, as you said, it was not good idea to look for a packet
length within the packet itself.
But since read(2) would return multiple packets in single reading
data, so we need to know the boundary of the packet.
It is hard to know the packet the exact boundary...
So I rewrote a patch using completely different approach.
In this patch I'm using getmsg(2) instead of read(2).
It is guaranteed that getmsg would return single message from
kernel side buffer, aka stream head, and we can expect single
message contain single packet data as tun driver treats packet
as single message. By using getmsg, we don't need to care
about the boundary of the packet data.
I did test with this patch on x64 Solaris11, and it worked well for me.
But, I'm not sure it can handle ipv6 packet accordingly... since I
can't test it.
Thanks,
Kazuyoshi
2011/11/23 David Woodhouse <dwm 2 at infradead.org>:
> On Wed, 2011-11-23 at 01:43 +0900, Kazuyoshi Aizawa wrote:
>> + ? ? ? ? ? ? ? ? ? ? ? while (left > 0){
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int iplen;
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iphdr = (struct ip *) pkt;
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iplen = ntohs(iphdr->ip_len);
>
> What guarantee is thare that 'left' is more than one byte, if it's
> non-zero? You're reading bytes 3 and 4... and for IPv6 we'll need to
> read bytes 5 and 6.
>
> If that's something that's guaranteed, that's fine. Otherwise, we'll
> need to cope with the case where we have read *something* of the next
> packet, but not yet enough to know its length.
>
> --
> dwmw2
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tun.c-3.14-patch-solaris-getmsg
Type: application/octet-stream
Size: 1195 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20111123/f7a42888/attachment.obj>
