[Click] Problems using Click

Fri Feb 4 05:53:44 EST 2005

Sorry, on the previous mail, when I say  "If I don't use linux on my 
client..." I wanted to say "If I don't use CLICK on my client..."


El Viernes, 4 de Febrero de 2005 11:50, Julián David Morillo Pozo escribió:
> Hello,
>
> John, thanks for yout answer but I think it is not my solution (probably I
> didn't explain very well my problem). Briefly, my question is: Why, with my
> configuration shown in the previous mail, I can ping from one machine to
> the other but I cannot open a TCP connection?
>
> I guess that my kernel receives packets destined for it (a ping works
> correctly).
> The tcpdump log (shown in the previous mail) shows that my client machine
> (10.0.0.1) generates a SYN packet, then a SYN-ACK reply arrives from the
> server machine (10.0.0.4). The problem comes then, when my client machine
> generates a RESET packet instead of an ACK packet, and the connection is
> not established.
> If I don't use linux on my client everything works fine, so I guess that
> the problem is with CLICK. But pings works, and UDP too. Even T CP works ok
> until the third step of the 3-WayHandshake, when my client sents a RESET.
>
> Any idea?? (I'm completely lost)
>
> Thanks a lot
>
> El Jueves, 3 de Febrero de 2005 19:46, John Bicket escribió:
> > I think I understand that you want click to route packets from eth0
> > on the 10.0.0.X network.
> >
> > Your probably want to do this instead of what you configuration does:
> >
> > 1. run ifconfig eth0 up, but don't give it an ip address. Otherwise linux
> > will handle the routing and arp, and if I understand you correctly you
> > want userlevel click to handle this stuff.
> > 2. Use tun :: KernelTun(10.0.0.1/24). Linux will add the route to
> > 10.0.0.X through the tun0 brought up by kerneltun. Now you have
> > to send packets destined to 10.0.0.1 in your configuration to the "tun"
> > element, otherwise the kernel will not get them.
> >
> > --john
> >
> > Juli?n David  Morillo Pozo [jmorillo at ac.upc.edu] wrote:
> > >Sorry, there was a mistake on the previous message: the IP address of
> > > the client machine is 10.0.0.1 and not 10.0.0.4.
> > >
> > >El Jueves, 3 de Febrero de 2005 16:21, Juli?n David Morillo Pozo 
escribi?:
> > >> Hello,
> > >>
> > >> We are trying to comunicate two machines using user level CLICK, but
> > >> some strange things are happening. We are using two directly connected
> > >> machines that have flat IP addresses (10.0.0.1/32 and 10.0.0.4/32) and
> > >> that act both as a router and as a host. In order to allow this
> > >> behaviour, we are using the KernelTun element and every packet
> > >> generated by the machine is routed to the tun0 device created by this
> > >> element (this is the only route we have in the kernel forwarding table
> > >> of both machines).
> > >>
> > >> We are able to ping from one machine to the other but we can not
> > >> establish a tcp connection (ftp, ssh) between them. By executing
> > >> tcpdump on the client machine (10.0.0.4/32) we have got the following:
> > >>
> > >> tcpdump: listening on eth0
> > >> 15:34:58.439506 10.0.0.1.35284 > 10.0.0.4.ftp: S
> > >> 2110020349:2110020349(0) win 6024 <mss 2008,sackOK,timestamp 590699432
> > >> 0,nop,wscale 1> (DF) 15:34:58.439774 10.0.0.4.ftp > 10.0.0.1.35284: S
> > >> 2069372027:2069372027(0) ack 2110020350 win 5988 <mss
> > >> 2008,sackOK,timestamp 619677506
> > >> 590699432,nop,wscale 0> (DF)
> > >> 15:34:58.439948 10.0.0.1.35284 > 10.0.0.4.ftp: R
> > >> 2110020350:2110020350(0) win 0 (DF)
> > >>
> > >> And at the same time, click shows the following error messages:
> > >>
> > >> LinearIPLookup: no gw for 3205393
> > >> LinearIPLookup: no gw for 4215393
> > >>
> > >> Everything works fine if we use regular kernel forwarding in the
> > >> client machine (10.0.0.4/32).
> > >>
> > >> The CLICK configuration we are using in the client is the following
> > >> (in the server, the configuration is the same, just changing IP
> > >> addresses):
> > >>
> > >> ============================================================
> > >> // Shared IP input path and routing table
> > >> _xorp_ip :: Strip(14)
> > >>     -> CheckIPHeader(INTERFACES 10.0.0.1/32)
> > >>     -> _xorp_rt :: LinearIPLookup(10.0.0.1/32 1, 10.0.0.4/32 0);
> > >>
> > >> elementclass FixChecksums {
> > >>     input -> SetIPChecksum
> > >>           -> ipc :: IPClassifier(tcp, udp, -)
> > >>           -> SetTCPChecksum
> > >>           -> output;
> > >>     ipc[1] -> SetUDPChecksum -> output;
> > >>     ipc[2] -> output
> > >> }
> > >>
> > >> tun :: KernelTun(172.16.0.1/24) -> Paint(0) -> _xorp_rt;
> > >>
> > >>
> > >> // ARP responses are copied to each ARPQuerier and the host.
> > >> _xorp_arpt :: Tee(2);
> > >>
> > >> // Input and output paths for eth0
> > >> _xorp_c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002, 12/0800, -);
> > >> FromDevice(eth0) -> _xorp_c0;
> > >> _xorp_out0 :: Queue(200) -> _xorp_to_device0 :: ToDevice(eth0);
> > >> _xorp_c0[0] -> _xorp_ar0 :: ARPResponder(10.0.0.1 00:0C:6E:F2:9B:6E)
> > >> -> _xorp_out0;
> > >> _xorp_arpq0 :: ARPQuerier(10.0.0.1, 00:0C:6E:F2:9B:6E) -> _xorp_out0;
> > >> _xorp_c0[1] -> _xorp_arpt;
> > >> _xorp_arpt[0] -> [1]_xorp_arpq0;
> > >> _xorp_c0[2] -> Paint(1) -> _xorp_ip;
> > >> _xorp_c0[3] -> Print("eth0 non-IP") -> Discard;
> > >>
> > >> // Local delivery
> > >> _xorp_arpt[1] -> Discard;
> > >> _xorp_rt[1] -> Discard;
> > >>
> > >> // Forwarding path for eth0
> > >> _xorp_rt[0] -> DropBroadcasts -> _xorp_sw0 :: PaintSwitch();
> > >> _xorp_gio0 :: IPGWOptions(10.0.0.1)
> > >>     -> FixIPSrc(10.0.0.1)
> > >>     -> _xorp_dt0 :: DecIPTTL
> > >>     -> _xorp_fr0 :: IPFragmenter(1500)
> > >>     -> [0]_xorp_arpq0;
> > >>
> > >> _xorp_sw0[0] -> StoreIPAddress(10.0.0.1,12) -> FixChecksums ->
> > >> _xorp_fr0; _xorp_sw0[1] -> _xorp_cp0 :: Tee(2) -> ICMPError(10.0.0.1,
> > >> redirect, host) -> _xorp_rt;
> > >> _xorp_cp0[1] -> _xorp_gio0
> > >> _xorp_dt0[1] -> ICMPError(10.0.0.1, timeexceeded) -> _xorp_rt;
> > >> _xorp_fr0[1] -> ICMPError(10.0.0.1, unreachable, needfrag) ->
> > >> _xorp_rt; _xorp_gio0[1] -> ICMPError(10.0.0.1, parameterproblem) ->
> > >> _xorp_rt;
> > >> ==============================================================
> > >>
> > >> Does anybody know what is the problem?
> > >>
> > >> Cheers,
> > >
> > >--
> > >=============================================
> > >Juli?n David Morillo Pozo
> > >PhD Student - Computer Networking Group
> > >Department of Computer Architecture   (DAC)
> > >Polytechnical University of Catalonia (UPC)
> > >Phone: +34-934017182   Fax: +34-934017055
> > >URL: http://people.ac.upc.edu/jmorillo
> > >=============================================
> > >
> > >
> > >_______________________________________________
> > >click mailing list
> > >click at amsterdam.lcs.mit.edu
> > >https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click

-- 
=============================================
Julián David Morillo Pozo
PhD Student - Computer Networking Group
Department of Computer Architecture   (DAC)
Polytechnical University of Catalonia (UPC)
Phone: +34-934017182   Fax: +34-934017055
URL: http://people.ac.upc.edu/jmorillo
=============================================