| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Haiku defines AF_INET as 1, not 2, so update a comment to reflect
reality.
(There has probably never been a version of rpcapd on Haiku built on the
original code, which just put structures directly on the wire, rather
than our version of the code, which has explicit serialization and
deserialization code, so there should be no reason to worry about Haiku
having a diferent value, as it would never appear on the wire.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stick a byte-order magic number, in the host byte order of the server,
into the authentication reply.
If the authentication reply is large enough to contain that magic
number, extract it and, from it, determine whether the server's byte
order is the opposite of the client's byte order; if it's not present,
assume the server has the same byte order.
If the two byte orders are differen, do the same byte-order fixing of
the packet contents that we do when reading a pcap file or pcapng
section with the opposite byte order, so that host-byte-order fields are
converted from the byte order of the host that sent or wrote them to the
byte order of the host that received or read them.
This change will allow a client to work with all servers, regardless of
whether they provide the byte order or not, although if the server
doesn't provide the byte order, and it happens to be the opposite of the
client's byte order, packets with a link-layer header type that contains
host-byte-order fields will not be able to be processed correctly. It
also allows clients that don't handle the byte order magic number in the
authentication reply to work with all servers, as they will just discard
what they consider extra data at the end of the reply.
(Note: fixing the byte order in the server requires that the client send
a byte order indication to the server, so *either* fix works only
between an updated client and an updated server. We already have
optional data in the authentication reply, to allow updated servers and
clients to negotiate a protocol version while still allowing updated
clients to work with older servers and older clients to work with
updated servers, so this just continues that mechanism.)
|
| | |
|
| |
|
|
|
|
| |
Instead of defining intN and uintN types for use in the rpcap protocol -
except on Haiku - just use the C99 intN_t and uintN_t types, as we now
require them to be available.
|
| |
|
|
| |
Haiku declares and uses them for itself but in a different way.
|
| | |
|
| |
|
|
| |
[skip ci]
|
| |
|
|
|
| |
That's what I'm doing in the rpcap protocol I-D I'm writing, as it makes
it a bit cleaner to do the "uppermost bit means reply" stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might make it a bit cleaner to handle new authentication types;
clients will still have to check for PCAP_ERR_AUTH with particular error
strings to detect "that authentication type isn't supported by the
server", but at least they can check first for
PCAP_ERR_AUTH_TYPE_NOTSUP.
Also add PCAP_ERR_AUTH_FAILED for authentication failures and
PCAP_ERR_TLS_REQUIRED for "the server requires TLS". PCAP_ERR_AUTH is
used for all other errors, including internal errors.
While we're at it, fix one case where the wrong error code was returned
for "set sampling" request errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the authentication phase, which begins when the connection is
made and ends when an authentication reply is received or the connection
is closed, require that all request have a version number of 0, and
accept version 0 in that phase, regardless of whether we support it once
we're authenticated. That means the messages from the client will not
be rejected any server with an "unsupported version" error, and also
means we can distinguish between a plaintext request and a TLS handshake
message.
Have the server send out authentication replies with a payload giving
the minimum and maximum version number supported by the server. Have
the client accept authentication replies whether or not they have that
additional information; if the reply has no payload, the server is
assumed to support only version 0. This means that old servers that
don't supply that information, and new servers that do, can be handled
by the new client code; old clients discard extra payload, and only
support version 0 (no servers or clients supporting versions other than
0 have been released, yet), so they can also handle both old and new
servers.
The client then uses that information (sent or implied) to try to find
the highest version that it and the server supports. If there is no
such version, it's impossible for the client and server to communicate
further, so the client just reports an error to its caller and gives up.
If there *is* such a version, the client then uses it in all subsequent
requests, and the server replies with the version in the request.
For data packets, the version used in the "start capture" request is
used.
This avoids timeouts or dropped connections with old servers due to the
initial request having an unsupported version number, and means that the
negotiation never requires two authentication requests.
|
| |
|
|
| |
And don't change #defines for structure field values, either.
|
| |
|
|
|
|
| |
Removing it would be a *protocol* change, and there are clients out
there that expect the open reply to be 8 bytes long. Just continue to
send a zero over the wire.
|
| |
|
|
|
|
|
|
|
|
|
| |
That way, the failure modes for those are a bit less ugly; for the
former, you'll get a TLS handshake failure error, and for the latter,
you'll get a "server requires TLS" authentication error, rather than
some ugly protocol error from rpcapd in the former case and TLS in the
latter case.
To make this work, we just have to make sure that we never use protocol
version 22. Do so.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also encode the control sockets in adition to the data
socket. Clients performs a TLS handshake when the scheme is rpcaps://
rather than rpcap://. Both active and passive modes are supported, but
transfert via UDP is not (yet) supported (the lib returns an error in
that case).
I did some adaptation to the windows code but couldn't tested so for all
I know it may not even compile.
Also tried to fix the indentation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using rpcapd one may want the forwarded traffic to be encrypted.
When running rpcapd via initd it is relatively easy to add stunnel but
the client still have to implement TLS. Or one could also use an ssh
tunnel but it's a lot of setup. Ultimately, it is simpler than rpcap
protocol could run on SSL natively. So this patch adds a -S option to
rpcapd that will wrap the data socket into a TLS tunnel (in both passive
anbd active mode, as long as it's TCP not UDP).
The start capture message has an additional flag: ssl, asking the client
to initiate a TLS handshake once he is connected to the data socket.
This patch is not polished as I'm more interested in early opinions at
this stage. Please let me know what you think of the idea and its
implementation so far.
Proof of concept:
generate a private key, a self signed root cert:
$ openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 36500 -out cert.pem
then run rpcapd with option -S (ssl) and -K and -C:
$ rpcapd -n -S -K key.pem -C cert.pem
Once recompiled, tcpdump can attach to this rpcap:// service and the
traffic will be encrypted.
|
| |
|
|
| |
And drop in another Y2.038K note.
|
| |
|
|
| |
As a follow-up to comit 5f2a5c03e0f91bc2dc2ae33838db273dd6c7d8d9.
|
| | |
|
| |
|
|
|
|
| |
Version numbers are unsigned, so they can never be < 0, so checking
whether a version is less than the minimum supported version will never
fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we send a "wrong version number" error message to an old client
(before the changes to support version negotiation) with a version
number other than 0, it'll treat it as a protocol error and return the
wrong error message to the caller. Instead, if the client's version
number is too old for the server, send back the version number they sent
us; they'll try it again and get the same error, and give up. (This
would happen only if there's a server that doesn't support version 0;
let's not create so many protocol versions that there's a temptation to
drop older ones.)
Also, add details on protocol versioning and protocol negotiation (the
construction of which pointed out the failure mode).
|
| |
|
|
|
|
| |
Currently, we only have one protocol version, but the code should be
able to handle multiple versions in the future - and to be able to work
with older code that doesn't do negotiation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Have two service loops, one of which runs before we are authenticated
(so the only messages we accept are "authenticate me" messages) and one
which runs after we are authenticated (where we can accept command
messages, but not "authenticate me" messages).
Have the service loops do protocol version checking; currently, we only
support one version, but the first loop would do protocol negotiation in
the future, while the second loop would treat messages with a version
other than the negotiated one as an error (and there might be different
loops for different versions, as some or all messages might have
different formats with different versions).
They already need a switch statement to switch on the message type, so
we don't need to have rpcap_checkmsg() do the type checking.
Have routines to process the various message types; they do all the work
of processing the message, and return 0 on success, send an error
message to the client and return 0 on failure, and log an error message
and return -1 on a network error.
Check for errors when receiving and sending network data; always log
those messages.
Check to make sure the message length isn't too short; send an error
message to the client, and discard the message, if it is.
|
| | |
|
| |
|
|
|
|
|
|
| |
rpcap-protocol.h doesn't need portability.h or pcap/funcattrs.h, so
don't include it. It does, however, need sockutils.h, for SOCKET.
That means rpcap-protocol.c has to include portability.h, as it uses
pcap_strerror().
|
| |
|
|
|
| |
That way, rpcapd doesn't depend on them being exported from libpcap
(which they shouldn't be).
|
| | |
|
|
|
That means that everything in rpcap is part of rpcapd.
Fix up the list of files included in the tarball while we're at it.
|
