Skip to main content

Tcpflow and connections between local interfaces


Looks like tcpflow doesn't see connections between local interfaces. After a bit of digging, looks like such connections are "routed internally by the kernel", at least in Linux. And there are patches for Linux to force those packets out of one interface and in from another, but even that is only useful if you have an external network connecting both interfaces (looks like a simple crossover cable should be enough).

http://www.ssi.bg/~ja/send-to-self.txt

There is another option: using iptables to first make the packets leave the machine towards some external IP, and then using arpd to make a router send back those packets.

http://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface

And I see people reporting that tcpflow -i lo does work for them, capturing flows having local addresses even though different than 127.0.0.1.

http://fixunix.com/tcp-ip/327123-capturing-tcpdump-local-traffic.html

The interesting thing is that people seem to take for well-known that Linux routes through the "lo" interface the traffic between local interfaces; but I didn't find any authoritative source which explains any rationale, any configurability, any implementation. Which I guess would make it somewhat easier to find such things in the BSD's and OS X.

(I surely should go straight to the source code, but that feels fragile. I am not interested on the current implementation, but on the design: how should it work vs. how does it work right now. Although surely that kind of networking would be pretty baked in into the kernel...)

Would be interesting to know if this something missing in the BSD's/OS X or in libpcap.

Comments

  1. Well, looks like the problem rather is in tcpflow, since tcpdump does show the packets being routed with -i lo0! I just sent a bug report to tcpflow's current maintainer...

    ReplyDelete
  2. Confirmed, it was a bug in tcpflow. Fixed in a modified (not the official) 1.1.0-beta3, so it should be OK in the next official beta or release.
    Doing a capture with tcpdump -i lo0 and then feeding the output file to tcpflow -r didn't work either, by the way.

    ReplyDelete

Post a Comment