[Click] Help FromHost!!

[Ian Rose]

 From what I am able to tell, if you replace 'ToDevice(tun0)' with 
'foo::Null' and 'FromHost(tun0)' with 'foo -> Unqueue', your 
configuration works as you expect (although I encourage you to verify 
this yourself).  From this I have to assume that the problem lies not in 
your click config, but instead in your usage of the Tun device, which I 
must admit I know very little about.  However, from briefly reading the 
tun man page (on FreeBSD 7.2-STABLE) I think that you are confusing tun 
with tap.  Specifically, tun seems to expect a network (IP) layer 
packet, not a MAC (Ethernet) layer packet as tap does.  From 'man tun':

>  If the TUNSLMODE ioctl has been set, packets read from the control device
>      will be prepended with the destination address as presented to the net-
>      work interface output routine, tunoutput().  The destination address is
>      in struct sockaddr format.  The actual length of the prepended address is
>      in the member sa_len.  If the TUNSIFHEAD ioctl has been set, packets will
>      be prepended with a four byte address family in network byte order.
>      TUNSLMODE and TUNSIFHEAD are mutually exclusive.  In any case, the packet
>      data follows immediately.
> 
>      A write(2) call passes a packet in to be ``received'' on the pseudo-
>      interface.  If the TUNSIFHEAD ioctl has been set, the address family must
>      be prepended, otherwise the packet is assumed to be of type AF_INET.
>      Each write(2) call supplies exactly one packet; the packet length is
>      taken from the amount of data provided to write(2) (minus any supplied
>      address family).  Writes will not block; if the packet cannot be accepted
>      for a transient reason (e.g., no buffer space available), it is silently
>      dropped; if the reason is not transient (e.g., packet too large), an
>      error is returned.

Given this, I'm not sure how exactly your current configuration could 
lead to the exact problem you are seeing, but I would say delete your 
EtherEncap element and adjust your offsets in the second file 
appropriately and see if that works.  Also try to identify whether the 
bytes are being dropped from the front of the packet or the rear, as 
that may also aid debugging.

Cheers,
Ian


María Gómez wrote:
> This is my configuration:
> 
> //this file generates UDP traffic
> 
> RatedSource(DATA \<55 44 50 20  70 61 63 6b  65 74 21 0a  04 00 00 00  
> 01 00 00 00 
>   01 00 00 00  00 00 00 00  00 80 04 08  00 80 04 08  53 53 00 00
>   53 53 00 00  05 00 00 00  00 10 00 00  01 00 00 00  54 53 00 00
>   54 e3 04 08  54 e3 04 08  d8 01 00 00>, RATE 20, LIMIT 10000)       
>     //data = 72 bytes
>     -> c::Counter   
>     -> SetTimestamp       
>     //-> StoreTimestamp(TAIL true)
>     -> DynamicUDPIPEncap(1.0.0.1, 1234, 2.0.0.2, 1234, INTERVAL 10)      
> //header IP= 20 + header UDP= 8
>     -> SetUDPChecksum   
>     -> SetIPChecksum   
>     -> EtherEncap(0x0800, 1:1:1:1:1:1, 2:2:2:2:2:2)                
> //header eth = 14
>     -> Print ("source")                                                  
>            // packet length 114
>     -> c2::Counter   
>     -> cola::Queue()                           
>     -> l::LinkUnqueue (0, 512 kbps)               
>     -> Queue   
>     -> c3::Counter
>     -> ToDevice(tun0)
> 
> 
> //the other file
> 
> FromHost(tun0)
>     -> Queue
>     -> l1::LinkUnqueue(0.16, 512 kbps)            //link
>     -> Queue   
>     -> c::Counter       
>     -> SetTimestamp   
>     -> Unqueue
>     -> brs::BandwidthRatedSplitter(1000 bps)   
>     -> ToDump(tiempo1.dump, ENCAP IP)       
>     -> Print   
>     //-> Print("tasa menor de 1000 bps")
>     //-> CheckIPHeader2   
>     //-> Strip(14)                        //IPV4
>     -> GetIPAddress(16)               
>     -> DropBroadcasts       
>     //-> CheckUDPHeader   
>     //-> StripIPHeader()   
>     -> DecIPTTL                   
>     //-> IPPrint("hola",PAYLOAD hex, ID true, TTL true, LENGTH 
> true)//OUTFILE dump_packets)       
>     -> DynamicUDPIPEncap(2.0.0.2, 1234, 1.0.0.1, 1234, INTERVAL 10)     
>     -> EtherEncap(0x0800, 2:2:2:2:2:2, 1:1:1:1:1:1)                   
>     -> Queue
>     ->l2::LinkUnqueue(0.16, 512 kbps)            //link
>     -> Queue
>     -> ToDevice(tun1)
> 
> brs[1]-> Print("tasa mayor de 1000 bps") -> IPPrint("hola",PAYLOAD hex, 
> ID true, TTL true, LENGTH true)    -> d1::Discard;
> 
> 
> Although the second file has only FromHost(), Print() and Discard, the 
> console output is 110 bytes.
> 
> Thank for your time
> 
>  > Date: Fri, 28 Aug 2009 19:52:39 -0400
>  > From: ianrose at eecs.harvard.edu
>  > To: maria_gn1 at hotmail.com
>  > CC: click at pdos.csail.mit.edu
>  > Subject: Re: [Click] Help FromHost!!
>  >
>  > Can you send your click configuration?
>  >
>  >
>  > María Gómez wrote:
>  > > Hi!!
>  > >
>  > > I don't understand why my configuration loses 4 bytes when using 
> the element FromHost.
>  > >
>  > > Thanks
>  > >
>  > > _________________________________________________________________
>  > > Toda la información meteorológica. Consulta en MSN el tiempo que va 
> a hacer en cualquier lugar de España o del Mundo.
>  > > http://eltiempo.es.msn.com/
>  > > _______________________________________________
>  > > click mailing list
>  > > click at amsterdam.lcs.mit.edu
>  > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
> ------------------------------------------------------------------------
> ¡Que no te pillen atascos ni radares! En MSN te damos toda la 
> información sobre el estado de las carretas y te mostramos dónde se 
> encuentran los radares de tráfico. <http://motor.es.msn.com/servicios/>