[Click] TCP Reset (RST) with From/To Host

[Nicholas Weaver]

On Wed, Apr 11, 2007 at 09:31:50AM -0400, Robert Ross composed:
> We are attempting to use Click in userlevel mode to modify the TTL on
> outgoing packets on a system.  In order to do this, we made very slight
> modifications to the example config "FromHost-Tunnel.click" supplied
> with the Click source.  However, even if only making slight
> modifications necessary to run this exact example config in userlevel
> mode, the config displays the same problematic behavior: 
> 
> Both ICMP and UDP packets appear to work fine in both directions. 
> Outgoing packets are addressed through the "fake0" interface and appear
> on the greater network as coming from the real IP address.  Incoming
> packets are addressed through the "eth0" interface and appear to the
> Linux application as coming to the "fake0" interface.  This is all
> exactly as we would expect.
> 
> The problem comes with TCP packets which never seem to make it into the
> Linux kernel from Click.  Using Wireshark, we see that the TCP SYN
> packet goes out, a SYN/ACK packet comes back, and then a "RST/ACK"
> packet goes back out.  This implies that either Click or the Linux
> kernel does not like something about the TCP handshake.  We have
> compared packet exchange when using Click versus not using Click and we
> cannot any significant differences between the SYN and SYN/ACK packet
> exchange.  The only clue we have so far is that this problem only occurs
> one direction.  Even with Click running, another non-Click machine can
> successfully negotiate an incoming TCP connection for something like SSH
> or Telnet.  The problem is with outgoing connections where the system
> running Click wishes to initiate a TCP connection to another non-Click
> machine.
> 
> I have not provided my script because this problem is repeatable simply
> by using the "FromHost-Tunnel.click" example config supplied with Click.

What I think is happening is that by being in USERLEVEL, the normal
Ethernet packets are still going to the host processing stack as well
as Click, and the host is interpreting those packets.

What is the results of ifconfig for the Ethernet?  IMO, it sohuldn't
have an IP address, or at least should have a DIFFERENT IP address, so
that the host doesn't respond to those Ethernet packets.

(Note this is NOT an issue in Kernel mode click, as in Kernel mode,
Click is the only process which gets the packets)

> Any help would be greatly appreciated!
> 
> Thanks,
> Robert Ross
> DSCI Inc.
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

-- 
Nicholas C. Weaver                               nweaver at icsi.berkeley.edu
     This message has been ROT-13 encrypted twice for higher security.