Skip to content

Loading builds...

Changes

#2358 (Feb 19, 2026, 11:41:46 AM)

Bump version: 1.12.0.73-10f3 → 1.13.0

Change-Id: I877d255890a525a34fbf89101b3ff0bbd0989c87
Pau Espin Pedrol at

#2357 (Feb 9, 2026, 2:25:04 PM)

logging: Support nonblocking-io for log target stderr & file, make it default

The nonblocking-io used to be the mode used until recently, where wq
only was used if the write buffer was full.
This is more performant that always waiting for poll() to write, plus
the fact that we write to system synchronously, hence seeing output
immediatelly or not losing it if program crashes.
Furthermore, It turns out using wq in multithreaded programs may cause
problems, so better switch back to using nonblocking-io by default.

Related: OS#6947
Change-Id: I46420f4b174d3a9ed01e993e2e89aea3b46c0dd7
Pau Espin Pedrol at

#2356 (Feb 9, 2026, 1:34:03 PM)

logging: Support nonblocking-io for log target stderr & file, make it default

The nonblocking-io used to be the mode used until recently, where wq
only was used if the write buffer was full.
This is more performant that always waiting for poll() to write, plus
the fact that we write to system synchronously, hence seeing output
immediatelly or not losing it if program crashes.
Furthermore, It turns out using wq in multithreaded programs may cause
problems, so better switch back to using nonblocking-io by default.

Related: OS#6947
Change-Id: I46420f4b174d3a9ed01e993e2e89aea3b46c0dd7
Pau Espin Pedrol at

#2355 (Feb 9, 2026, 1:00:33 PM)

logging: Support nonblocking-io for log target stderr & file, make it default

The nonblocking-io used to be the mode used until recently, where wq
only was used if the write buffer was full.
This is more performant that always waiting for poll() to write, plus
the fact that we write to system synchronously, hence seeing output
immediatelly or not losing it if program crashes.
Furthermore, It turns out using wq in multithreaded programs may cause
problems, so better switch back to using nonblocking-io by default.

Related: OS#6947
Change-Id: I46420f4b174d3a9ed01e993e2e89aea3b46c0dd7
Pau Espin Pedrol at

#2354 (Feb 9, 2026, 11:58:33 AM)

logging: Fix print tid value in multithreadded programs

Change-Id: I363751ab1368d916aad8905b056ec4f9d62b7175
Pau Espin Pedrol at

#2353 (Feb 9, 2026, 11:36:08 AM)

osmo_io_uring: Split global init from per-thread init

osmo_iofd_init() is expected to be called per-thread, while some code in
osmo_iofd_uring_init() was only expected to be called once.

Change-Id: Ifa5c46d7532ea49869f3cfe7268fdd082906fd10
Pau Espin Pedrol at

#2352 (Feb 9, 2026, 11:36:08 AM)

osmo_io: Lazy-initialize during osmo_iofd_setup()

This way new threads (!=main) don't need to explicitly call
osmo_iofd_init() explicitly before using osmo_io. This is specially
useful for threads using osmo_io indirectly, eg, when logging.

The osmo_iofd_setup() API is really the only main API which requires
initialization. All other APIs requiring it come after osmo_iofd_setup()
since they use an osmo_iofd pointer.

Change-Id: Ia543c1b9d111c929cd9dbed266b6d21b74e47e4b
Pau Espin Pedrol at

#2351 (Feb 9, 2026, 11:03:58 AM)

osmo_io: Move function declaration to internal header

Change-Id: I25ffb94e00225bcdc565f56a3f0f7834df00e974
Pau Espin Pedrol at

#2350 (Feb 4, 2026, 11:15:03 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2349 (Feb 3, 2026, 7:19:19 PM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2348 (Feb 3, 2026, 6:28:45 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2347 (Feb 2, 2026, 9:03:34 AM)

vty: Use osmo_fd_{write,read}_enable() API helper

Change-Id: Icba439fb33a29626ffce9ca1d61d30e88426f526
Pau Espin Pedrol at

#2346 (Jan 30, 2026, 2:31:16 PM)

osmo_io: Remove outdated comment in API doc of osmo_iofd_set_io_buffers()

Multiple iov buffers are supported in poll backend since
4272cd46b1e5b264e6f6b65d38bcb08e3a139a9e.

Related: OS#6705
Change-Id: I9b75f3597081c6cd7e24f75f0e289b93edb3aa86
Pau Espin Pedrol at

#2345 (Jan 30, 2026, 2:31:16 PM)

logging_file: Request up to 8 iofd write buffers if available

This should help in decreasing latency between submitting a logging line
and getting it written to file. It should, for the same reason, optimize
CPU use.

Change-Id: Ia88b27948922d278e0f72fc2aac4b4ae88465b4d
Pau Espin Pedrol at

#2344 (Jan 30, 2026, 2:31:14 PM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2343 (Jan 30, 2026, 2:31:14 PM)

osmo_io: Allow fetching maximum value allowed by osmo_iofd_set_io_buffers()

Before this patch, there's no way for a user of the API to know whether
a requested buffers value is actually going to be accepted or not.

Change-Id: Id3d8413c119eb3d9b60aa068295a59561236938c
Pau Espin Pedrol at

#2342 (Jan 30, 2026, 2:31:13 PM)

Use same queue length for gsmtap_log and gsmtap_file

Take the chance to also deduplicate MAX_LOG_SIZE.

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2341 (Jan 30, 2026, 2:03:56 PM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2340 (Jan 30, 2026, 2:03:56 PM)

Use same queue length for gsmtap_log and gsmtap_file

Take the chance to also deduplicate MAX_LOG_SIZE.

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2339 (Jan 30, 2026, 2:03:56 PM)

osmo_io: Introduce API osmo_iofd_get_txqueue_max_length()

Change-Id: I92526aa554fc87734fae3fac0ad650d17bf52bb5
Pau Espin Pedrol at

#2338 (Jan 30, 2026, 2:03:56 PM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2337 (Jan 30, 2026, 1:51:20 PM)

Use same queue length for gsmtap_log and gsmtap_file

Take the chance to also deduplicate MAX_LOG_SIZE.

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2336 (Jan 30, 2026, 1:51:20 PM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2335 (Jan 30, 2026, 1:51:20 PM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2334 (Jan 30, 2026, 1:51:20 PM)

logging: Also Avoid infinite loop/deadlock in log_check_level()

A LOG() macro being called inside an already-logging path will first
call log_check_level() before calling osmo_vlogp(). Since calling
happens with the mutex hold, it has been seen to deadlock in eg.
osmo-hnbgw.

Change-Id: I0098629b335b3aa174b49fd79c33d22b04bc4785
Pau Espin Pedrol at

#2333 (Jan 30, 2026, 1:50:39 PM)

Use same queue length for gsmtap_log and gsmtap_file

Take the chance to also deduplicate MAX_LOG_SIZE.

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2332 (Jan 30, 2026, 1:50:39 PM)

logging: Also Avoid infinite loop/deadlock in log_check_level()

A LOG() macro being called inside an already-logging path will first
call log_check_level() before calling osmo_vlogp(). Since calling
happens with the mutex hold, it has been seen to deadlock in eg.
osmo-hnbgw.

Change-Id: I0098629b335b3aa174b49fd79c33d22b04bc4785
Pau Espin Pedrol at

#2331 (Jan 30, 2026, 1:50:39 PM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2330 (Jan 30, 2026, 1:50:34 PM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2329 (Jan 30, 2026, 1:22:53 PM)

vty: Use osmo_fd_{write,read}_enable() API helper

Change-Id: Icba439fb33a29626ffce9ca1d61d30e88426f526
Pau Espin Pedrol at

#2328 (Jan 30, 2026, 11:28:22 AM)

Fix 'logging: Avoid infinite loop logging inside logging path'

I didn't see the early return of log_cache_check(), which should leave
the logging_active variable as true forever.

Fixes: bc400626b28c85fe0f52ce25947a90650b0d06b5
Change-Id: I13ed182688597c7da279a50bf057eff6d13f0867
Pau Espin Pedrol at

#2327 (Jan 30, 2026, 9:43:54 AM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2326 (Jan 30, 2026, 9:43:54 AM)

Use same queue length for gsmtap_log and gsmtap_file

Take the chance to also deduplicate MAX_LOG_SIZE.

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2325 (Jan 30, 2026, 9:43:54 AM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2324 (Jan 30, 2026, 9:43:53 AM)

logging: Avoid infinite loop logging inside logging path

If eg. gsmtap_log target is requested to log a message but the iofd
wqueue is full, it may try to log an error message, which will create an
infinite stack loop.

Change-Id: If3b8c0ee97537242162558fdd1c99f03b32af811
Pau Espin Pedrol at

#2323 (Jan 29, 2026, 11:20:41 AM)

Use same queue length for gsmtap_log and gsmtap_file

Take the chance to also deduplicate MAX_LOG_SIZE.

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2322 (Jan 29, 2026, 11:17:36 AM)

Use same queue length for gsmtap_log and gsmtap_file

Change-Id: I3772d291f97626ee325731f3515a5110eda70d3d
Pau Espin Pedrol at

#2321 (Jan 29, 2026, 11:02:15 AM)

stats_tcp.c: Remove unneeded EMBEDDED check

The HAVE_LINUX_TCP define check should be enough.

Change-Id: I68cb49925aa49ad97b266638d41f38c22fc32000
Pau Espin Pedrol at

#2320 (Jan 29, 2026, 11:00:55 AM)

logging_file: Avoid reopening file for stderr

target->tgt_file.fname is NULL for stderr log target.

Change-Id: I4a551b0c434c480e78852a0a4873700eac2f5853
Pau Espin Pedrol at

#2319 (Jan 29, 2026, 11:00:55 AM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2318 (Jan 29, 2026, 11:00:54 AM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2317 (Jan 29, 2026, 11:00:54 AM)

logging: Avoid infinite loop logging inside logging path

If eg. gsmtap_log target is requested to log a message but the iofd
wqueue is full, it may try to log an error message, which will create an
infinite stack loop.

Change-Id: If3b8c0ee97537242162558fdd1c99f03b32af811
Pau Espin Pedrol at

#2316 (Jan 29, 2026, 11:00:53 AM)

logging_file: Fix log_target_file_switch_to_stream on stderr

In stderr log target, the bfd of the wq was left registered despite
freeing the wq, which ended up in the callback being called and the
freed wq being used.

Change-Id: I1c0d833fb8ae82d1dd54e44cc2fc8be80d5e1b4b
Pau Espin Pedrol at

#2315 (Jan 29, 2026, 10:53:23 AM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2314 (Jan 29, 2026, 10:53:23 AM)

logging: Avoid infinite loop logging inside logging path

If eg. gsmtap_log target is requested to log a message but the iofd
wqueue is full, it may try to log an error message, which will create an
infinite stack loop.

Change-Id: If3b8c0ee97537242162558fdd1c99f03b32af811
Pau Espin Pedrol at

#2313 (Jan 29, 2026, 10:38:48 AM)

core: always build tun.c and gate TUN support by headers

Always build tun.c and move platform-specific checks into the
implementation.

Guard the TUN-specific code paths based on the availability of
linux/if_tun.h detected at configure time. If TUN support is not
available, osmo_tundev_open() returns -ENOTSUP.

This keeps the public TUN API available while disabling unsupported
functionality in a capability-based way.

Change-Id: I6d1ea1644d12ef59a54cf2f73b9155def58b17a9
dtv.comp at

#2312 (Jan 29, 2026, 9:47:37 AM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2311 (Jan 29, 2026, 9:47:37 AM)

logging_file: Fix log_target_file_switch_to_stream on stderr

In stderr log target, the bfd of the wq was left registered despite
freeing the wq, which ended up in the callback being called and the
freed wq being used.

Change-Id: I1c0d833fb8ae82d1dd54e44cc2fc8be80d5e1b4b
Pau Espin Pedrol at

#2310 (Jan 28, 2026, 5:17:21 PM)

logging_file: Clean log_target_file_reopen()

Move specific assert for wq further below.
Do early return to get rid of extra indentation.

Change-Id: Ibcb50320ad80b034115cccc3b7ab90501ac1d091
Pau Espin Pedrol at

#2309 (Jan 28, 2026, 5:17:21 PM)

Implement log file target using osmo_io

Reuse (struct log_target)->tgt_file->wqueue->except_cb to store the iofd
pointer internally, since we are not allowed to change the struct
log_target because it's public and we don't want to break the ABI.
Using the wqueue except_cb is fine since that field was never used.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2308 (Jan 28, 2026, 4:49:46 PM)

logging_file: Avoid reopning file for stderr

target->tgt_file.fname is NULL for stderr log target.

Change-Id: I4a551b0c434c480e78852a0a4873700eac2f5853
Pau Espin Pedrol at

#2307 (Jan 27, 2026, 11:09:50 AM)

osmo_io: Fix misaligment of iofd->cmsg used as struct cmsghdr

Fixes following ASAN runtime error:
"""
src/stream.c:398:47: runtime error: member access within misaligned address 0x516000012b81 for type 'struct cmsghdr', which requires 8 byte alignment
0x516000012b81: note: pointer points here
51 00 00  00 30 00 00 00 00 00 00  00 84 00 00 00 01 00 00  00 00 00 00 00 00 00 00  00 00 00 00 03
              ^
"""

Current GCC documentation [1] states that __attribute__ ((__aligned__
(alignment))) is the older sytnax. The newer _Alignas mimics the
standarized alignas() in C23. Since we build with CLAGS=-std=gnu11 we
are fine using _Alignas, which was introduced in C11.

[1] https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Type-Alignment.html

Related: OS#6905
Change-Id: Ia80dfc4dbffe85514b18dcf8d36b85bfafd76d64
Pau Espin Pedrol at

#2306 (Jan 27, 2026, 10:14:45 AM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2305 (Jan 27, 2026, 10:14:45 AM)

Implement log file target using osmo_io

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2304 (Jan 26, 2026, 3:17:25 PM)

osmo_io: Fix misaligment of iofd->cmsg used as struct cmsghdr

Fixes following ASAN runtime error:
"""
src/stream.c:398:47: runtime error: member access within misaligned address 0x516000012b81 for type 'struct cmsghdr', which requires 8 byte alignment
0x516000012b81: note: pointer points here
51 00 00  00 30 00 00 00 00 00 00  00 84 00 00 00 01 00 00  00 00 00 00 00 00 00 00  00 00 00 00 03
              ^
"""

Related: OS#6905
Change-Id: Ia80dfc4dbffe85514b18dcf8d36b85bfafd76d64
Pau Espin Pedrol at

#2303 (Jan 26, 2026, 11:29:23 AM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2302 (Jan 26, 2026, 11:28:55 AM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2301 (Jan 26, 2026, 11:08:02 AM)

Implement log file target using osmo_io

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2300 (Jan 26, 2026, 11:05:04 AM)

osmo_io.h: Avoid including sys/socket.h

sys/socket.h may not always be available (eg. arm-none-eabi toolchain).
In the header file we only really need the forward declaration of struct
msghdr, so simply do that.

Change-Id: I5bcba8f72a2be6161d7782a3100d25a7025341d0
Pau Espin Pedrol at

#2299 (Jan 26, 2026, 11:02:54 AM)

core: guard TCP stats on availability of linux/tcp.h

Detect availability of linux/tcp.h at configure time
and build TCP statistics code conditionally based on that.

This replaces platform-specific conditionals with proper feature checks
and avoids build failures on systems lacking Linux TCP headers or types
(e.g. non-Linux or cross-build environments).

When TCP_INFO support is unavailable, the public API remains unchanged,
but all related functions return -ENOTSUP.

No functional changes on systems where linux/tcp.h are available.

Change-Id: Ibcd00f15131b0291f0b10eca51401c518b77cc39
dtv.comp at

#2298 (Jan 26, 2026, 10:27:33 AM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2297 (Jan 26, 2026, 10:20:13 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2296 (Jan 26, 2026, 10:20:13 AM)

core: guard Linux netlink headers by libmnl usage

Only include Linux-specific netlink headers when the libmnl backend
is enabled.

The code paths requiring <linux/if_link.h> and <linux/rtnetlink.h>
are entirely guarded by ENABLE_LIBMNL conditionals, so the headers should
not be included unconditionally.

This avoids pulling in Linux-only headers when the corresponding
backend is not built.

Change-Id: I0b681deb1f1e025e3ea9996f19b1de06a5feb408
dtv.comp at

#2295 (Jan 26, 2026, 10:16:37 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2294 (Jan 26, 2026, 10:16:37 AM)

core: guard Linux netlink headers by libmnl usage

Only include Linux-specific netlink headers when the libmnl backend
is enabled.

The code paths requiring <linux/if_link.h> and <linux/rtnetlink.h>
are entirely guarded by ENABLE_LIBMNL conditionals, so the headers should
not be included unconditionally.

This avoids pulling in Linux-only headers when the corresponding
backend is not built.

Change-Id: I0b681deb1f1e025e3ea9996f19b1de06a5feb408
dtv.comp at

#2293 (Jan 26, 2026, 10:13:23 AM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2292 (Jan 26, 2026, 10:01:45 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2291 (Jan 26, 2026, 10:01:45 AM)

core: guard TCP stats on availability of linux/tcp.h

Detect availability of linux/tcp.h at configure time
and build TCP statistics code conditionally based on that.

This replaces platform-specific conditionals with proper feature checks
and avoids build failures on systems lacking Linux TCP headers or types
(e.g. non-Linux or cross-build environments).

When TCP_INFO support is unavailable, the public API remains unchanged,
but all related functions return -ENOTSUP.

No functional changes on systems where linux/tcp.h are available.

Change-Id: Ibcd00f15131b0291f0b10eca51401c518b77cc39
dtv.comp at

#2290 (Jan 26, 2026, 10:01:45 AM)

core: guard Linux netlink headers by libmnl usage

Only include Linux-specific netlink headers when the libmnl backend
is enabled.

The code paths requiring <linux/if_link.h> and <linux/rtnetlink.h>
are entirely guarded by ENABLE_LIBMNL conditionals, so the headers should
not be included unconditionally.

This avoids pulling in Linux-only headers when the corresponding
backend is not built.

Change-Id: I0b681deb1f1e025e3ea9996f19b1de06a5feb408
dtv.comp at

#2289 (Jan 26, 2026, 10:01:44 AM)

core: always build tun.c and gate TUN support by headers

Always build tun.c and move platform-specific checks into the
implementation.

Guard the TUN-specific code paths based on the availability of
linux/if_tun.h detected at configure time. If TUN support is not
available, osmo_tundev_open() returns -ENOTSUP.

This keeps the public TUN API available while disabling unsupported
functionality in a capability-based way.

Change-Id: I6d1ea1644d12ef59a54cf2f73b9155def58b17a9
dtv.comp at

#2288 (Jan 26, 2026, 9:02:36 AM)

socket.h: Include netinet/in.h instead of arpa/inet.h

In socket.h we are mainly interested in netinet/int.h, since that's the
one defining INET_ADDRSTRLEN, struct sockaddr_in, struct in_addr, ec.

Header arpa/inet.h usually defines several functions which use those,
like htonl(), inet_ntop(), etc.

See POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/arpa_inet.h.html#tag_13_03
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netinet_in.h.html

Change-Id: I03919c4adc962bbcfabc9030c6f12c0e10ff060c
Pau Espin Pedrol at

#2287 (Jan 26, 2026, 9:02:35 AM)

remove references to define EMBEDDED in public headers

It's not a good idea to base opt-in/out of code in public headers based
on some specific non-standard define being set at compile time when
calling the compiler. Get rid of those references; Now that
osmocom/core/socket.h can be included thanks to improved
osmocom/core/socket_compat.h, it shouldn't be a problem.

Change-Id: I7a657d67077dfbe861959c6123eb9163bc791694
Pau Espin Pedrol at

#2286 (Jan 26, 2026, 9:02:35 AM)

configure.ac: Add arpa/inet.h to AC_CHECK_HEADERS

We use arpa/inet.h in several places in the code, so it's good to look
up for presence even if it's only to debug toolchain compatibility.

Change-Id: Ib2d1fb3efb1dcb429b511698691249c257e00720
Pau Espin Pedrol at

#2285 (Jan 26, 2026, 9:02:34 AM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2284 (Jan 26, 2026, 9:02:34 AM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2283 (Jan 26, 2026, 9:02:33 AM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2282 (Jan 26, 2026, 9:02:32 AM)

osmo_io.h: Avoid including sys/socket.h

sys/socket.h may not always be available (eg. arm-none-eabi toolchain).
In the header file we only really need the forward declaration of struct
msghdr, so simply do that.

Change-Id: I5bcba8f72a2be6161d7782a3100d25a7025341d0
Pau Espin Pedrol at

#2281 (Jan 26, 2026, 9:02:32 AM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2280 (Jan 26, 2026, 8:50:38 AM)

osmo_io: Add assert to validate inconditional

The do-while loop is entered:
* First time: "tail_msg != NULL" (since it was set to "msg").
* Subsequent times: coming from "while" condition:
** tail_msg != NULL
** res == IOFD_SEG_ACT_HANDLE_MORE, which means iofd->pending != NULL.

Hence, always either "iofd->pending" or "tail_msg" is valid when entering
the loop, and hence "msg" will also be valid.

Related: Coverity CID#557196
Change-Id: If29363edfba576370e306fb5b160d9f038018130
Pau Espin Pedrol at

#2279 (Jan 25, 2026, 6:44:56 PM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2278 (Jan 25, 2026, 6:44:55 PM)

core: always build tun.c and gate TUN support by headers

Always build tun.c and move platform-specific checks into the
implementation.

Guard the TUN-specific code paths based on the availability of
linux/if_tun.h detected at configure time. If TUN support is not
available, osmo_tundev_open() returns -ENOTSUP.

This keeps the public TUN API available while disabling unsupported
functionality in a capability-based way.

Change-Id: I6d1ea1644d12ef59a54cf2f73b9155def58b17a9
dtv.comp at

#2277 (Jan 25, 2026, 6:44:54 PM)

core: guard TCP stats on availability of linux/tcp.h

Detect availability of linux/tcp.h at configure time
and build TCP statistics code conditionally based on that.

This replaces platform-specific conditionals with proper feature checks
and avoids build failures on systems lacking Linux TCP headers or types
(e.g. non-Linux or cross-build environments).

When TCP_INFO support is unavailable, the public API remains unchanged,
but all related functions return -ENOTSUP.

No functional changes on systems where linux/tcp.h are available.

Change-Id: Ibcd00f15131b0291f0b10eca51401c518b77cc39
dtv.comp at

#2276 (Jan 25, 2026, 6:44:53 PM)

vty: guard definition of _XOPEN_SOURCE

Define _XOPEN_SOURCE only if it is not already provided by the build
environment.

This avoids redefinition warnings/errors while ensuring required POSIX
interfaces are available.

Change-Id: I4f53aff1afef02abce7cb70d1b29080ba900ff41
dtv.comp at

#2275 (Jan 25, 2026, 6:44:50 PM)

core: fix printf format casts for struct timeval fields

Explicitly cast struct timeval fields to long when passing them to
printf-style functions.

This avoids compiler warnings/errors on platforms where tv_sec or
tv_usec are not exactly of type long, while keeping the existing log
and control output unchanged.

Change-Id: Icac9e392c728948a7976970658e37f5e0da41709
dtv.comp at

#2274 (Jan 25, 2026, 6:44:49 PM)

core: remove SCTP include from osmo_io_internal.h

No functional changes intended.

Change-Id: Icd626d908192a954d55d76a46d7cc863ed332631
dtv.comp at

#2273 (Jan 25, 2026, 6:44:43 PM)

build: keep netns API public and gate features with HAVE_*

The netns API was previously guarded by platform-specific preprocessor
conditions (e.g. !EMBEDDED and defined(__linux__)), which caused the
netns headers and implementation to be entirely excluded from non-Linux
builds such as Emscripten. This in turn led to build failures in code
depending on the netns API, as the symbols and declarations were not
available at all.

Always build netns.c and keep the public declarations available
for non-embedded builds. Move platform/feature conditionals into the
implementation: guard the netns code paths with HAVE_SETNS/HAVE_UNSHARE/
HAVE_MOUNT and HAVE_CLONE_NEWNET, and return -ENOTSUP when the required
functionality is not available.

Add configure-time checks for the required headers/functions and for the
CLONE_NEWNET declaration, defining the
corresponding HAVE_* macros.

No functional changes intended for platforms where netns is available.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2272 (Jan 23, 2026, 9:47:10 PM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2271 (Jan 23, 2026, 9:47:10 PM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2270 (Jan 23, 2026, 9:47:10 PM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2269 (Jan 23, 2026, 5:46:32 PM)

remove references to define EMBEDDED in public headers

It's not a good idea to base opt-in/out of code in public headers based
on some specific non-standard define being set at compile time when
calling the compiler. Get rid of those references; Now that
osmocom/core/socket.h can be included thanks to improved
osmocom/core/socket_compat.h, it shouldn't be a problem.

Change-Id: I7a657d67077dfbe861959c6123eb9163bc791694
Pau Espin Pedrol at

#2268 (Jan 23, 2026, 5:30:37 PM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2267 (Jan 23, 2026, 5:30:37 PM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2266 (Jan 23, 2026, 5:30:37 PM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2265 (Jan 23, 2026, 5:30:37 PM)

socket.h: Include netinet/in.h instead of arpa/inet.h

In socket.h we are mainly interested in netinet/int.h, since that's the
one defining INET_ADDRSTRLEN, struct sockaddr_in, struct in_addr, ec.

Header arpa/inet.h usually defines several functions which use those,
like htonl(), inet_ntop(), etc.

See POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/arpa_inet.h.html#tag_13_03
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netinet_in.h.html

Change-Id: I03919c4adc962bbcfabc9030c6f12c0e10ff060c
Pau Espin Pedrol at

#2264 (Jan 23, 2026, 5:30:37 PM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2263 (Jan 23, 2026, 5:30:37 PM)

configure.ac: Add arpa/inet.h to AC_CHECK_HEADERS

We use arpa/inet.h in several places in the code, so it's good to look
up for presence even if it's only to debug toolchain compatibility.

Change-Id: Ib2d1fb3efb1dcb429b511698691249c257e00720
Pau Espin Pedrol at

#2262 (Jan 23, 2026, 5:24:12 PM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2261 (Jan 23, 2026, 5:22:02 PM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2260 (Jan 23, 2026, 5:15:01 PM)

socket_compat.h improvements to always have struct osmo_sockaddr available

Having a #if (!EMBEDDED) based on compiler defined variable is not a
good idea. Instead, add minimal sys/socket.h and netient/in.h to always
have the definition of struct osmo_sockaddr available.

Change-Id: I5b10e09770727c72812af15360ab3385b957509b
Pau Espin Pedrol at

#2259 (Jan 23, 2026, 4:39:27 PM)

configure.ac: Add arpa/inet.h to AC_CHECK_HEADERS

We use arpa/inet.h in several places in the code, so it's good to look
up for presence even if it's only to debug toolchain compatibility.

Change-Id: Ib2d1fb3efb1dcb429b511698691249c257e00720
Pau Espin Pedrol at

#2258 (Jan 23, 2026, 4:37:05 PM)

socket.h: Include netinet/in.h instead of arpa/inet.h

In socket.h we are mainly interested in netinet/int.h, since that's the
one defining INET_ADDRSTRLEN, struct sockaddr_in, struct in_addr, ec.

Header arpa/inet.h usually defines several functions which use those,
like htonl(), inet_ntop(), etc.

See POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/arpa_inet.h.html#tag_13_03
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/netinet_in.h.html

Change-Id: I03919c4adc962bbcfabc9030c6f12c0e10ff060c
Pau Espin Pedrol at

#2257 (Jan 23, 2026, 4:03:25 PM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2256 (Jan 23, 2026, 4:03:25 PM)

osmo_io.h: add forward declaration of struct osmo_sockaddr

During amr-none-eabi build (EMBEDDED defined), including
<osmocom/core/socket.h> includes a mostly empty file, since that file is
guarded by "#if (!EMBEDDED)" because sys/socket.h is not available
there. As a result, if somebody includes osmo_io.h when EMBEDDED is set,
there will be no declaration of struct osmo_sockaddr used in declared
APIs. Add a forward declaration to fix it.

Furthermore, the EMBEDDED check in osmocom/core/socket.h is actually
broken because it's in a header file which cannot include "config.h", so
also avoid including osocom/core/socket.h altogether in order to avoid
it in turn including arpa/inet.h which is not available in the
arm-none-eabi toolchain.

Change-Id: Id7db4b081752a1034b95a92b4850484a26ec11c6
Pau Espin Pedrol at

#2255 (Jan 23, 2026, 4:03:24 PM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2254 (Jan 23, 2026, 4:03:24 PM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2253 (Jan 23, 2026, 3:52:34 PM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2252 (Jan 23, 2026, 3:52:34 PM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2251 (Jan 23, 2026, 3:52:34 PM)

osmo_io.h: add forward declaration of struct osmo_sockaddr

During amr-none-eabi build (EMBEDDED defined), including
<osmocom/core/socket.h> includes a mostly empty file, since that file is
guarded by "#if (!EMBEDDED)" because sys/socket.h is not available
there. As a result, if somebody includes osmo_io.h when EMBEDDED is set,
there will be no declaration of struct osmo_sockaddr used in declared
APIs. Add a forward declaration to fix it.

Change-Id: Id7db4b081752a1034b95a92b4850484a26ec11c6
Pau Espin Pedrol at

#2250 (Jan 23, 2026, 3:52:34 PM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2249 (Jan 23, 2026, 3:23:36 PM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2248 (Jan 23, 2026, 3:23:34 PM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2247 (Jan 23, 2026, 3:23:34 PM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2246 (Jan 23, 2026, 3:09:04 PM)

osmo_io.h: Avoid including sys/socket.h

sys/socket.h may not always be available (eg. arm-none-eabi toolchain).
In the header file we only really need the forward declaration of struct
msghdr, so simply do that.

Change-Id: I5bcba8f72a2be6161d7782a3100d25a7025341d0
Pau Espin Pedrol at

#2245 (Jan 23, 2026, 2:59:44 PM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2244 (Jan 23, 2026, 10:58:19 AM)

logging: Make struct log_context and struct log_target private

Change-Id: Iecbd07995ccb465a44be0debcc97458b2b240a0e
Pau Espin Pedrol at

#2243 (Jan 23, 2026, 10:58:19 AM)

logging: Move log target file to its own file

We already have all other log_target implementations each on its own
file. Move the file (and stderr, a specific case of file) into its own
file too, properly separating most file-specific logic from general
logging logic.

Change-Id: I8e32e31c75b66ff0649d92c2f469f8895689fbad
Pau Espin Pedrol at

#2242 (Jan 23, 2026, 10:58:17 AM)

Implement log file target using osmo_io

TODO: re-add talloc_pool.

Related: OS#6918
Change-Id: Ieb6420246454ef59442b1fd7b1d14e2c00fa69a5
Pau Espin Pedrol at

#2241 (Jan 23, 2026, 10:43:29 AM)

osmo_io: Support rx of segments up to ~UINT16_MAX

Previously if we recevied a big chunk (near UINT16_MAX), we would hit
the following assert in iofd_msgb_alloc2(), because our msgb
implementation can only handle sizes up to 16 bit length, counting
headroom + data length:
"OSMO_ASSERT(size + headroom <= 0xffff);".

This new improved logic allows handling segments of up to ~UINT16_MAX
which may come in in multiple read calls. It also adds logic to catch
received segments greater than UINT16_MAX (or buggy segment_cb or buggy
peer transmitting to us) and notifies the user of a broken stream
through read_cb() in that case.

test_segmentation_uint16_max() is added to osmo_io_test, which would
abort without this patch applied.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2240 (Jan 23, 2026, 10:43:29 AM)

osmo_io: Propagate segment_cb errors to the read_cb

Previous logic was to drop an entire msgb in the stream and pretend it
can continue working that way, which clearly makes no sense.
Instead, if segment_cb detects some problem (eg. buggy peer sending
corrupted data according to protocol), propagate the issue through
read_cb() so that the app can act on it, ie. most likely close the
connection.

Related: SYS#7842
Change-Id: I572e68df6799b903507229a9beee6fa7d7d6d652
Pau Espin Pedrol at

#2239 (Jan 23, 2026, 10:09:19 AM)

osmo_io: Propagate segment_cb errors to the read_cb

Previous logic was to drop an entire msgb in the stream and pretend it
can continue working that way, which clearly makes no sense.
Instead, if segment_cb detects some problem (eg. buggy peer sending
corrupted data according to protocol), propagate the issue through
read_cb() so that the app can act on it, ie. most likely close the
connection.

Related: SYS#7842
Change-Id: I572e68df6799b903507229a9beee6fa7d7d6d652
Pau Espin Pedrol at

#2238 (Jan 23, 2026, 10:09:18 AM)

osmo_io: Support rx of segments up to ~UINT16_MAX

Previously if we recevied a big chunk (near UINT16_MAX), we would hit
the following assert in iofd_msgb_alloc2(), because our msgb
implementation can only handle sizes up to 16 bit length, counting
headroom + data length:
"OSMO_ASSERT(size + headroom <= 0xffff);".

This new improved logic allows handling segments of up to ~UINT16_MAX
which may come in in multiple read calls. It also adds logic to catch
received segments greater than UINT16_MAX (or buggy segment_cb or buggy
peer transmitting to us) and notifies the user of a broken stream
through read_cb() in that case.

test_segmentation_uint16_max() is added to osmo_io_test, which would
abort without this patch applied.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2237 (Jan 23, 2026, 1:16:23 AM)

core: guard TCP stats on availability of linux/tcp.h and struct tcp_info

Detect availability of linux/tcp.h and struct tcp_info at configure time
and build TCP statistics code conditionally based on that.

This replaces platform-specific conditionals with proper feature checks
and avoids build failures on systems lacking Linux TCP headers or types
(e.g. non-Linux or cross-build environments).

When TCP_INFO support is unavailable, the TCP stats code is compiled out,
while keeping the public API intact.

No functional changes on systems where linux/tcp.h and struct tcp_info
are available.

Change-Id: Ibcd00f15131b0291f0b10eca51401c518b77cc39
dtv.comp at

#2236 (Jan 23, 2026, 1:16:23 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2235 (Jan 23, 2026, 1:16:22 AM)

core: fix printf format casts for struct timeval fields

Explicitly cast struct timeval fields to long when passing them to
printf-style functions.

This avoids compiler warnings/errors on platforms where tv_sec or
tv_usec are not exactly of type long, while keeping the existing log
and control output unchanged.

Change-Id: Icac9e392c728948a7976970658e37f5e0da41709
dtv.comp at

#2234 (Jan 23, 2026, 1:16:19 AM)

vty: guard definition of _XOPEN_SOURCE

Define _XOPEN_SOURCE only if it is not already provided by the build
environment.

This avoids redefinition warnings/errors while ensuring required POSIX
interfaces are available.

Change-Id: I4f53aff1afef02abce7cb70d1b29080ba900ff41
dtv.comp at

#2233 (Jan 22, 2026, 11:34:45 PM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2232 (Jan 22, 2026, 11:34:45 PM)

core: guard SCTP include in osmo_io_internal.h

Include <netinet/sctp.h> only when libsctp support is available.

This avoids pulling in SCTP-specific headers on builds where libsctp is
disabled or unavailable, while keeping the internal header usable across
all configurations.

No functional changes intended.

Change-Id: Icd626d908192a954d55d76a46d7cc863ed332631
dtv.comp at

#2231 (Jan 22, 2026, 11:14:05 PM)

build: keep netns API public and gate features with HAVE_*

The netns API was previously guarded by platform-specific preprocessor
conditions (e.g. !EMBEDDED and defined(__linux__)), which caused the
netns headers and implementation to be entirely excluded from non-Linux
builds such as Emscripten. This in turn led to build failures in code
depending on the netns API, as the symbols and declarations were not
available at all.

Always build netns.c and keep the public declarations available
for non-embedded builds. Move platform/feature conditionals into the
implementation: guard the netns code paths with HAVE_SETNS/HAVE_UNSHARE/
HAVE_MOUNT and HAVE_CLONE_NEWNET, and return -ENOSYS when the required
functionality is not available.

Add configure-time checks for the required headers/functions and for the
CLONE_NEWNET declaration, defining the
corresponding HAVE_* macros.

No functional changes intended for platforms where netns is available.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2230 (Jan 22, 2026, 11:14:05 PM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2229 (Jan 22, 2026, 4:00:15 PM)

build: keep netns API public and gate features with HAVE_*

The netns API was previously guarded by platform-specific preprocessor
conditions (e.g. !EMBEDDED and defined(__linux__)), which caused the
netns headers and implementation to be entirely excluded from non-Linux
builds such as Emscripten. This in turn led to build failures in code
depending on the netns API, as the symbols and declarations were not
available at all.

Always build netns.c and keep the public declarations available
for non-embedded builds. Move platform/feature conditionals into the
implementation: guard the netns code paths with HAVE_SETNS/HAVE_UNSHARE/
HAVE_MOUNT and HAVE_CLONE_NEWNET, and return -ENOSYS when the required
functionality is not available.

Add configure-time checks for the required headers/functions and for the
CLONE_NEWNET declaration, defining the
corresponding HAVE_* macros.

No functional changes intended for platforms where netns is available.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2228 (Jan 22, 2026, 4:00:14 PM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2227 (Jan 22, 2026, 3:27:59 PM)

osmo_io: Propagate segment_cb errors to the read_cb

Previous logic was to drop an entire msgb in the stream and pretend it
can continue working that way, which clearly makes no sense.
Instead, if segment_cb detects some problem (eg. buggy peer sending
corrupted data according to protocol), propagate the issue through
read_cb() so that the app can act on it, ie. most likely close the
connection.

Related: SYS#7842
Change-Id: I572e68df6799b903507229a9beee6fa7d7d6d652
Pau Espin Pedrol at

#2226 (Jan 22, 2026, 3:18:39 PM)

osmo_io: Support rx of segments up to ~UINT16_MAX

Previously if we recevied a big chunk (near UINT16_MAX), we would hit
the following assert in iofd_msgb_alloc2(), because our msgb
implementation can only handle sizes up to 16 bit length, counting
headroom + data length:
"OSMO_ASSERT(size + headroom <= 0xffff);".

This new improved logic allows handling segments of up to ~UINT16_MAX
which may come in in multiple read calls. It also adds logic to catch
received segments greater than UINT16_MAX (or buggy segment_cb or buggy
peer transmitting to us) and notifies the user of a broken stream
through read_cb() in that case.

test_segmentation_uint16_max() is added to osmo_io_test, which would
abort without this patch applied.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2225 (Jan 22, 2026, 3:18:39 PM)

osmo_io: Propagate segment_cb errors to the read_cb

Previous logic was to drop an entire msgb in the stream and pretend it
can continue working that way, which clearly makes no sense.
Instead, if segment_cb detects some problem (eg. buggy peer sending
corrupted data according to protocol), propagate the issue through
read_cb() so that the app can act on it, ie. most likely close the
connection.

Related: SYS#7842
Change-Id: I572e68df6799b903507229a9beee6fa7d7d6d652
Pau Espin Pedrol at

#2224 (Jan 22, 2026, 2:27:58 PM)

build: keep netns API public and gate features with HAVE_*

The netns API was previously guarded by platform-specific preprocessor
conditions (e.g. !EMBEDDED and defined(__linux__)), which caused the
netns headers and implementation to be entirely excluded from non-Linux
builds such as Emscripten. This in turn led to build failures in code
depending on the netns API, as the symbols and declarations were not
available at all.

Always build netns.c and keep the public declarations available
for non-embedded builds. Move platform/feature conditionals into the
implementation: guard the netns code paths with HAVE_SETNS/HAVE_UNSHARE/
HAVE_MOUNT and HAVE_CLONE_NEWNET, and return -ENOSYS when the required
functionality is not available.

Add configure-time checks for the required headers/functions and for the
CLONE_NEWNET declaration, defining the
corresponding HAVE_* macros.

No functional changes intended for platforms where netns is available.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2223 (Jan 22, 2026, 2:27:57 PM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2222 (Jan 22, 2026, 12:19:56 PM)

osmo_io: Reorder iofd_handle_segmented_read()

All other similar functions have first the int rc and later the struct
msgb; fix this one being different.

Change-Id: I88683334e77901776c806dad776ef46ea20b4480
Pau Espin Pedrol at

#2221 (Jan 22, 2026, 12:19:56 PM)

osmo_io: Propagate segment_cb errors to the read_cb

Previous logic was to drop an entire msgb in the stream and pretend it
can continue working that way, which clearly makes no sense.
Instead, if segment_cb detects some problem (eg. buggy peer sending
corrupted data according to protocol), propagate the issue through
read_cb() so that the app can act on it, ie. most likely close the
connection.

Related: SYS#7842
Change-Id: I572e68df6799b903507229a9beee6fa7d7d6d652
Pau Espin Pedrol at

#2220 (Jan 22, 2026, 12:19:56 PM)

osmo_io: Support rx of segments up to ~UINT16_MAX

Previously if we recevied a big chunk (near UINT16_MAX), we would hit
the following assert in iofd_msgb_alloc2(), because our msgb
implementation can only handle sizes up to 16 bit length, counting
headroom + data length:
"OSMO_ASSERT(size + headroom <= 0xffff);".

This new improved logic allows handling segments of up to ~UINT16_MAX
which may come in in multiple read calls. It also adds logic to catch
received segments greater than UINT16_MAX (or buggy segment_cb or buggy
peer transmitting to us) and notifies the user of a broken stream
through read_cb() in that case.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2219 (Jan 22, 2026, 12:19:56 PM)

osmo_io: Make iofd_handle_segmented_read() static

Change-Id: I6671380ad071e23445c3e38c0b9700af66998af1
Pau Espin Pedrol at

#2218 (Jan 22, 2026, 12:19:55 PM)

osmo_io: Assert osmo_iofd_set_alloc_info() params fit in a 16bit value

Related: SYS#7842
Change-Id: I32822574db8997a02bf18b71bf6ab596e726cb82
Pau Espin Pedrol at

#2217 (Jan 22, 2026, 11:16:31 AM)

build: detect netns support via configure-time capability checks

The netns API was previously guarded by platform-specific preprocessor
conditions (e.g. !EMBEDDED and defined(__linux__)), which caused the
netns headers and implementation to be entirely excluded from non-Linux
builds such as Emscripten. This in turn led to build failures in code
depending on the netns API, as the symbols and declarations were not
available at all.

Replace the hard-coded platform checks with explicit configure-time
capability detection. The build now checks for the concrete requirements
needed by netns and netdev support, including the availability of setns(), unshare(),
mount(), the CLONE_NEWNET macro and required headers.

Based on the result of these checks, USE_NETNS is defined and netns support
is either enabled or disabled in a controlled manner.

Netns and netdev support remains disabled for embedded builds.

No functional changes intended for platforms where netns is available.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2216 (Jan 22, 2026, 11:16:31 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2215 (Jan 22, 2026, 11:02:56 AM)

osmo_io: Propagate segment_cb errors to the read_cb

Change-Id: I572e68df6799b903507229a9beee6fa7d7d6d652
Pau Espin Pedrol at

#2214 (Jan 22, 2026, 10:55:56 AM)

osmo_io: Support rx of segments up to ~UINT16_MAX

Previously if we recevied a big chunk (near UINT16_MAX), we would hit
the following assert in iofd_msgb_alloc2(), because our msgb
implementation can only handle sizes up to 16 bit length, counting
headroom + data length:
"OSMO_ASSERT(size + headroom <= 0xffff);".

This new improved logic allows handling segments of up to ~UINT16_MAX
which may come in in multiple read calls. It also adds logic to catch
received segments greater than UINT16_MAX (or buggy segment_cb or buggy
peer transmitting to us) and notifies the user of a broken stream
through read_cb() in that case.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2213 (Jan 22, 2026, 10:45:30 AM)

Add Emscripten build support and JS callback logging backend

This change enables building libosmocore for sandboxed, non-POSIX
environments, specifically WebAssembly targets produced via the
Emscripten toolchain.

The broader motivation is to allow partial execution of selected
Osmocom components in isolated runtime environments where direct access
to hardware and traditional operating system facilities (filesystem,
sockets, privileged execution) is not available.

One intended use case is running a GSM 2G base station where the
radio-facing components are executed inside a web environment, while
the remaining Osmocom stack and core network components continue to run
unchanged on a conventional backend server. In this model, highly
stripped-down variants of osmo-bts and osmo-trx are built as static
WebAssembly libraries and executed in the browser, while depending on
core libraries such as libosmocore, libosmo-netif, and libosmo-abis.

A practical advantage of this approach is that no deployment or
privileged setup is required on the radio endpoint side. A user can
instantiate a radio endpoint with minimal configuration, while all
stateful logic and operational complexity remains centralized on the
backend. Multiple such radio endpoints may connect to the same backend
core network, effectively forming a single logical network from the
core network perspective, independent of the physical location of the
radio endpoints.

Existing libosmocore build logic and platform assumptions rely on the
availability of POSIX APIs and OS services which are not present in
WebAssembly runtimes. This currently prevents libosmocore from being
built for such targets without targeted, build-time adjustments. This
patch introduces the minimal set of changes required to enable such
builds, without affecting native platforms.

As part of this groundwork, a minimal callback-based logging hook is
introduced. When building for Emscripten, this hook allows forwarding
log messages to an external environment via a user-provided JavaScript
callback. This enables integration with browser-side logging or UI
infrastructure without introducing new logging backends or runtime
dependencies. For all other build targets, the hook resolves to a no-op
implementation and does not alter existing logging behavior.

No runtime behavior, protocol semantics, or network interactions are
changed by this patch. All modifications are strictly limited to
build-time and platform-specific code paths and are only active when
targeting Emscripten. Native builds and existing deployment scenarios
remain unaffected.

This patch is intended as groundwork. Follow-up changes, proposed
separately and incrementally, may extend similar support to other
Osmocom components such as libosmo-netif, libosmo-abis, osmo-bts, and
osmo-trx, while keeping all such changes optional and isolated from
native builds.

Change-Id: Ia8d5f4bb6570b5e055826f3a051e5e5896866e31
dtv.comp at

#2212 (Jan 22, 2026, 10:45:30 AM)

build: detect netns support via configure-time capability checks

The netns API was previously guarded by platform-specific preprocessor
conditions (e.g. !EMBEDDED and defined(__linux__)), which caused the
netns headers and implementation to be entirely excluded from non-Linux
builds such as Emscripten. This in turn led to build failures in code
depending on the netns API, as the symbols and declarations were not
available at all.

Replace the hard-coded platform checks with explicit configure-time
capability detection. The build now checks for the concrete requirements
needed by netns and netdev support, including the availability of setns(), unshare(),
mount(), the CLONE_NEWNET macro and required headers.

Based on the result of these checks, USE_NETNS is defined and netns support
is either enabled or disabled in a controlled manner.

Netns and netdev support remains disabled for embedded builds.

No functional changes intended for platforms where netns is available.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2211 (Jan 22, 2026, 10:35:40 AM)

osmo_io: Support rx of segments up to ~UINT16_MAX

Previously if we recevied a big chunk (near UINT16_MAX), we would hit
the following assert in iofd_msgb_alloc2(), because our msgb
implementation can only handle sizes up to 16 bit length, counting
headroom + data length:
"OSMO_ASSERT(size + headroom <= 0xffff);".

This new improved logic allows handling segments of up to ~UINT16_MAX
which may come in in multiple read calls. It also adds logic to catch
received segments greater than UINT16_MAX (or buggy segment_cb or buggy
peer transmitting to us) and notifies the user of a broken stream
through read_cb() in that case.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2210 (Jan 21, 2026, 6:29:50 PM)

osmo_io: Assert osmo_iofd_set_alloc_info() params fit in a 16bit value

Related: SYS#7842
Change-Id: I32822574db8997a02bf18b71bf6ab596e726cb82
Pau Espin Pedrol at

#2209 (Jan 21, 2026, 6:14:06 PM)

core: always build osmo_sock_multiaddr_* helpers

Always build the public osmo_sock_multiaddr_* helper functions,
independent of HAVE_LIBSCTP.

Move the HAVE_LIBSCTP checks inside the functions and limit them
to the SCTP-specific code paths: when IPPROTO_SCTP is requested
without libsctp support, return -ENOTSUP, while non-SCTP protocols
continue to work as before.

This fixes link failures in libosmo-netif when building with
--disable-libsctp.

Change-Id: I3e70b7cd6cb4d022252e6ddc70a42ca5eea72bb1
dtv.comp at

#2208 (Jan 21, 2026, 6:14:05 PM)

build: control USE_NETNS via configure.ac

Define USE_NETNS based on host_os and disable it for embedded builds.

No functional changes intended, this is a preparatory refactor to keep
follow-up patches focused and easier to review.

Change-Id: I2322eb2936bea35596f1fd6b6a713ea5f997b1ea
dtv.comp at

#2207 (Jan 21, 2026, 5:38:23 PM)

osmo_io: Prevent abort allocating rx segment bigger than UINT16_MAX

Avoid hitting iofd_msgb_alloc2() assert "OSMO_ASSERT(size + headroom <=
0xffff);".

Our msgb implementation can only handle sizes up to 16bit in length,
counting headroom + data length.

Related: SYS#7842
Change-Id: I8c11a7edbed2335ada40a1f93d081041974c3586
Pau Espin Pedrol at

#2206 (Jan 21, 2026, 5:32:08 PM)

osmo_io: Reorder iofd_handle_segmented_read()

All other similar functions have first the int rc and later the struct
msgb; fix this one being different.

Change-Id: I88683334e77901776c806dad776ef46ea20b4480
Pau Espin Pedrol at