[Click] Strange buffer_length() value for packets of more than 1500 bytes

[Bobby Longpocket]

Hi Manel,

My guess is that it is related to the Ethernet driver on the receive side.  When you set the MTU higher (into jumbogram territory), it probably changes the receive mechanism to store only the first part of the packet in the 'data' part of the buffer and sticks the rest off in the 'frags' area of the buffer.  Probably your version of Click doesn't support packets that are stored this way (and, for all I know, none do).

Bobby


> Hi all,
> 
> I am using linuxmodule click-1.7 over linux-2.6.24.7 (but
> this is also  
> the case with linux-2.6.18.2)
> If I send packets of 1480 bytes and with the default mtu of
> 1500, the  
> the buffer size allocated at the receiver is of 1664, 
> 
> (p->buffer_length()= 1664 ) which is fine.
> However, when I send large packets of more than 1500 bytes,
> and set  
> the mtu to a value > 1500,  the buffer allocated at
> the reception is  
> always of 256 ((p->buffer_length()= 256)) whatever the
> packet size is.
> So, if I want to access to the data stored beyond the 256
> bytes in  
> that packet, the data I get is erroneous.
> So i am wondering if there is a limitation on the maximum
> buffers  
> size? where this limitation is hard-coded? and why does it
> change with  
> the mtu?
> 
> Thanks for helping
> 
> 
> Ps: Click scripts are roughly :
> 
> Sender :
> RatedSource ->UDPIPEncap -> EtherEncap ->
> ToDevice(eth0)
> Receiver:
> FromDevice(eth0) -> Myelement -> Discard
> 
> In Myelement, I only get p->buffer_length() and p->
> data() and p->end_data()
> 
> 
> Manel BOURGUIBA
> PhD Candidate
> PHARE - LIP6 - UPMC - Sorbonne Universit?s
> BC169 - Office 25/26-319
> 4 place Jussieu
> 75252 PARIS cedex 05
> +33 1 44 27 61 88