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

Robert Ross rross at dsci.com
Wed Apr 11 09:31:50 EDT 2007


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.

Any help would be greatly appreciated!

Thanks,
Robert Ross
DSCI Inc.


More information about the click mailing list