----- Original Message ----- From: "Guy Harris" <[EMAIL PROTECTED]> To: <tcpdump-workers@lists.tcpdump.org> Sent: Monday, October 03, 2005 6:49 PM Subject: Re: [tcpdump-workers] pcap: prob w/libnet making raw socket client
> 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. Raw IP sockets. > 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). Sounds like it's unavoidable. libnet and libpcap seem like they'd complement each other so well. > > I need to test application-sensitive router configurations. > > I.e., test whether the router handles IP packets not using TCP, UDP, or > ICMP? Whether the routers correctly prioritize packets with a variety of values in the 'protocol' field of the IP header. You know, these guys: http://www.iana.org/assignments/protocol-numbers Sometimes I'd want to use a datagram > > 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? No. I want to override what the kernel would otherwise place in there. Otherwise I'd just use a normal socket, eh? If there was a socket option for this field, as there is for the TOS field, there wouldn't be a problem. > > 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. I understand that. What I don't understand is why the underlying socket created and used by libnet isn't known to the kernel as bound to the port # the SYN ACK is coming back on. Ie, why doesn't the machines TCP stack know about this socket and its SYN_SENT state? > 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. I'm not trying to 'intercept' the packet ahead of the kernel. I just use pcaplib all the time, and thought it'd be easier to use it for this if I could. > > 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. Thanks for your tolerance of a marginally topical discussion. rh > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
