[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