rh wrote:
I'm using libnet 1.1.1 and pcaplib 0.8.3 (I believe).
Linux 2.4.20 / 2.6.11 (and later, FreeBSD 5.2).
GCC 3.3
Apologies if this is too off-topic an application for this list.
I'm attempting to use libnet and pcap together to write a client using raw
sockets so that I can gain explicit control over the ip_p value in the IP
header.
By "raw sockets" do you mean raw *IP* sockets, or raw *link-layer*
sockets? On Linux, libpcap uses raw link-layer sockets
(PF_PACKET/SOCK_RAW) on most network interfaces.
What you might want to do is to write your own code, rather than using
libnet (which I think can use either raw IP sockets or, on Linux, raw
link-layer sockets to send packets) or libpcap, if all you want to do is
send packets with a protocol other than the ones supported by the host's
networking stack (that being what "explicit control over the ip_p value
in the IP header" means).
I need to test application-sensitive router configurations.
I.e., test whether the router handles IP packets not using TCP, UDP, or
ICMP?
I'm failing at connection establishment. I can squirt the packet out using
libnet and get a reply using pcap, but the connection-initiating TCP
If you're using TCP, you don't need explicit control over ip_p - the
OS's TCP stack will set it to 6 for you.
Are you thinking of some *other* field you need to control?
seems to be generating a RST on my behalf before I can transmit the
third packet of the handshake.
If another host sends a TCP packet to your machine, and your machine's
TCP stack doesn't know that a connection to which that packet belongs is
being set up, your machine's TCP stack will send an RST.
Reading that packet with libpcap will *NOT* help. libpcap does *NOT*
use mechanisms that can process packets before the networking stack sees
them, with packets processed by libpcap not being seen by the stack; the
mechanisms it uses are intended for "passively" tapping and for
implementing protocols not also implemented in the OS's networking
stack, not for "intercepting" traffic that would otherwise be processed
by the host's networking stack.
suse83 is running my raw-socket version of TTCP. The response from suse83
seems exactly like what would be expected if it received a SYN ACK in reply
to a SYN that it didn't know about.
That's because that's exactly what is happening, from the point of view
of suse83's networking stack.
I thought the libnet_init() call would make its underlying socket known to
the kernel so that the kernel would know about incoming traffic on that
port.
No - it's probably creating a raw socket at the IP layer, not any type
of socket at the TCP layer.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
