aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-10-11Constify LLC/SNDCP parametersMax5-22/+23
That makes it easier to track side-effects while reading the code. Related: OS#5349 Change-Id: I903f8a747a8d3b7f734dac7b0c12373ecbb90b11
2022-10-11GTP: migrate from deprecated functionMax1-2/+2
The gtp_set_cb_recovery3() is similar to gtp_set_cb_recovery2() with extra parameter representing GSN. Change-Id: I8b46cf8c52e36b0312eddf37f3e136662b95732e
2022-10-08SNDCP: log more details on failureMax1-2/+3
Related: OS#5349 Change-Id: Iad3ebbc28909a827db7b3a0ae2d3e1de7991210f
2022-09-08llc: gprs_llc_fcs(): make the input data pointer constVadim Yanitskiy4-4/+4
Change-Id: If95210fe69f915ab1010fe5916cb6bee3faeb7b9
2022-09-08gprs_llc.h: use '#pragma once'Vadim Yanitskiy1-5/+1
Change-Id: Iff748fe68dbef83589bfb5e3bea5183deb365fa6
2022-08-30Set working directory in systemd service fileMax2-0/+4
By default systemd will execute service with root directory (or home directory for user instance) which might result in attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead. Related: OS#4821 Change-Id: I950d84853c6737276d02b3275127b499ae567c38
2022-08-26gprs_llc: fix misleading spacing in gprs_llc_rcvmsg()Vadim Yanitskiy1-3/+3
Change-Id: I7ec97a7d9b37f0541887bc13e31f547613f8945e
2022-08-16configure.ac: do not require unused dlsym/dlopenVadim Yanitskiy1-7/+0
Change-Id: I90b383ed45b27d8b59272116dd81acb72912349d
2022-06-29Bump version: 1.8.0.9-c230-dirty → 1.9.01.9.0Pau Espin Pedrol4-31/+54
Change-Id: If8d3bad88dbd57b620e3aca61d99073e178c2fb6
2022-06-20README: Major updateHarald Welte3-18/+82
* convert to markdown syntax * bring in-line with other osmo-* README.md files, in terms of links to git, mailing list, manuals, etc. Change-Id: Ia4a4329c6ef6b8c833aa26832776dad662cdc7e9
2022-06-20update git URLs (git -> https; gitea)Harald Welte4-5/+5
Change-Id: Ib8d2953a6c3f1e65b7c638feea4d8a97ee02e443
2022-04-13tests: use 'check_PROGRAMS' instead of 'noinst_PROGRAMS'Vadim Yanitskiy7-7/+7
When using 'check_PROGRAMS', autoconf/automake generates smarter Makefiles, so that the test programs are not being compiled during the normal 'make all', but only during 'make check'. Change-Id: I8118ee3d3da9bdcd0c691471ef91b95dba21004a
2022-03-10Iu: add UEA encryptionNeels Hofmeyr6-3/+48
Add vty 'encryption uea 0 1 2', defaults to 'encryption uea 0' to yield previous behavior. If any UEA above 0 is enabled, include the UEA key in the Iu Security Mode Command. I noticed that only the code bit in st_iu_security_cmd_on_enter() affects the test. The same code in gsm48_gmm_authorize() seems to be dead code? But applying the patch there as well just to be safe. We cannot yet verify the chosen UEA to match a configured UEA level, because the iu_client.c does not send us message details with the RANAP_IU_EVENT_SECURITY_MODE_COMPLETE. Also we cannot yet send the set of configured UEA to the hNodeB, since, again, iu_client.c does not provide the proper API for it. The proper solution here is to completely dissolve iu_client.c and do all Iu handling in osmo-sgsn itself -- see OS#5487. Related: SYS#5516 Related: I1a7c3b156830058c43f15f55883ea301d2d01d5f (osmo-ttcn3-hacks) Change-Id: I27e8e0078c45426bf227bb44aac82a4875d18d0f
2022-03-07s/cipher_support_mask/gea_encryption_maskNeels Hofmeyr4-12/+12
will add uea_encryption_mask, and find that the name 'cipher_support_mask' is not concise enough. Related: SYS#5516 Change-Id: Ie8d4a0534c5b751f698bce425427bb1d28ddea31
2022-02-18Revert "sgsn: Handle different levels of QoS"Pau Espin Pedrol1-12/+5
This reverts commit 4bd931f96d75d3e71b73a06e67f84ffdcab9caf6. The commit was wrong, and previous code is correct. Relevant specs: * TS 29.060 7.7.34 Quality of Service (QoS) Profile * TS 24.008 10.5.6.5 Quality of service As can be seen in TS 24.008 10.5.6.5, OSMO_IE_GSM_REQ_QOS never comes with the the ARP byte prepended. This is actually always prepended when sending the GTP message, as explained in TS 29.060 7.7.34. As a result, the Qos Service sent in Create PDP Context Request sent to the GGSN contained wrongly formatted Qos Profile IE, which was observed checking wireshark with a real phone. This was found due to open5gs-smfd being more strict about the possible lengths of the IE, since the wrongly formatted IE send in GTP had length=14, which is incorrect due to folllowing TS 24.008 10.5.6.5 wording: "Octets 15-22 are optional. If octet 15 is included, then octet 16 shall also be included, and octets 17-22may be included." In this case, due to the wrong format it was seen as including octet 15 but not 16. Change-Id: I4fc5ab823a27d27482858a7459337a2f8ae593c3 Related: SYS#5793
2022-01-11Drop unneeded ax_check_compile_flag.m4Pau Espin Pedrol1-74/+0
The macro is no longer used since 2d0e22960cc8f9c6f97159589df25395cc491e85. Change-Id: I230005acc27e29c679a4ddbb2b316a3aae70874e
2021-12-14treewide: remove FSF addressOliver Smith3-12/+0
Remove the paragraph about writing to the Free Software Foundation's mailing address. The FSF has changed addresses in the past, and may do so again. In 2021 this is not useful, let's rather have a bit less boilerplate at the start of source files. Change-Id: I9bc57a7152015e0f37e3d1573921d6d5d3c0449b
2021-12-07llme_free: clean up related sndcpOliver Smith3-0/+18
Fix crash in vty_dump_sne when sndcp->lle has already been deallocated. Context: * sndcp->lle is set only once in gprs_sndcp_entity_alloc() * sndcp->lle is a struct gprs_llc_lle, which gets allocated and deallocated together with struct gprs_llc_llme. From gprs_llc.h: struct gprs_llc_llme { ... struct gprs_llc_lle lle[NUM_SAPIS]; Fixes: OS#4824 Change-Id: I707029f78222bc6335837241e5a08c54c5ae6eb3
2021-11-16Bump version: 1.7.0.28-245ac-dirty → 1.8.01.8.0Pau Espin Pedrol5-31/+74
Change-Id: I62daba59b9dd1a0cade5292c8705ee5ec5b103c2
2021-11-15tests/Makefile.am: do not try removing non-existing filesVadim Yanitskiy1-3/+3
Change-Id: Ie9f4a9aa4061e4e4c659b1ad71596846ce75df7b
2021-11-04Revert "Turn some compiler warnings into errors"Oliver Smith1-12/+0
Do not turn some compiler warnings into errors by default. This patch was added before --enable-werror was available. We build with --enable-werror during development and in CI. If the code is built with a different compiler that throws additional warnings, it should not stop the build. This reverts commit 34f012639ddf41470714ae74ae961d158670a4c7. Related: OS#5289 Change-Id: I24e0a0d7f93f196dc642e37b03f68464024c09d4
2021-09-30VTY: Don't display 'PDP Address: invalid' for IPv4v6Keith3-6/+24
We were not handling the case of PDP_TYPE_N_IETF_IPv4v6 in gprs_pdpaddr2str() and showed "invalid" for these addresses. Depends: libosmocore Change-Id: I1f82f9d8fc13dcc4474760329bd74ae9685b9031 Change-Id: Id36b7520677e4a0af40d05dc503b26d1b0b74a26
2021-09-01debian/control: remove dh-systemd build-dependOliver Smith1-1/+0
Related: OS#5223 Change-Id: I769bf61a2f3a97d55c65999436d2cb079c9170a0
2021-08-06vty: add "page imsi"Oliver Smith1-0/+21
Make it easy to manually test pagings from SGSN to the PCU. Related: SYS#4878 Change-Id: I8a73caa234f6b841e641be866e22e7fa03152eb7
2021-07-12gtphub: remove llist_first, llist_last macrosOliver Smith1-13/+2
Use list_first_entry_or_null instead of llist_first, which has been present in libosmocore since the 0.10.0 release. Use llist_last_entry instead of llist_last (also present since libosmocore 0.10.0). This macro does not have a check for an empty list, however the only user is already checking for an empty list before using the macro. This solves a build error, as llist_last was defined in libosmocore Icf455bf6ba9d60bd311af17c9e80febaa42cacc9 (should probably be reverted for backwards compatibility with previous osmo-sgsn versions?): gtphub.c:68:0: error: "llist_last" redefined [-Werror] #define llist_last(head, type, entry) \ In file included from /build/deps/install/stow/libosmocore/include/osmocom/core/timer.h:46:0, from /build/deps/install/stow/osmo-ggsn/include/gtp.h:17, from gtphub.c:32: /build/deps/install/stow/libosmocore/include/osmocom/core/linuxlist.h:245:0: note: this is the location of the previous definition #define llist_last(head) (head)->prev Change-Id: Ia0496c24386cd13b1e9e604aa2d425d3fa28d352
2021-07-03doc/manuals: update configuration.adoc to use new command syntaxVadim Yanitskiy1-3/+3
The old command is deprecated since [1] has been merged. Change-Id: Iac985f373de98206fdfb3196295ebec160189780 Related: [1] Ie6700c4e9d2df1eb5fde1b971e287b62668cc2de Related: SYS#5324
2021-06-16add support for multiple encryption algorithms and a5/4Eric8-19/+118
Change-Id: Ie6700c4e9d2df1eb5fde1b971e287b62668cc2de Related: SYS#5324
2021-06-04Use new stat item/ctr getter APIsPau Espin Pedrol7-50/+50
Generated with spatch: """ @@ expression E1, E2; @@ - &E2->ctr[E1] + rate_ctr_group_get_ctr(E2, E1) """ Change-Id: I2e064883ac6dafa89e41a297a886a9ebd26ce925
2021-05-20vty: Fix optional display of pdp with mm-contextKeith1-3/+2
The vty is randomly including the pdp context when the vty command 'show mm-context all' is issued without the pdp parameter. I do not know why, but I assume that relying on a true/false test of argv[0] has unpredictable results. Change-Id: Idcde4dd30a39625b24a1c3a38901349875e0949a
2021-05-19Support forwarding RIM messages over GTPCv1 EUTRAN<->GERANPau Espin Pedrol16-38/+695
MMEs connect over Gn interface using GTPCv1 towards the SGSN in order to exchange RIM PDUs by using "RAN Information Relay" GTPCv1 message type. For more info, see 3GPP TS 29.060 sec 7.5.14.1 "RAN Information Relay" In order to support it, this commit does the following: * Uses new libgtp APIs to rx and tx RAN Information Relay messages. The same "gsn" object is reused, ie. the local GTPCv1 socket address used for exchanging messages against GGSN is reused. * Adds a new "sgsn_mme_ctx" struct holding information about MMEs allowed by the SGSN, each one containing information about the GTP address it uses, the in/out routing based on TAI requests, etc. The set of MMEs and their config can be set up using new VTY node introduced in this commit. * The RIM related code in SGSN is refactored to allow forwarding from and to several types of addresses/interfaces. Depends: osmo-ggsn.git Change-Id Iea3eb032ccd4aed5187baca7f7719349d76039d4 Depends: libosmocore.git Change-Id I534db7d8bc5ceb19a2a6866f07d5f5c70e456c5c Related: SYS#5314 Change-Id: I396450b8d8b66595dab8ff7bf41cbf964bb40d93
2021-05-08gtp: Delete ctx upon receive UpdateCtxResp with cause Non-existentPau Espin Pedrol1-0/+29
Related: SYS#5435 Change-Id: Ic5f682a79663acc65fd364dd7a3a7cc554534414
2021-05-03Drop unused GBRPOXY enum fieldPau Espin Pedrol1-2/+1
Change-Id: I85dbc65addfbb072a75b6f62fcc4306b7fbb6a91
2021-04-14mm_state_{gb,iu}_fsm: Improve naming for detach eventPau Espin Pedrol6-20/+18
The E_(P)MM_IMPLICIT_DETACH event was actually sent and handled when the UE was considered to be detached, no matter the reason, be it due to implicit detach, or Detach Request received, etc. So, let's properly name the event to avoid confusions in the code. Related: SYS#5389 Change-Id: I224ea9db80b4d96696934cea06349dab036f919b
2021-04-14mm_state_{gb,iu}_fsm: Add missing license block, improve spec referencesPau Espin Pedrol4-3/+46
Change-Id: Ifcfd9c11005a388220c599e7b2f6901175141f1c
2021-04-14gprs_ranap.c: Clean up code path releasing IU connPau Espin Pedrol1-4/+3
Let's always send the event to the FSM and keep logic of whether it's a good event to sent or not inside the FSM, not in the caller. The logic is kept the same: if the event is not expected (not handled), keep forcing free of the IU connection. In theory this should never happen since only a PMM in Connected state should have a established connection (hence only a PMM in Connected state can have it released). In any case let's keep the safety check, but let the FSM receive the event and log an error about unexpected event, which is more interesting from debug point of view. While at it, clean up the related logging line: There's no need to print the imsi explicitly, since LOGMMCTXP already does it. Furthermore, print the exact low level event which triggered the code path. Related: SYS#5389 Change-Id: I45017562ea7f27c2248b7de56f99ce7ca88e89b2
2021-04-14Iu: Drop timer X3314Pau Espin Pedrol4-28/+5
This Iu timer is Osmocom specific, but is made to resemble T3314 timer from GERAN (also named READY timer). The idea of this activity timer was to arm it whenever PMM state transitions to CONNECTED, and then rearm it every time there's some sort of activity, until there's none for some time, then we send a Release Command to close the conn with the HNGBW/RNC. That's the same principle as per spec-defined READY timer T3314. However, there's still a fundamental problem with it: GTP-U in GERAN passes through the SGSN, but in UTRAN, the GTP-U stream goes directly from the HnodeB to the GGSN. Hence, there's no proper way to re-arm this timer upon activity in UTRAN, basically because the SGSN will never see (userplane data) activity. That explains why the E_MM_PDU_RECEPTION event exists for mm_state_gb_fsm, but doesn't exist for mm_state_iu_fsm. As a result, the timer is currently never rearmed, which means it will transition to IDLE always after 44 seconds (default value) once it went into CONNECTED state. In UTRAN, there is a SCCP connection for each subscriber between RNC/hNB and SGSN. If the subscriber is no longer in the respective state, the RNC/hNB should release that IuPS SCCP connection, whcih in turn means the SGSN cleans up its state. Furthermore, SCCP has a built-in IT (inactivity timer). So should the RNC/hNB die, that timer would time out, and the SGSN-side local SCCP stack (provider) wold send a RELEASE.ind for that connection to the user (SGSN). TLDR; this timer is not really needed and cannot be implemented properly in UTRAN, so let's remove it. Related: OS#5116 Change-Id: Ibc71829e417bf2dd0c27deb842369dd4f17010d6
2021-04-13mm_state_iu_fsm: T3314 expiry must lead to PMM IDLE, not PMM DETACHEDPau Espin Pedrol1-1/+0
This Iu timer is Osmocom specific, but is made to resemble T3314 timer from GERAN (also named READY timer). The READY timer mission is to make the MM state transition from READY to STANDBY, which in PMM (UTRAN) matches the transition from CONNECTED to IDLE. Instead, the patch introducing the timer was making it transition to DETACHED directly, but this was clearly not the intention: * Detaching a UE after 44 seconds (default value for T3314) is overkill. * The comment describing it says: "Iu User inactivity timer. On expiry release Iu connection". The release of Iu connection happens during the CONNECTED->IDLE transition (that's basically the difference between both states). The transition CONNECTED->IDLE is done by means of calling sgsn_ranap_iu_release_free(), which will eventually answer with a event RANAP_IU_EVENT_IU_RELEASE from lower layers when the Release Complete is received. At that point, osmo-sgsn code frees the connection and transitions to IDLE state. This way we maintain the state according to the connection existance. Related: SYS#5389 Related: osmo-iuh.git Change-Id Iac822c74e56750dc40e94573eae0e20853ff68c0 Fixes: 3bad31bcb42c3449e6847ea7495578817029a2e1 Change-Id: I7279102ad51b0c39eb6d04c129986984112d15cc
2021-04-13gprs_gmm.c: State proper GMM prefix logging rx/tx of GMM messagesPau Espin Pedrol1-23/+23
Change-Id: I58af41acdc4a04870b4cf2ea34a272d46d896254
2021-03-25mm_iu: Expect E_PMM_PS_ATTACH when in ST_PMM_IDLEPau Espin Pedrol1-1/+5
It can happen that the MS tries to attach while SGSN's MM Iu state is ST_PMM_IDLE (eg because UE was hard rebooted). Since Attach is a specific case of getting a Connection Established, also allow it as a trigger to transit to state ST_PMM_CONNECTED. Related: SYS#5389 Change-Id: Ia74a062ddc3052faad569f1428f0ddd02e5b188d
2021-03-25mm_iu: Send event E_PMM_PS_CONN_ESTABLISH upon rx GMM SERVICE REQUESTPau Espin Pedrol1-1/+1
Attach event should only be triggered by rx Attach Request, not other messages. Furthermore, currently E_PMM_PS_CONN_ESTABLISH is defined and expected in FSM but not sent by anyone. Also, The opposite transition is done by E_PMM_PS_CONN_RELEASE: """ MM_STATE_Iu(0)[0x81379b0]{Connected}: Received Event E_PMM_PS_CONN_RELEASE MM_STATE_Iu(0)[0x81379b0]{Connected}: state_chg to Idle ... MM(001010123456063/c8b8bd08) -> GMM SERVICE REQUEST MI(3367550216) type="signalling" MM_STATE_Iu(0)[0x81379b0]{Idle}: Received Event E_PMM_PS_ATTACH MM_STATE_Iu(0)[0x81379b0]{Idle}: Event E_PMM_PS_ATTACH not permitted """ Related: SYS#5389 Change-Id: Ica00891f91834522f4dea2508b62af34e4c4eca7
2021-03-25gmm_fsm: Expect E_GMM_COMMON_PROC_INIT_REQ when in ST_GMM_COMMON_PROC_INITPau Espin Pedrol1-1/+6
Due to whatever errors, the MS may re-init the Common Procedure by retransmitting a GPRS Attach Request while we are for instance aiting for Identity to be resolved. See this log: MM(---/ffffffff) -> GMM ATTACH REQUEST MI(3903513414) type="GPRS attach" GMM(gmm_fsm)[0x8136110]{Deregistered}: Allocated GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{Init}: Allocated MM_STATE_Gb[0x8138ac0]{Idle}: Allocated MM_STATE_Iu[0x8138bb0]{Detached}: Allocated GMM(gmm_fsm)[0x8136110]{Deregistered}: Received Event E_GMM_COMMON_PROC_INIT_REQ GMM(gmm_fsm)[0x8136110]{Deregistered}: state_chg to CommonProcedureInitiated GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{Init}: Received Event E_ATTACH_REQ_RECV GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{Init}: state_chg to CheckIdentity MM(/fba673a2) <- GPRS IDENTITY REQUEST: mi_type=IMEI UE(0x2){001-01-10422-99} Received GSM 04.08 message type 0x16, but no MM context available GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{CheckIdentity}: Timeout of T3370 MM(/fba673a2) <- GPRS IDENTITY REQUEST: mi_type=IMEI [Failure to handle GSM48_MT_GMM_ID_RESP and subsequent retransmission of GPRS IDENTITY REQUEST happens a couple times here] MM(---/ffffffff) -> GMM ATTACH REQUEST MI(3903513414) type="GPRS attach" GMM(gmm_fsm)[0x8136110]{CommonProcedureInitiated}: Received Event E_GMM_COMMON_PROC_INIT_REQ GMM(gmm_fsm)[0x8136110]{CommonProcedureInitiated}: Event E_GMM_COMMON_PROC_INIT_REQ not permitted GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{CheckIdentity}: Received Event E_ATTACH_REQ_RECV [Here IDENTITY REQUEST is sent again, and this time MS answers ID RESPONSE back and goes forward] Related: SYS#5389 Change-Id: I93d7d6bc694c84223a11d075d24c234b82b73389
2021-03-25gmm: Expect E_VLR_ANSWERED when in ST_IU_SECURITY_CMDPau Espin Pedrol1-1/+8
GSUP message is sent immediately before moving onto state ST_IU_SECURITY_CMD, so it's expected to receive a response for it, which will trigger event E_VLR_ANSWERED being sent. See following log showing the scenario: """ GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{Authenticate}: Received Event E_AUTH_RESP_RECV_SUCCESS MM(001010123456789/f8bab3dc) Requesting authorization MM(001010123456789/f8bab3dc) Missing information, requesting subscriber data MM(001010123456789/f8bab3dc) Requesting subscriber data update SUBSCR(001010123456789) subscriber data is not available SUBSCR(001010123456789) Sending GSUP, will send: 04 01 08 00 01 01 21 43 65 60 f3 28 01 01 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{Authenticate}: state_chg to IuSecurityCommand SUBSCR(001010123456789) Received GSUP message OSMO_GSUP_MSGT_INSERT_DATA_REQUEST SUBSCR(001010123456789) Will set PDP info, context id = 1, APN = 01 2a SUBSCR(001010123456789) Updating subscriber data MM(001010123456789/f8bab3dc) Subscriber data update MM(001010123456789/f8bab3dc) Updating authorization (authenticate -> accepted) MM(001010123456789/f8bab3dc) Got authorization update: state authenticate -> accepted MM(001010123456789/f8bab3dc) Authorized, continuing procedure, IMSI=001010123456789 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: Received Event E_VLR_ANSWERED GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: Event E_VLR_ANSWERED not permitted SUBSCR(001010123456789) Sending GSUP, will send: 12 01 08 00 01 01 21 43 65 60 f3 28 01 01 SUBSCR(001010123456789) Received GSUP message OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT SUBSCR(001010123456789) Updating subscriber data MM(001010123456789/f8bab3dc) Subscriber data update MM(001010123456789/f8bab3dc) Updating authorization (accepted -> accepted) sccp_sap_up(N-DATA.indication) N-DATA.ind(2, 20 06 00 08 00 00 01 00 06 00 01 00 ) handle_co(dir=2, proc=6) Transmitting RANAP CommonID (SCCP conn_id 2) GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: Received Event E_IU_SECURITY_CMD_COMPLETE GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: state_chg to WaitAttachComplete """ Related: SYS#5389 Change-Id: If348ff32faa4a709b59ee1b9b043883a7d46cf93
2021-03-25gmm: log GMM msg type name instead of numberPau Espin Pedrol1-2/+2
Change-Id: I2dc6eb5bfb0f44caf2687e582d660f71fdd647a2
2021-03-25ranap: log ranap iu event type name instead of numberPau Espin Pedrol1-1/+2
Change-Id: If66e9d5989b46abe01855a5c1183d567d358abeb
2021-03-14main: resurrect removed 'ns' logging category as deprecatedVadim Yanitskiy1-0/+1
This logging category has been removed completely in [1], and now osmo-sgsn fails to start with old configuration files: There is no such command. Error occurred during reading the below line: logging level ns info Let's accept it and print a deprecation warning. Change-Id: I2036170af41db89484c299e18e0b703c97427dc1 Fixes: [1] Ia4723ab344ad6a1927029a2d5d0dda020266b39d
2021-03-12manuals: Regenerate counters/VTY through dockerDaniel Willmann1-65/+11
Change-Id: I09b01d2e4bc7b1c17588100b16ac9f04cf72cf99
2021-03-10Remove bogus DNS log categoryHarald Welte3-11/+0
When we switched to the libosmogb NS2 implementation, we should have removed the DNS category, as NS2 uses DLNS internally and hence DNS is unused. Change-Id: Ia4723ab344ad6a1927029a2d5d0dda020266b39d Closes: OS#5058
2021-02-23Bump version: 1.6.0.157-b05c1-dirty → 1.7.01.7.0Pau Espin Pedrol5-34/+212
Change-Id: Ifa861bb0109f433b103a75d5140425bf19c66943
2021-02-23main: change initialization orderHarald Welte1-17/+17
We must have initialized e.g. the NS protocol stack before calling handle_options(), as that might want to dumpy the VTY XML, and it can obviously only dump those nodes that are registered at that point. Change-Id: Icd1b8fb3f466cdace67ff0d4f7c85183d8266c41
2021-02-23manuals: generate vty reference xml at build timeHarald Welte3-2678/+7
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built before the docs Rremove sgsn_vty_reference from the source tree. In manuals//Makefile.am use the new BUILT_REFERENCE_XML feature recently added to osmo-gsm-manuals, and add a build target to generate the XML using the new osmo-sgsn --vty-ref-xml cmdline switch. Change-Id: Ied75fdd13283aa592350994fb4febce06c213d3a Depends: I613d692328050a036d05b49a436ab495fc2087ba
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-01 08:57:34 +0000