This allows setting a suitable write-queue max length per client. The
desired value can be different based on a lot of variables, like memory
availabilty, network and CPU load, input/output link state, etc.
Related: SYS#5921
Change-Id: I4e9d5d836ddda215f9e7a075aa8e10d2d3854dd2
Resolve conflict with other Osmocom software by moving ports:
osmo-pcap-client 4237 -> 4227
osmo-pcap-server 4238 -> 4228
Notably the defines OSMO_VTY_PORT_PCAP_CLIENT and _SERVER are currently
not provided by libosmocore, but will be added with the related commit.
Related: OS#5203
Related: libosmocore I098f211370bba61995ce424ab64029bdd4c49e2d
Change-Id: I3b18b1fbbca2799f868f28104e2f5d513f93d46c
Take the chance to define SERVER_MAX_DATA_SIZE as pcap payload, which we
can later match to configurable snaplen parameter.
Change-Id: I45d4c59026faf1108c0976eb6ad8c270e3577dbf
Despite this value not being exported publicly, the truth is that
tcpdump and wireshark nowadays avoid processing any file with snaplen
bigger than this value:
"tcpdump: pcap_loop: invalid packet capture length 861244, bigger than
snaplen of 262144"
It also fails to set snaplen to values bigger than that:
"tcpdump -s 262145" --> "tcpdump: invalid snaplen 262145"
pcapfix also warns about wrong packet length if bigger than same value
(defined as PCAP_MAX_SNAPLEN there).
MAXIMUM_SPANPLEN is defined in tcpdump's netdissect.h and libpcap's
pcap-int.h. It is also defined as WTAP_MAX_PACKET_SIZE in
wireshark/wiretap/wtap.h (this one being the only publicly available).
Change-Id: Ib7449d5aba9da342c150704ebd0e1f09e7f7276c
This allows the user to change the configuration between either using
a) the classic OsmoPCAP protocol (over TCP with or without TLS)
which is used when you want to talk to an osmo-pcap-server
b) the (new) IPIP encapsulation, which will simply take the IP
packet (without Ethernet or pcap header) and transmit it inside IPIP
to the specified server IP address. This is useful for gettin
real-time streaming into wireshark.
Change-Id: I8056fc163ac2f15adcb964d867dd5e51df4e4710
osmo-pcap for historical reasons uses the same port numbers as
OsmoPCU and OsmoBTS. This leads to problems when wanting to run related
software together on one system. Let's break the historical assumptions
and start with non-overlapping port numbers that are allocated/assigned
from https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers
Change-Id: I638ac0534517931d0987ce9f72f5db4f5b6c16b7
Modify the osmo_sock_init (code clone to be integrated upstream)
to allow binding to a specific source ip and source port. Allow
the source ip to be configured but allow the kernel to pick a
random port for us.
This is necessary for systems with multiple interfaces where the
default route is not necessarily the right one to connect to the
pcap server.
Change-Id: I84e728b0752213d28f970fcbbfd6565c441ccfeb
Allow to configure multiple servers and connect. Introduce a new VTY
node to allow multiple servers. Add an explicit connect. Do not put
the main connection into the same list but assume it exists.
Change-Id: I9448ad4a005dd7c7eb1c615d03e57d6cb058ae4d
Take out various fields into a new connection class. We will have the
option to connect to multiple servers.
Change-Id: I820176d133fbdb0240a16eb4e1a6d505e5c080c6
Make the priority configurable, load DH params, allow to specify
certificates or anonymous operations.
Change-Id: I8ec3c0f8e1ee2089e1b7dacd9de842260930032f
Using tls priority of NORMAL:+ANON-ECDH:+ANON-DH already allows a
client to connect to a server and protect the data using tls.
Generate the dh params on load (and do that for the client right
now as well) but that will go away soon.
Change-Id: Ifa2ad24c0a631573c259a3bf94b91a946ad9ec9d
We are only reading from the socket and never write but the osmo_tls
code is integrated with it. We will never write and the queue size is
set to 0. Simplify the read_cb.
Change-Id: I32335b1f7b7ed06b92c6222516c185301ce13781
Use GNUtls because it is GPL compatible and instead of mbedTLS seems
to have a working non-blocking I/O integration. GNUtls has various
issues that could not be resolved easily:
* Pick spdy as sub protocol
* gmt_time not randomized
* private key loaded to RAM (but not verified)
This is the beginning and not the end. Client support might need more
work with actual tls verification. Maybe more manual x509 cert
verification is needed and maybe client certs don't work at all. I try
to ignore renegotiation as I threw away the key.
Reload x509 creds and keys as they might have changed from one
connection to another.
Change-Id: I9128e14084da1fc2705f858393f98b8133996172
Add the basics for getting a picture what a client and the server
is doing. We need to create unique descriptions as the code is
working with names and not numbers for clients.
Change-Id: I4a9be5bdd815d280cccf0199efc2ca79fc77d393
Add more counters and start counting them when reading from the
PCAP library and when trying to write to the socket.
Change-Id: I52d3064a265b402ac849d8578a14f718156c0805
Count certain events that can help to understand what is going on.
This includes OOM, failure to queues.
Change-Id: I4a2dad32afb577822c7181d2813ea5a7e693c704
To allow easily extracting or streaming the data to an external
analysis system, zeromq can be configured (and reconfigured). The
system works as fire and forget and no loss detection is present.
A simple go based client application is provided to subscribe to
the publisher.
Change-Id: I4f3e6d675023a81b7d2ee19bf1f44a2be0ca003c
We might only want to centralize the data streams but handle the
data differently. This will be combined with an upcoming ZeroMQ
publisher feature to broadcast all events out.
Change-Id: I12c6bf16310820d882fa28c6930931650475e0bb
We need to convert the 64bit timeval on a 64bit userspace (or on
OpenBSD) into a 32bit truncated value for being able to write the
file. This means we have 2038 issue here?
The 2000 as a number is too small. Modern networks can have a
higher MTU (up to 9000). Take this number and assume there is
a big header in front of it.
Allow to inspect UDP messages and check for GPRS, NS, BSSGP
and then filter LLC frames. Parsing the vL datastructure with
the libpcap syntax is a pain. It could be done using BPF but
we do not want to use bpf asm to specify the entire ruleset.
I looked into using libepan/libwireshark but this has memory
issues and is painful too. So let's parse UDP, NS, BSSGP using
the info we already have. I tried a bit of editcap to generate
a bit of broken data. The length check might still be bad.
I used my crash_20100602.pcap file to count the LLC frames we
detect and compare that to wireshark it ended with the right
number.
pcap add-filter gprs
can be used to enable the new filtering option after the OS
has received the packet.
Fixes: ONW#1314
Pau Espin
Oliver Smith
Vadim Yanitskiy
Harald Welte
Holger Hans Peter Freyther