[Click] packets not seen by click unless tcpdump running

[Eddie Kohler]

Please try it with PROMISC and see if Click gets all the packets (as 
well as others).  Let us know...

E


On Oct 14, 2004, at 9:03 PM, Marcel Poisot wrote:

> I don't think PROMISC is my problem.  I really do just want packets 
> destined for my test machine, not everything else on the network.  My 
> second machine sends telnet SYN packets to the test box's IP address, 
> so the test box should be giving them to my click configuration even 
> with PROMISC=false.
>
> And it does give some of the packets, some of the time.  It seems 
> somewhat random as to how many of the three telnet SYN packets Click 
> sees, but usually its not all three.  However, with tcpdump 
> simultaneously running on the test machine, ALL (3) of the expected 
> telnet SYN packets (addressed for the test machine) enter the Click 
> configuration, every time.
>
> I added a Queue just after ToDevice, just in case, to no avail.
>
> I'm stymied.
>
>
> Marcel
>
>
> Eddie Kohler wrote:
>
>> Hi Marcel,
>> 1. Your first problem sounds like you didn't set FromDevice's PROMISC 
>> argument to true.  Without PROMISC true, the FromDevice is not acting 
>> as a sniffer; it's just reporting packets sent to *this* host.
>> 2. Queues maximize utilization.  You place a Queue anywhere you have 
>> a bursty input process, where you might need storage to absorb a 
>> burst.  For example, say you have a FromDevice that can generate up 
>> to 300 packets/sec, and a ToDevice that can send at most 250 
>> packets/sec.  Then you want to place a Queue in between, so that if 
>> the FromDevice generates a burst, no packets are dropped.  In 
>> concrete terms, you place it on the boundary between push elements 
>> and pull elements.
>> Eddie
>> On Oct 14, 2004, at 12:27 PM, Marcel Poisot wrote:
>>> I have the following configuration, run in User mode:
>>>
>>> FromDevice( eth0 ) -> ToDump( input.dump ) -> /* uninteresting stuff 
>>> */
>>>
>>> I have Iptables set to drop packets from INPUT, and accept all 
>>> packets
>>> from FORWARD and OUTPUT.  I do this because I just want to passively
>>> record packets right now, and I don't want the OS sending out RST or 
>>> any
>>> programs actually responding to packets.
>>>
>>> With this router running, I try to telnet to this machine from a 
>>> second
>>> machine, expecting input.dump to record the several SYN packets 
>>> issued
>>> by telnet trying to initiate the connection.  I have tcpdump running 
>>> on
>>> the second machine so I see the three SYN packets go out.
>>>
>>> However, input.dump only records the first SYN packet.  Sometimes I 
>>> see
>>> other traffic, such as ARP requests and NetBios broadcasts from other
>>> machines on the network.
>>>
>>> Strangely, if I run tcpdump at the same time as the click router, 
>>> then
>>> input.dump DOES record all the traffic I think it should be getting 
>>> (ie,
>>> the three SYN packets)!  What is going on here?  Why does the click
>>> router not receive traffic unless tcpdump is running?
>>>
>>>
>>>
>>> 2.
>>>
>>> What is the proper/required use of Queue?  Is it needed for Userland
>>> click configurations, or just Kernel mode?  Where in a configuration
>>> should I put them, and how many are needed?  (I really don't want any
>>> packets dropped).  Could this have anything to do with my problem 
>>> above?
>>>
>>>
>>> Thanks,
>>> Marcel
>>>
>>>
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click