[Click] Problem with KernelTap : size of packet readed from TAP
Eddie Kohler
kohler at cs.ucla.edu
Wed Jul 16 18:48:33 EDT 2008
Remi,
It certainly would seem more natural to treat the MTU consistently as counting
the network header only. (It used to count network + link headers in the
KernelTap case.) I have checked in a patch which also fixes some other bugs.
If you aren't using git, the diff can be downloaded here:
http://www.read.cs.ucla.edu/gitweb?p=click;a=commitdiff;h=6014975667600091c1992fca1c859c28bddfa869
Thanks for the bug report.
Eddie
remi.clavier at orange-ftgroup.com wrote:
>
> Thanks to Michael Voorhaen [michael.voorhaen at ua.ac.be], the link between
> two TCP applications using click works. But, in my case, only for frames
> with a lesser size than MTU.
> If frame size is equal at MTU (case of fragmented frame), 14 bytes are
> missing at the end of it.
> A deeper analyze of the code thows that the number of read bytes is
> equal to _mtu_in (=MTU+2) and the variable _type is 0.
> The size of the information to read is MTU+16... (
> MTU+2bytes+EthernetHeader) At is easy to show if we increase the 3th
> param value of the read (_fd,...) function.
>
> Perhaps it's a problem of compilation constant, or a bad behaviour of
> tap on my LINUX implementation (ubuntu 8.04).
>
> It's this a know issue and, if yes, it's a patch or a workaround about?
>
> Thanks for all help
>
> Regards
>
> Remi
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
More information about the click
mailing list