This member is deprcated/unused so simply remove it:
> 'is_config_node' is deprecated: Implicit parent node tracking has
> replaced the use of this callback. This callback is no longer called,
> ever, and can be left NULL.
Change-Id: I34295950557d9009b0d8d3378deb3b1263476f82
tall_ctr_ctx is only used by the obsolete osmo_counters which are not
used anymore.
tall_msgb_ctx is now set through msgb_tallox_ctx_init().
Fixes undefined reference errors since libosmocore.map was introduced in
I13169c00a59fb59513dfc598de5a71d094492422:
```
osmo-pcap/src/osmo_client_main.c:226: undefined reference to `tall_msgb_ctx'
/usr/bin/ld: osmo-pcap/src/osmo_client_main.c:226: undefined reference to `tall_msgb_ctx'
/usr/bin/ld: osmo-pcap/src/osmo_client_main.c:227: undefined reference to `tall_ctr_ctx'
/usr/bin/ld: osmo-pcap/src/osmo_client_main.c:227: undefined reference to `tall_ctr_ctx'
```
Change-Id: Idcbb96fd070f5ad20d3091ce886dc6130968538f
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
Having a length of 10 packets is too low, it can be filled easily under
high load or really bursty traffic, where the input path could be polled
multiple times while the output path (write socket poll) is not called.
Related: SYS#5921
Change-Id: I72babfcc31e12624f30c16450dafd988192148be
the spec.in files already stated so expicitly, since some files include
osmocom/gprs/*.h. Only some data types from there are used, so there's
no need in linking the lib. Even more, doing so makes the build fail
because there soft-linking symbols required to be implemented by
libosmogb are not implemented here.
Related: OS#5311
Change-Id: I9a8fa03cef1efc9fdaea65ee63ca9b3379993989
In case the config file specifies a vty bind address, we must read
it before we start the telnet server.
Change-Id: I44561754d4beaad5c74cb66994ca4ef38960ea78
Prior to this patch, you could configure 'bind 1.2.3.4' in the
config file, but the telnet interface still binds to 127.0.0.1.
Change-Id: I9b86b2cf6949917c55ea15277619cfa2b745185d
A non-blocking STREAM socket connect() will mark the socket as
write-able once the connection succeeds. However, as we first
call osmo_fd_setup() and then osmo_sock_init2_ofd(), the latter
will force the 'when' to OSMO_FD_READ and hence the write callback
will not be called.
Change-Id: I44c484b48966a985a9b85fb16122a17df5666bc1
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Fixes: OS#4865
Change-Id: I39367aa480445fe961dcfa308789b3fc0cf759a1
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: I2e1ab7005514f1a06cac03e967aa5c8ea472e671
Related: OS#4138
On (at least) Debian unstable I'm seeing the following compiler
warninig:
/usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
Apparently this was deprecated in glibc 2.20 released in 2014 (!)
Change-Id: I826189dec4107e7c3e8cf4c013316ef3014b7857
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
The '.' is illegal character in counter names, as they are exported
via CTRL interface, where '.' has a special meaning that cannot be
used by strings comprising the variable name.
Change-Id: Icec5338d3242137980fa05d2c7ae2db940afb542
According to pcap.h, type bpf_u_int32 can be 32 bits on some systems,
so better cast explicitly to size_t to make sure always correct size is
used by log function.
Fixes warning:
osmo-pcap/src/osmo_client_network.c:175:4: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 7 has type ‘bpf_u_int32’ {aka ‘unsigned int’} [-Wformat=]
"Capture len too big %zu\n", in_hdr->caplen);
^~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Change-Id: I98654da143218d3e57da4e57781252eb3d3f3d5b
Fixes following compilation warning:
osmo-pcap/src/osmo_client_vty.c:511:2: warning: ‘install_default’ is deprecated: Now happens implicitly with install_node() [-Wdeprecated-declarations]
Depends: libosmocore I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I943f68dbafd7906313ad9e59f4adb289ae23cdec
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
We can simplify the code even further by using the osmo_fd version
of osmo_sock_init2() called osmo_sock_init2_ofd(), which takes care
of filling the osmo_fd.fd member and registering the socket in the
select loop.
Change-Id: Ibf1480e7dee287db77a19bb9f0254edddf7706ab
A related function for "create a socket, bind it locally and connect
remotely" has meanwhile been introduced in libosmocore, so the local
implementation can go.
Change-Id: Ieda77ad8b3f7b89faa09882c0037562ce4d0fc89
This naming is more in line with what all the other osmocom programs are
doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't
generally use osmo_ anywhere else, so I suggest to change it for more
uniformity.
Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1
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
src_result is only valid "if (src)", so we cannot unconditionally
free it:
(gdb) bt
host=0x52 <error: Cannot access memory at address 0x52>, src=0x0)
at /usr/src/debug/osmo-pcap/0.0.6+gitrAUTOINC+4776b2972e-r1d/git/src/osmo_client_network.c:165
Change-Id: I3b6778d9110583ecb1daec59ef2c86465d5818b9
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
When not running as root the opening might fail and then we would
crash when sending the link information. Do not crash. This could
have crashed before the re-factoring but due the async connect it
seems more likely we hit it now.
Change-Id: I26a10c401a9a8998acc50a4bd4432d2ac7fceaeb
With the VTY a user can write connect, connect, connect and this
would lead to leaking fds. Always close the connection.
Change-Id: Iab94dc2fd28496bf5fd8ceb5611f9e6505ccae1b