[Click] Problems using Click
Luis Otero
loteroc at gmail.com
Fri Feb 4 07:00:51 EST 2005
Julian,
no he podido lanzar tu configuración pero creo que John Bickett apunto
correctamente el problema. Debes inhibir completamente la respuesta
del stack linux: el te dice que lo hagas levantando las interfaces sin
IP. En tu caso es el stack el que esta enviado un paquete de RESET
porque esta recibiendo paquetes sobre una conexion que no reconoce
como valida (la ha establecido Click).
In other words, you should disable response from linux stack. Linux
stack is the one sending the RESET packets. Your configuration is
working fine, probably,
Cumps, L.
On Fri, 4 Feb 2005 11:53:44 +0100, Julián David Morillo Pozo
<jmorillo at ac.upc.edu> wrote:
> 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
> =============================================
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
More information about the click
mailing list