On Mon, Feb 23, 2009 at 1:17 PM, Oliver Zheng
<[email protected]> wrote:
> Thanks for the response Aaron.
>
> On Mon, Feb 23, 2009 at 11:34 AM, Aaron Turner <[email protected]> wrote:
>> In my experience, sending packets on eth0 causes the packet to bypass
>> the TCP/IP stack and be sent out sight unseen. Hence, you won't be
>> able to inject packets into a TCP stream with the target of the local
>> host.
>
> Well that kind of sucks. =( It seems weird that an outgoing packet
> like this could be filtered by the kernel. What criteria does a packet
> like this fit for it to be filtered out? (e.g. it doesn't match a TCP
> connection, but obviously it does in this case.) The only thing I can
> think of is that the kernel uses a different incoming adapter (really
> low level?) than libpcap, which sounds wrong since libpcap should be
> operating at the lowest possible layer, right?
It's not "filtered'. Rather libpcap (and the PF_PACKET api on Linux)
bypasses the TCP/IP stack completely for outgoing packets.
>> Sending packets via loopback might work- I've never tried that to be
>> honest. I'm not really sure if you can inject standard ethernet
>> frames or you need to convert to Linux's cooked SLL header format.
>> You might try setting the destination MAC to that of eth0 and see if
>> the kernel will route it for you.
>
> Tried sending an incoming packet to lo, no go either. It's the same
> packet as if I had sent it on eth0. Should I perhaps be changing the
> MAC address to the one on lo? What do packets even look like on the
> lo? In that SLL format? I can't think of any application that uses lo
> for communication that I can use Windump to look at.
tcpdump/Wireshark will show you the Linux SLL header. Basically the
struct looks like:
typedef struct {
u_int16_t source; /* values 0-4 determine where the packet
came and where it's going */
u_int16_t type; /* linux ARPHRD_* values for link-layer
device type. See:
*
http://www.gelato.unsw.edu.au/lxr/source/include/linux/if_arp.h
*/
#define ARPHRD_ETHER 1 /* ethernet */
u_int16_t length; /* source address length */
u_char address[8]; /* first 8 bytes of source address (may be
truncated) */
u_int16_t proto; /* Ethernet protocol type */
} linux_sll_header_t;
Honestly, loopback is a weird beast and it wouldn't surprise me at all
that it won't work for your needs. Your best bet is to run your
application on the other host (or a 3rd host) and inject packets that
way.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little
temporary Safety,
deserve neither Liberty nor Safety.
-- Benjamin Franklin
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
