[Click] packet rejects trasmitting a group of queued packets

[Guido Alejandro Gavilanes Castillo]

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