----- Original Message ----- From: "Guy Harris" <[EMAIL PROTECTED]> To: <tcpdump-workers@lists.tcpdump.org> Sent: Monday, October 03, 2005 10:49 PM Subject: Re: [tcpdump-workers] pcap: prob w/libnet making raw socket client
> rh wrote: > > > Sounds like it's unavoidable. libnet and libpcap seem like they'd > > complement each other so well. > > libpcap is a low-level library, in that > > 1) it works at the link layer > > and > > 2) it doesn't deal with dissecting or constructing packets. > > As of 0.9.x, it *does* deal with sending as well as receiving packets. (Nice feature.) > libnet's main function appears to be constructing packets; it also > includes code to send packets, but that's probably in part because > libpcap hasn't always supported that. If it supports sending packets > over raw IP sockets, that might be another reason why it includes code > to send them. > > For sending IP packets (making use of the OS's IP layer, e.g. to do the > initial routing), the ideal would probably be a layer to do packet > construction and disassembly (think "libnet with dissection code > added"), and either directly using raw IP sockets (if they're reasonably > portable) or a library to hide platform-specific details of using raw IP > sockets (if they're not as portable as one would want) - libpcap > wouldn't fit in there, as it's too low-level. > > > 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 > > Yes, I know those guys (as per my from-memory use of "6", that being the > protocol number for TCP, in my message). However: > > > Sometimes I'd want to use a datagram > > ...you can just do that with a UDP socket; you don't need raw IP sockets > to put 17 in ip_p. Of course. > > 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. > > There *is* a socket option for that - the "protocol" parameter to the > socket call. That means you can't send a UDP datagram with a protocol > value of, say, 6, or a TCP segment with a protocol value of 17, but such Well that's the rub, eh? The ability to set any in-range value using socket() is useless unless the packets actually go out that way. It's almost not worth mentioning as a "socket option". OTOH, the IP_TOS sockopt will accept any value you give it within its range (at least, it will on the platforms I have to worry about). Valid, invalid (eg, MBZ bit set to 1), it doesn't care. You give IP_TOS a value, and that's how the packets go out on the wire. You can see what the router does with it. Life is good. > a packet would be misinterpreted by the receiver - or by any routers > that, for example, try to determine the flow to which the packet belongs. "What do the routers do with it?" is the question I have to answer. I don't worry so much about the ICMP protocol unreachable I'll get from the receiver until I can write handlers that accept and sink any incoming data. > If you're going to be sending stuff *that* strange, you shouldn't expect > a receiving machine to run an ordinary networking stack to handle them, > so it seems a bit odd that you're running ttcp on the remote machine, > unless you're trying to use that to test whether your code works if it's > *not* sending strange packets, just normal TCP packets. Mostly. For now, just using it to work out connection establishment. > > 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? > > Because libnet is using either raw IP sockets (or possibly packet > sockets), so that the socket creation and packet transmission completely > bypasses the TCP stack. I obviously need to go RTFM some more and then RTFCode. I haven't done raw sockets directly for a few years, and it looks like what I knew about it didn't have a very long shelf life. Thanks very much for the discussion. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
