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.
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.
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
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.
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.
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.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
