[Click] packet rejects trasmitting a group of queued packets

[Beyers Cronje]

Hi Guido,

I'm not sure if this might be related but have a look at
https://pdos.csail.mit.edu/pipermail/click/2007-January/005552.html

Are you running CVS version?

Are packets actually being pushed into the queues from myelement[1] ..
myelement[2] etc? Maybe check with adding a print statement between
myelement and the queues or reading the length handler of your queue
elements.

Beyers

On 4/6/07, Guido Alejandro Gavilanes Castillo <ggavilanes at gmail.com> wrote:
>
> Hello Click gurus,
> I am using click in some nodes to share some information by means of
> special ethernet encapsulated frames. On one node, a broadcast is
> generated in the form of a unicast by taking a single packet, cloning
> it and depending on output port on myelement, encapsulates it with
> different ethernet headers; however these packets go out of the node
> through the same interface, by means of a round robin scheduler and
> finally a queue as follows:
>
> myelement[0]  -> Queue() -> encap1 -> [0]roundrobinsched;
> myelement[1]  -> Queue() -> encap2 -> [1]roundrobinsched;
> myelement[2]  -> Queue() -> encap2 -> [2]roundrobinsched;
> roundrobinsched -> Print(OUTPUT,40) ToDevice(eth0);
>
> then
> FromDevice(eth0) -> Print(INPUT,40)-> classifier(...) ->
>
> Inputs to the myelement come from other paths in my config.
> And Strangely I have found that when I see a packet originated on the
> node, it is cloned and output by all three ports of my element as
> expected, but I see printed (and only finally transmitted to the
> ethernet channel attached to eth0) only the packet encapsulated by
> encap1, and not the others.
>
> Then I tried changing the order of the ports, lets say, encap 1 ->
> [2]roundrobinsched, and encap2->[0]roundrobinsched, and this time
> encap2 is the only packet I see printed as OUTPUT.
>
> I run this in user level, but originally on linuxmodule, the same
> configuration gives the same behavior (just one packet effectively
> transmitted) but with a message "ToDevice eth0 rejected a packet!"
> after the printed OUTPUT message.
>
> Another observation is that as these messages are transmitted my
> configuration states that one of destination hosts responds to the
> previous broadcast, so I verified that response, but the packet seems
> to be not arriving to eth0 (I dont see it in "INPUT"). Other hosts
> with the same configuration (but without sending previous broadcasts)
> actually see the incoming packets.
>
> I tried also changing ToDevice options, such as BURST parameter, as
> there are 3 sources of packets for the interface, but the result
> changing it is the same. these are the only packets I am putting on
> the interface, so I am still not sure if a "full" condition is reached
> as a previous click mailing list suggests as the cause in
> https://amsterdam.lcs.mit.edu/pipermail/click/2002-March/001126.html
>
> I would like to have some help with this, hope being clear enough
> explaining this problem, otherwise, please let me know and I will
> clarify a bit more as possible.
> Thank you in advance for your attention and information.
>
> Guido
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>