[Click] question about test-tun.click

[Xavier Brouckaert]

Hi Eddie,

There are magical things in click :-)

I tried this :

ICMPSendPings(1.0.0.3,1.0.0.1) -> IPPrint(in) -> Queue ->
KernelTun(1.0.0.1/8) -> IPPrint(out) -> Discard

Note that in my short click config, there is no ICMPPingResponder.

When I launch it :
gav at osiris:~/Coding/click-1.4.1/conf$ sudo click tun.click
in: 1089363312.434501: 1.0.0.3 > 1.0.0.1: icmp: echo request (0, 1)
out: 1089363312.434888: 1.0.0.1 > 1.0.0.3: icmp: echo reply (0, 1)
in: 1089363313.434485: 1.0.0.3 > 1.0.0.1: icmp: echo request (0, 2)
out: 1089363313.434796: 1.0.0.1 > 1.0.0.3: icmp: echo reply (0, 2)
in: 1089363314.434493: 1.0.0.3 > 1.0.0.1: icmp: echo request (0, 3)
out: 1089363314.434813: 1.0.0.1 > 1.0.0.3: icmp: echo reply (0, 3)

There are Echo Replies ! So, they must be made by the kernel because I
don't create them in click. I ping myself through tun0 and the kernel IP
stack answers.  Seems logical but is this expected behaviour ?

So, I think that the exemple test-tun.click is misleading because
IPFilter(..), ICMPPingResponder and IPPrint(tun-ping) are useless ! If
they were useful, I would see tun-ping messsages.

The author of test-tun.click thinks that Echo Requests go out of
KernelTun and this is not true.

If you agree with me, it would be great to change the online
documentation accordingly.

Xavier

Le jeu 08/07/2004 à 17:42, Eddie Kohler a écrit :
> Xavier Brouckaert wrote:
> > Hi,
> > 
> > I'm learning click and I'd like to use it. In test-tun.click, I see this
> > : ( http://www.pdos.lcs.mit.edu/click/ex/test-tun.html )
> > ch[0] -> IPPrint(tun-ok)
> >     -> IPFilter(allow icmp type echo)
> >     -> ICMPPingResponder
> >     -> IPPrint(tun-ping)      (*)
> >     -> tunq;
> > 
> > gav at osiris:~/Coding/click-1.4.1/conf$ sudo click test-tun.click
> > tun-ok: 1089295895.570164: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 1)
> > tun-ok: 1089295896.580096: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 2)
> > tun-ok: 1089295897.580098: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 3)
> > tun-ok: 1089295898.580136: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 4)
> > tun-ok: 1089295899.580051: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 5)
> > tun-ok: 1089295900.580052: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 6)
> > tun-ok: 1089295901.580228: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 7)
> > tun-ok: 1089295902.580085: 1.0.0.1 > 1.0.0.2: icmp: echo reply (0, 8)
> > 
> > My question is : why do i never see a tun-ping message which should
> > correspond to the (*) line in the code ?
> 
> Hi Xavier,
> 
> Note the IPFilter two lines above.  This only lets "icmp echo" packets through 
> to the ICMPPingResponder.  The tun-ok lines are all "icmp echo reply" packets.
> 
> So why aren't any ICMP echoes getting to the IPFilter?  I believe this is 
> expected behavior.  The Click configuration is generating the ICMP echoes with 
> ICMPSendPings/ICMPPingSource; the kernel doesn't send packets _generated_ by a 
> particular tunnel back to that tunnel.
> 
> Eddie
> 
> 
> 
> > 
> > I know that it works OK with tethereal :
> > gav at osiris:~$ sudo tethereal -i tun0
> > Capturing on tun0
> >   0.000000      1.0.0.2 -> 1.0.0.1      ICMP Echo (ping) request
> >   0.000025      1.0.0.1 -> 1.0.0.2      ICMP Echo (ping) reply
> >   1.000043      1.0.0.2 -> 1.0.0.1      ICMP Echo (ping) request
> >   1.000067      1.0.0.1 -> 1.0.0.2      ICMP Echo (ping) reply
> >   1.999999      1.0.0.2 -> 1.0.0.1      ICMP Echo (ping) request
> >   2.000025      1.0.0.1 -> 1.0.0.2      ICMP Echo (ping) reply
> > 
> > So, I don't understand why the first IPPrint works and not the second.
> > 
> > Thank you for shedding light on this,
> > Xavier
> > 
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>