Commit Graph

223 Commits

Author SHA1 Message Date
Harald Welte 1ee44400a4 Fix license headers: Should have been AGPLv3+, not GPLv2+
I'm not sure why so many files (particularly written by Philipp)
did contain a GPLv2+ header, instead of the AGPLv3+ which is the
actual overall project license.  I consider it a mistake.

In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.

Change-Id: I42ea544ae4e5c4d3bedad12ddb55cf3c26a30919
2024-02-17 10:28:41 +01:00
Neels Hofmeyr eba9cbf9d1 pfcp: implement sending Network Instance IEs
Allow configuring specific Network Instance names for the Core and
Access sides, to send to the UPF, to allow the UPF to pick the proper
network interface to create GTP tunnels on.

Add VTY cfg 'hnbgw' / 'pfcp' / 'netinst (access|core) NAME' to allow
configuring Network Interface values to send in PFCP. These are "dotted"
domain name strings, as in APN.

Add these Network Interface names to the PFCP messages' detection as
well as forwarding rules, each one indicating the side that it is
detecting on or forwarding to.

This helps lift osmo-hnbgw's PFCP support out of lab situations to a
proper production scenario, where the core and access networks are in
separate subnets, with osmo-hnbgw + UPF as the gateway.

For example, in osmo-hnbgw, configure

    netinst access my-ran
    netinst core my-core

and in osmo-upf, configure

   add my-ran
   add my-core

In effect, all GTP tunnel endpoints towards the Access side will be
bound on, and all GTP tunnel endpoints towards the Core side
will be bound on

Related: SYS#5895
Change-Id: Ief53dbfacf1645c32a07847d590c4884d4c8ca56
2024-01-21 02:48:38 +01:00
Neels Hofmeyr 5fd2aa5dc4 pfcp: fix missing vty_write of pfcp local-port
Change-Id: I180e67b8abdd3c0d91b30f1e7668b02f1a323809
2024-01-21 02:29:45 +01:00
Neels Hofmeyr 4ec1c77f9c add tests/pfcp_cfg.vty.with_pfcp
So far, we had no pfcp.vty test, because PFCP support is built
conditionally, and the pfcp.vty test would always fail without PFCP

Add a pfcp test for the VTY, conditionally: use suffix .vty.with_pfcp to
identify tests that need PFCP support, and run those only when
configured with --enable-pfcp.

Related: SYS#5895
Change-Id: Ibb1797bb43a18f26fc693e0c8920cfd1f5fb9ede
2024-01-21 02:29:31 +01:00
Neels Hofmeyr ec10455aed tweak vty doc: "UDP port"
Change-Id: I24e52143a8f3d0c9f92985f6bb0420b34926eb33
2024-01-20 08:34:54 +01:00
Neels Hofmeyr 6582c9a06c pfcp: fix modification of wrong FAR ID
Do not update the Core-facing Forwarding Action Rule with the Access
side's remote TEID, update the Access-facing FAR as we should.

This is a seemingly small but very grave bug in osmo-hnbgw's PFCP
implementation, and proof that no-one anywhere has tested osmo-hnbgw's
PFCP support properly yet.

Related: SYS#5895
Change-Id: I596f1785d280d7e53e0cef649d6bb5df01ebf648
2024-01-20 08:34:54 +01:00
Oliver Smith 1237ae48d1 debian: fix having no manuals in osmo-hnbgw-doc
Fixes: OS#6326
Change-Id: I8daeba6b267b2f7793a26a0e1fbc74ab17401cde
2024-01-19 14:40:49 +01:00
Oliver Smith 770d62f91b gitignore: add *.la, hnbgw_vty_reference.xml
Change-Id: I5c9ec6cf01d75b10a86098755064ad187de815c1
2024-01-19 14:40:42 +01:00
Harald Welte 67f9de4148 Display RANAP state during 'show cnlink'
This adds a line to the output showing DISCONNECTED or CONNNECTED
state for each cnlink during the 'show cnlink' VTY command.

Closes: SYS#6741
Change-Id: I6ab7d08fcd0631d31a12418f950c5901a93db43a
2024-01-15 13:56:38 +01:00
Neels Hofmeyr 406d95139b rua: move from ERROR to DEBUG log: stray RUA Disconnect
Related: SYS#6602
Change-Id: Ib55c254190f46f24981e4394d8d5cf017070118d
2024-01-05 05:12:03 +01:00
Neels Hofmeyr c17b2850b7 rua: validate correct RUA ctx state per RUA message type
It helps in a pretty complex situation seen in the field.
A third-party MSC releases SCCP in one fell swoop, not waiting for the
Iu Release Complete to come back from RAN as the specs would suggest.

The result is this odd sequence, where late rx of RUA Disconnect
actually causes a new SCCP connection to be established and torn down

    RAN                 HNBGW                MSC
     |                    |<--IU-Release-Cmd--|
     |<--IU-Release-Cmd---|                   |
     |                    |<--SCCP-RLSD-------| (too soon)
     |...<-RUA-Disconnect-|                   x (the consequence)
     |                    x
     |--RUA-Disconnect--->|                     (IU Release Complete)
     x              <create-new-ctx>
                          x                   x

This patch is a relatively simple practical improvement of above
situation that is logically obvious:

Validate the correct message type for creating a new RUA-to-SCCP
context: RUA Connect.

That means the IU Release Complete is ignored:

    RAN                 HNBGW                MSC
     |                    |<--IU-Release-Cmd--|
     |<--IU-Release-Cmd---|                   |
     |                    |<--SCCP-RLSD-------| (too soon)
     |...<-RUA-Disconnect-|                   x (the consequence)
     |                    x
     |--RUA-Disconnect--->|                     (IU Release Complete)
     x                 <error>

Related: SYS#6602
Change-Id: Ie359fcada98fb19f56015cf462e6d8c039f5fce5
2023-12-12 02:02:08 +01:00
Pau Espin 5755268f9b mgw_fsm: Modify RAB on HNB if IuUP local IP addr at MGW changes during MDCX
Allow IP address renegotation between HNB and MGW:
* Upon MGCP MDCX ACK received from the RAN-side conn, if the IP address/port
  changes, then restart the RAB-Ass-Req+Resp procedure on Iuh.
* Upon RAB-Ass-Resp received from the HNB, if the IP address/port changes,
  then go through another MDCX + MDCX ACK prcoedure on MGCP.

An MDCX counter is introduced to avoid infinite loops where the HNB and
the MGW keep changing their IP address triggered by the change on the
other side, eg. due to incorrect network/routing setup.
The counter is also used to track count in order to make sure that
always at least 1 MDCX is transmitted, in order to change conn_mode to

Related: OS#6127
Change-Id: I936a50fed38a201c4a8da99b40f07082049e5157
2023-12-04 13:13:49 +01:00
Pau Espin 656d1d2778 mgw_fsm: Assume IuUP HNB IP addr = Iuh during MGCP CRCX on RAN side
In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for Iuh signalling.

When receiving a RAB-Ass-Req from CN, osmo-hnbgw creates an endpoint in
its co-located MGW and creates 2 MGCP conns on it, one facing the RAN
side and one facing the CN side. At that point, the remote CN IuUP IP address
is known (was include din the received RAB-Ass-Req), but the RAN one is
not yet known. Hence, the CRCX on the RAN-side conn contained no remote
IP address, which means MGW has to blindly guess a good local IP address
if "ip probing" is enabled.
As a result, when RAB-Ass-Resp comes back from the hNodeB containing the
allocated remote IuUP IP address and MGW is updated through MGCP MDCX,
it may happen that MGW rebinds to a better fitting local IP address and
returns it in MDCX. This has several downfalls:
1- We don't yet support updating the hNodeB about the changed IP address
(see mgw_fsm_mdcx_hnb). For that, we'd need to send a RAB-Modify-Req+Resp.
2- Even if we supported it, in the general case we'd be delaying call
establishment because an extra roundtrip is needed to update

In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for the Iuh signalling. Hence, use this assumption to
announce the Iuh IP address as a remote IuUP IP address when
transmitting the MGCP CRCX at the RAN-side conn to the MGW. This way
the MGW can potentially select a proper local IuUP IP address from the
start, so no RAB-Modify-Req is required later on.

The logic to transmit RAB-Modify-Req is left unimplemented in this
commit and is left as a later improvement.

Related: SYS#6657
Change-Id: Icf43e3a1cde809d844f17ef2d0600efe64bc3dfe
2023-12-04 12:07:05 +00:00
Neels Hofmeyr 90928fb246 systemd,manual: set LimitNOFILE=65536
A typical OS imposed limit is 1024 open FD, which is too low when there
are thousands of HNB.

In systemd service file, set a super high limit of 65536.

In osmo-hnbgw's user manual, add section 'Configure limits' describing
this in detail.

Related: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I5333765199cf9e3e5a570f85b85d2b7423d34a4d
2023-12-03 02:21:00 +00:00
Andreas Eversberg fadc67b8fb Use uniform log format for default config files
Related: OS#6272
Change-Id: I10bfc4150e10cac048f320641c040fa300f734c4
2023-12-01 11:53:41 +01:00
Pau Espin cd09569bc8 tests/ranap_rab_ass: Test RAB-Ass.req with X.213 IPv4 address len=7
It was found in the field that some peers sends an X.213 IP address
consisting of 7 bytes (1byte IDP/AFI, 2byte ICP, 4 byte IPv4 address) insetad
of 20 bytes. This was until recently failing in osmo-hnbgw due to
missing decoding functionalitit in osmo-iuh.git. Cover it here.

Related: SYS#6623
Depends: osmo-iuh.git I507fb1605d976bd8573162e4fa81721245330184
Change-Id: I71323018d79a4f5778dc6e49488d75ae7c2c4cdc
2023-11-27 14:51:13 +00:00
Neels Hofmeyr 3abd523faa allow (second) CS RAB Assignment Request without RTP info
In the field, we've encountered a so far unsupported scenario: after a
RAB Assignment Request and Response have successfully set up an RTP
stream, the CN sends *another* RAB Assignment Request to modify some SDU
parameters, omitting the transportLayerInformation IE (not modifying the
RTP address).

Directly forward all RAB Assignment Requests that have no RTP
information. This covers above use case, and also generally applies: no
RTP info means nothing to tell the MGW about.

Do not (yet?) support modifying the RTP address/port.

Related: osmo-ttcn3-hacks Iadaba0e5e82ad6d163ad509904ede213e2462d5c
Related: SYS#6624
Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
2023-11-07 04:34:35 +01:00
Neels Hofmeyr 81105a4d7a X31: fix vty doc
The actual scope is larger than just a stale release. Every RUA and SCCP
context map FSM state that has a timeout uses X31. (Seems I intended to
add more timers but forgot to follow up when I wrote it.)

Related: SYS#6602
Change-Id: I75a25f9065bc651e7ba8feda6db03c49a3b75c5e
2023-11-03 19:42:40 +00:00
Pau Espin 0e987d7f3c context_map_sccp: Fix assert hit due to missing ev handling
This was being triggered recently by
HNBGW_Tests.TC_ranap_cs_mo_disconnect in osmo-ttcn3-hacks.git.

Change-Id: Idaad11eaa3c2e56de792f80bab1f1d8435ef9b68
2023-11-02 12:09:06 +01:00
Pau Espin b64afa8631 Increase default X31 val from 5 to 15 seconds
It was spotted that in some deploys with satellite links and heavy load,
the roundtrip times for CR and CC can go slightly over 12 seconds, so
better increase the default value to 15 seconds to be on a safer place
and avoid operation problems with default configuration.

Related: SYS#6602, SYS#6616
Change-Id: I24225cfc0addf326c239ec658a27b93b83a3e751
2023-10-31 12:46:22 +01:00
Pau Espin 8514b73bff hnbgw_cn: Remove assert hit due to wrong assumption
The HNBGW in correctly assumes that no ss7->sccp instance is allocated
until the same function calls osmo_sccp_simple_client_on_ss7_id().
This assumption is wrong, since ss7 may create its own ss7->sccp
instance internally as a result of vty configuration, eg. when "sccp
max-optional-data 124" is placed in osmo-hnbgw.cfg file.

In this scenario, simply removing the assert is enough, since
osmo_sccp_simple_client_on_ss7_id() just calls osmo_ss7_ensure_sccp(),
the same that the libmoso-sccp code called to allocate the pointer.

Related: SYS#6566
Fixes: f3caea850b
Change-Id: I1221c165156e9625324cf0080836a8ed2bad4e9c
2023-09-19 12:36:38 +02:00
Pau Espin 92340d2131 Bump version: → 1.5.0
Change-Id: I7816b6554ce733207302c373d745b52146e0a995
2023-09-12 17:18:44 +02:00
Pau Espin 89fe80525b Tear down call if local IuUP MGW address changed during MDCX
Due to ip probing used at MGW and specific/complex routing in place
between RAN and CN, it may happen that, on the RAN-side endpoint connection,
the MGW first selects a local IP address.

Then, after the HNBGW signalling it to the HNB with the patched RabAssReq
and receiving the HNB local IP address through RabAssResp, then applying
it to MGW through MDCX, it can happen that the MDCX ACK contains a changed
local IP address at the MGW, due to IP probing after learning the remote

This change is so far not announced to the HNB in anyway, ending up in the
HNB sending IuUP packets to the wrong IP/port, which is rejected with ICMP
due to osmo-mgw having no socket open there anymore.

We should at least, in osmo-hnbgw, if detecting the local MGW IP address
changed during MDCX, tear down the call setup. This patch does precisely

Related: OS#6127
Change-Id: I32c4a7f838ceb5077bec7945e7976ce455d6b025
2023-08-01 19:21:38 +02:00
Philipp Maier 267a92a580 ranap_rab_ass: be sure to initialize memory with 0
When we use the ASN.1 decoder functions, we often reserve some memory on
the stack to store the results. (e.g. RANAP_RAB_xy_t _RANAP_RAB_xy;).
Then we assign the memory location to a pointer variable (e.g.
RANAP_RAB_xy = &_RANAP_RAB_xy). We do this for cosmetic reasons but we
may end up with an uninitialized buffer, which may cause trouble
lateron. Let's be consistent and make sure that those buffers are
initialized with zeros.

Change-Id: I7a8a951ccd8c9ae3923261468c0755192894a84b
2023-06-23 13:11:05 +00:00
Philipp Maier b77d944961 ranap_rab_ass: do not free never allocated FieldItems
When we check for an assignment failure in a RAB AssignmnetResponse, we
use decode_rab_flitms_from_resp_ies to search through the list of RAB
FailedItemsIEs for the RAB id we want to check. In case of failure, we
get a positive index back from this function. We then know that the RAB
that we checked for has failed bcause it was in the FailedItemsList.

In that case, we also must free the RAB FailedItemsIEs that
decode_rab_flitms_from_resp_ies has decoded. At the moment we also free
the RAB FailedItemsIEs also when decode_rab_flitms_from_resp_ies returns
with a negative return code, which may mean that the RAB was not found
or some other error occured. In this case we must not free since then
no valid RAB FailedItemsIEs are allocated.

Related: OS#6062
Change-Id: I755ba6599079810a048bf5b6d8947b5a9ffa622d
2023-06-23 13:11:05 +00:00
Neels Hofmeyr 067f1a0948 coverity: hnbgw_cn: avoid NULL deref in LOGP
Related: CID#321281
Change-Id: Icc2b45c8df8d92cfb42582615313d83389cf1621
2023-06-22 16:28:13 +02:00
Neels Hofmeyr 3a084af8f7 RUA: log tweak
I noticed that the log is awfully silent about disconnecting RUA, even
with DEBUG turned on. It is an important item that should show in the

Change-Id: I87592cbf197d5d3d2a22b04d9f6b64422af65ded
2023-06-21 04:16:13 +02:00
Neels Hofmeyr d58d15636f include Global RNC-ID in RESET-ACK
According to 3GPP TS 25.413, "The RNC shall include the Global

Related: SYS#6441
Change-Id: I49d351e90dfe4a7c4dfdd26542565f2d9bd3d605
2023-06-21 04:16:13 +02:00
Neels Hofmeyr 7867adc490 include Global RNC-ID in RESET
According to 3GPP TS 25.413, "The RNC shall include the Global
RNC-ID IE in the RESET message."

Related: SYS#6441
Change-Id: I2cd5d7ea86a6ed0916befe219dbf21373afbd95b
2023-06-21 04:16:13 +02:00
Neels Hofmeyr d482f8666c cfg: add 'hnbgw' / 'plmn MCC MNC'
According to 3GPP TS 25.413, "The RNC shall include the Global
RNC-ID IE in the RESET message." To be able to do that, osmo-hnbgw needs
to know the local PLMN.

Introduce explicit knowledge of the local PLMN by config, and use this
configured local PLMN in places where the local PLMN was so far derived

Subsequent patches will separately add the RNC-ID to the RANAP RESET

Since the PLMN is required to send correct RESET and RESET ACK, include
the new 'plmn' config item in all example configurations.

Related: SYS#6441
Change-Id: If404c3859acdfba274c719c7cb7d16f97d831a2a
2023-06-21 04:16:13 +02:00
Neels Hofmeyr 1b45792cbd cnpool: return Paging Resp to the exact CN link that Paged
Implement Paging record, remembering which CN link paged for which
mobile identity, for a set time period roundabout 15 seconds.

When receiving a Paging Response from a UE, connect it to the CN link
that sent the Paging.

Related: SYS#6412
Change-Id: I907dbcaeb442ca5630146f8cad40601c448fc40e
2023-06-21 04:16:13 +02:00
Neels Hofmeyr 5aeacc4500 use cnlink state in cnpool decisions
Change-Id: I28490a4a27bcda8fd689db8b8652e451103e3a9d
2023-06-21 04:16:13 +02:00
Neels Hofmeyr e14d3bd6fe detect in/active CN links by RANAP RESET
Implement cnlink FSM. This is a copy of osmo-bsc/bssmap_reset.c, except
for the connection success/failure counting.

The reason to exclude the CONN_CFM_FAILURE/_SUCCESS: it is a rather
experimental feature and should probably rather be covered by PCSTATE
notifications and protocol layer timeout tuning (e.g. SCCP ia timers).

Related: SYS#6412
Change-Id: Id3eefdea889a736fd5957b80280fa45b9547b792
2023-06-21 04:16:13 +02:00
Neels Hofmeyr fb627de4bb add ranap_domain_name()
As simple as it may seem, turning the RANAP CS/PS domain indicator to a
string so far is cumbersome. It is usually only CS or PS, but to be
accurate we should also expect invalid values. After the umpteenth
switch statement breaking up otherwise trivial code, I decided that yes,
after all, a value_string[] is a good idea even for just two enum values
that have only two-letter names.

Callers will follow in upcoming patches.

Related: SYS#6412
Change-Id: Ib3c5d772ccea8c854eec007de5c996d1b6640bc0
2023-06-21 04:16:13 +02:00
Neels Hofmeyr b1c0bb19e2 cnpool: add context_map_cnlink_lost() handling
When proper RANAP RESET handling is in place [1], a specific CN link may
be detected to be disconnected or reconnected at any point.
[1] Id3eefdea889a736fd5957b80280fa45b9547b792

When that happens, all related context maps should disconnect RUA and
SCCP links immediately. Add the context map side of this, so that
context_map_cnlink_lost() is ready to be dispatched in [1].

Related: SYS#6412
Change-Id: Ic0a6fcfb747dc093528ca2bd12a269ad390d465c
2023-06-21 04:16:10 +02:00
Neels Hofmeyr 72f0884ee0 ctrl test: also test msc 1
Change-Id: I957dca863b6cdc8b077f2ec2b2894cebe7613736
2023-06-16 04:25:31 +02:00
Neels Hofmeyr 11fa15e4d9 tweak lots of logging
Make lots of small tweaks in logging around RUA to SCCP context maps, CN
link selection and HNBAP:

- remove duplicate log context (e.g. LOGHNB() already shows the HNB Id)
- bring more sense into logging categories and levels / reduce noise
- add and clarify the details being logged at what points in time

Related: SYS#6412
Change-Id: I41275d8c3e272177976a9302795884666c35cd06
2023-06-16 04:25:31 +02:00
Neels Hofmeyr 15e79a2b7a make public: umts_cell_id_name()
Upcoming logging tweaks will call this from hnbgw_hnbap.c as well.
See I41275d8c3e272177976a9302795884666c35cd06

Related: SYS#6412
Change-Id: I499d18876685062d066a9a66d2def827efb77640
2023-06-16 04:07:24 +02:00
Neels Hofmeyr afb6298727 fix umts_cell_id_name(): show CID
The Cell ID is an important part to distinguish HNB in logging, add it
to the output string.

Use OTC_SELECT buffer instead of static buffer.

Related: SYS#6412
Change-Id: Id903b8579ded8b908e644808e440d373bcca8da4
2023-06-16 04:07:24 +02:00
Neels Hofmeyr 6563e11731 doc/examples/osmo-hnbgw/osmo-hnbgw-cnpool.cfg
Change-Id: I932eca7489f29eab23d180cd6d1216d26c62dd30
2023-06-16 04:07:24 +02:00
Neels Hofmeyr 36b5a74658 cnpool: select CN link from pool by NRI or round robin
This is the bulk of the CN pooling logic but is not working properly
without these future patches:

- detect in/active CN links by RANAP RESET

- return Paging Resp to the exact CN link that Paged

Change-Id: I66fba27cfbe6e2b27ee3443718846ecfbbd8a974
2023-06-16 04:07:24 +02:00
Neels Hofmeyr 685c276ce1 add CTRL transcript tests for cnpool rate ctrs
Related: SYS#6412
Change-Id: I5a9a23c10e3ac85dabbb1d367351bb7c5dfe2526
2023-06-16 04:07:24 +02:00
Neels Hofmeyr e513ffb983 add rate_ctr infra; add rate_ctrs for cnpool
Introduce rate counter stats to osmo-hnbgw.

Add the first rate counters -- they will be fed in upcoming commit
"cnpool: select CN link from pool by NRI or round robin"

Related: SYS#6412
Change-Id: I0132d053223a38e5756cede74106019c47ddcd94
2023-06-16 04:07:24 +02:00
Neels Hofmeyr 56323378db cnpool: extract Mobile Identity from RANAP payload
For InitialUE messages, decode the RANAP and NAS PDU to obtain the
Mobile Identity. Store it in map->l3.

A following patch will use this mobile identity to decide on which CN
links to pick from the CN pools for this subscriber.

Add the new information to LOG_MAP() as ubiquitous logging context.

Depends: libosmocore Ic5e0406d9e20b0d4e1372fa30ba11a1e69f5cc94
Related: SYS#6412
Change-Id: I373d665c9684b607207f68094188eab63209db51
2023-06-16 04:07:24 +02:00
Neels Hofmeyr a0321315e1 startup config tests: show default 'msc 0', 'sgsn 0'
Even when the config file did not configure any, the 'show
running-config' shows the default 'msc 0' and 'sgsn 0' that were
created. Let's also show that in the vty scripts.

Change-Id: Ia4e43fa9b5d9fda1ae374d3d31965aafe85d493d
2023-06-16 04:05:45 +02:00
Pau Espin ee1a647547 Use new mgcp_client_conf_alloc() API to alloc mgcp_client_conf
Depends: osmo-mgw.git Change-Id Iba0853ed099a32cf1dde78c17e1b34343db41cfc
Change-Id: I0f142e7af180136e8dac142672d38d75a76ef123
2023-06-14 14:08:44 +02:00
Pau Espin d6b0217c33 tests: Update *.vty after libosmo-sccp VTY improvements
After recent change, libosmo-sccp is always printing the "role" config.

Depends: libosmo-sccp.git Change-Id Ie81987265118e48173211f88b27a006115dc62d4
Change-Id: I316cd26ceb97f2ccfd1065d65177e7d3926625b0
2023-06-08 19:31:42 +02:00
Neels Hofmeyr d5fe76dec8 fixup for 'cnpool: split up context_map_find_...'
Fix: missing allocation of SCCP FSM instance.

When submitting patch [1], i failed to notice that a small but important
fix, already present later on my branch, was needed for this patch to

'cnpool: split up context_map_find_or_create_by_rua_ctx_id()'

Change-Id: I447f989f1d58b666bf9f1ab49ce6ba4fc5cdda80
2023-06-07 03:41:38 +02:00
Neels Hofmeyr 83dce9f7da add hnbgw_decode_ranap_co()
An upcoming patch will re-use this pattern of decoding RANAP and
attaching a talloc destructor to the result for the third time. The
caller will be in hnbgw_rua.c, so make this a "public" function.

Change-Id: I3695babfb083ed1f5fff700dcb7646fa95496a52
2023-06-02 17:11:25 +02:00
Neels Hofmeyr c957f4efd5 tdefs; combine timer groups 'ps' and 'cmap' to 'hnbgw'
Makes no sense to have groups with one member each.
Soon I will add a new timer that matches neither 'cmap' nor 'ps', and I
would have to open a third group with a single member.

Add a shim that redirects 'ps' to 'hnbgw'.
The group 'cmap' has not yet been released, so just drop that one
without a shim.

Change-Id: Ica6063fae4588b51897e5574d975b3185fa9ae80
2023-06-02 17:11:25 +02:00