[Click] Help FromHost!!
María Gómez
maria_gn1 at hotmail.com
Mon Aug 31 13:54:36 EDT 2009
Thank you.
I've found the error
I have checked, as you advise, what part of the packet is reduced (4 bytes) ->
data
It follows that the FromHost element make: p->pull(4) (in fromhost.cc file) (I don´t know why)
I have also deleted the element EtherEncap (I mistook the tun interface for the tap interface)
Thank you sincerely for your advice and your time. I have spent much time thinking about it.
Regards
:D (I´m happy)
buscar
> Date: Mon, 31 Aug 2009 07:37:54 -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!!
>
> 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/>
_________________________________________________________________
Comparte tus mejores momentos del verano ¡Hazlo con Windows Live Fotos!
http://www.vivelive.com/compartirfotos
More information about the click
mailing list