path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2018-11-21layer23/ccch_scan: unwrap dump_bcch() as gsm48_rx_bcch()fixeria/l1ctl_sapVadim Yanitskiy1-14/+11
Change-Id: I382fbdb60513324164cd1147c36f3367bb6fb22c
2018-11-21(WIP) misc/cbch_sacn: indicate CBCH cbits to L1/PHYVadim Yanitskiy1-2/+8
Change-Id: If19f2b2ed645c0f6f5baf7ed853b41011603f1a0
2018-11-21layer23/l23sap.c: add Osmocom specific cbits for CBCHVadim Yanitskiy1-0/+31
CBCH logical channel is a bit similar to FACCH as there is no way to indicate that it's exactly CBCH and not just a regular SDCCH. There is nothing about CBCH stated in GSM 08.58, Chapter 9.3.1. This change introduces Osmocom specific extensions for that. Change-Id: I35e454c825481e6a390485ee042e384b31a08bf4
2018-11-21layer23/l23sap.c: use safe wrapper around rsl_dec_chan_nr()Vadim Yanitskiy1-7/+38
The rsl_dec_chan_nr() may fail to decode a given chan_nr, so it could lead to uninitialized memory access. Let's avoid this by adding a safe wrapper that. Change-Id: Id78304f494be70aa05e2da11c785ba5d9aeaf6db
2018-11-21layer23/common: move signal loss criteria to L23SAPVadim Yanitskiy2-67/+83
Change-Id: Ib70bf9104cf3b5489413dd90819fd4955ec16f95
2018-11-21layer23/l1ctl.c: cosmetic: drop useless includesVadim Yanitskiy1-3/+0
Change-Id: I16f595110faf27444175864384ce6800a90e10da
2018-11-21layer23/common: merge l1ctl_ph_prim_cb() to L23SAPVadim Yanitskiy7-69/+40
Change-Id: Ic852b2b7f5a651b7a4debc83778ae24c687e85f8
2018-11-21layer23/common: move GSMTAP handling to L23SAPVadim Yanitskiy3-20/+66
L1CTL implementation (i.e. l1ctl.c) is also not a good place for GSMTAP handling, let's move it to L23SAP. Change-Id: Ie143b9e839d944a7a7eebf5529798a49b8e175d7
2018-11-21layer23/common: introduce L23SAP API for L1CTLVadim Yanitskiy7-51/+134
Having a separate abstraction layer between both L1CTL interface and the upper layers would allow to keep the L1CTL implementation clean from GSMTAP / LAPDm / measurement specific stuff. Change-Id: I22d7932ddc03c692f2616726ced53b6e8eef822d
2018-11-19mobile: fix vty bind ip overrideMax1-3/+4
Previously the vty bind config parameter was always ignored. Fix this by using proper default value from the config unless it's explicitly set via command-line parameter. Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
2018-11-19Fix build with latest libosmocoreMax1-10/+0
Remove locally defined function which conflicts with the one in libosmocore. Change-Id: I1be1d39f7c93c959ca33f6296ecda71996865cca
2018-11-19l1l2 interface: use LOGP for socket errorsMax2-2/+4
Log via LOGP() like the rest of the file instead of fprintf() for consistency. While at it, also print error cause. Change-Id: Id205bcd9bdb7c3e4b96493d50be8381a6fa80ac6
2018-11-19osmocon: log error cause for socket openingMax1-1/+2
Change-Id: I2f871cb16e5e1033e42863a9e12459057004782c
2018-11-19mobile: log socket path on errorMax1-1/+1
Change-Id: I18eb46743e4c0e4e8f8032883f39fec355f03c78
2018-11-16mobile: use proper type for boolean flagsMax2-11/+11
This makes reading code easier and simplifies further modifications. Change-Id: I7eff2a61495ff167dc19fc9a41882a7a11fbf32d
2018-11-16mobile: add header for MS' MNCC functionsMax4-10/+12
This simplifies adding new functions and re-using them from other parts of the code. Change-Id: Ibad400a99afe052f011f54fc706836b6bf89f4b9
2018-11-08layer23: Avoid mempcy with NULL srcPau Espin Pedrol1-1/+2
Fixes following ASan warning: git/osmocom-bb/src/host/layer23/src/misc/../common/main.c:146:2: runtime error: null pointer passed as argument 2, which is declared to never be null The warning however is harmless since in that case, app_len = 0 and thus size to copy is 0. Change-Id: I009a5b53f1e5be72ce347d64d3a7cb1d95d37ea3
2018-11-05layer23: Fix build against gpsd >= 3.18Pau Espin Pedrol1-2/+13
Change-Id: I0e97d3e8c3688064c959ea60ecef50cfbbc1bcd6
2018-11-05cosmetic: fix trailing whitespacePau Espin Pedrol1-4/+3
Change-Id: I5c1a6d98079ad846d114584a17ba9d80d95e0595
2018-11-05l1ctl_proto.h: use flexible array member for traffic messagesVadim Yanitskiy3-16/+31
Unlike the DATA messages, traffic frames may have different length. Instead of having fixed payload (i.e. TCH frame) length, let's introduce a flexible array member. This would allow one to calculate the frame length using the MSGB API. Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
2018-10-27layer23/l1ctl.c: fix: use host byte order for TDMA fnVadim Yanitskiy1-1/+1
Change-Id: Iad00eebf03b38b9c4fc2d7ed66697d23a953d8b2
2018-10-27layer23/common: move SIM APDU caching from l1ctl.cVadim Yanitskiy3-16/+29
L1CTL implementation (i.e. l1ctl.c) is not a good place for the SIM specific stuff. Let's move it to the proper place (i.e. sim.c). As a bonus, this change fixes a possible problem of loosing the cached APDUs if two or more L2&3 applications are using a single LAPDm connection. The APDU buffer is dedicated per MS now. Change-Id: I564c610e45aa3b630ca5d1ec6bc1cace0dc9c566
2018-10-26trxcon: make TRX bind address configurableVadim Yanitskiy1-6/+17
Previously the wildcard address (i.e. '') was hard-coded as the bind address of TRX interface. Let's make it configurable by introducing a command line option. Note that the '--trx-ip' option was deprecated by '--trx-remote', because it isn't clean whether it is remore or local address. It still can be used, but was removed from help message. Change-Id: Ic2f43632cc57bb6f722eba05219e438f97fecb95
2018-10-26Report socket path on errorsMax3-3/+3
Change-Id: Ib63e1205d7b845c8779eb511635f26bae3a18085
2018-10-23fake_trx: introduce CTRL commands for RSSI simulationPau Espin Pedrol2-0/+42
Since FakeTRX is a proxy, it basically emulates transceiver for both osmo-bts-trx and trxcon, hence there are two separate and independent control interfaces (usually, ports 6701 and 5701). All simulation commands (see 'FAKE_*') are usually implemented on both interfaces separately: - - simulation commands affecting Uplink, - - simulation commands affecting Downlink. This change introduces the 'FAKE_RSSI' command for both CTRL interfaces in two variations: - absolute: CMD FAKE_RSSI <BASE> <THRESH> - relative: CMD FAKE_RSSI <+-BASE_DELTA> where 'THRESH' affects optional value randomization. Change-Id: Ic01c31fb0304345dd7337c3ee1c7ee3c2d3e8460
2018-10-22firmware: set corret shebang in python2 scriptPau Espin Pedrol1-1/+1
Change-Id: I64582568f7390b7f4e3253508209a59eb78ee4dd
2018-10-20trxcon/scheduler: add PDTCH channel supportVadim Yanitskiy4-4/+214
Change-Id: I1176576f54c1d68e79cc6ac37d61a9033f7018dd
2018-10-03layer23/l1ctl.c: clean up & fix message length checkingVadim Yanitskiy1-21/+44
Almost all handlers for received L1CTL messages are also affected by the bug fixed in I7fe2e00bb45ba07c9bb7438445eededfa09c96f3. In short, they do verify the length of 'msg->l2h' or 'msg->l3h', but not the 'msg->l1h'. Let's fix this, and also add missing checks. Change-Id: I866bb5d97a1cc1b6cb887877bb444b9e3dca977a
2018-10-03layer23/l1ctl.c: avoid confusion between L1CTL / L1 headersVadim Yanitskiy1-7/+7
As we assign the payload following L1CTL header to 'msg->l1h', it makes sense to avoid possible naming confusion. Change-Id: I5d21ca8664b3445f472d3ffde90d0e11805dcb16
2018-10-03layer23/l1ctl.c: fix: verify msg length using l1h, not l2hVadim Yanitskiy1-3/+4
The actual L1CTL header is pointed by 'msg->l1h', not 'l2h'! Since msg->l2h is NULL (because nobody set it), the result of msgb_l2len() would always be bigger than size of L1CTL header, as it is calculated in the following way: return msgb->tail - (uint8_t *)msgb_l2(msgb); So, in case if 'msg->l2h' is NULL, it turns into: return msgb->tail - 0; Change-Id: I7fe2e00bb45ba07c9bb7438445eededfa09c96f3
2018-10-03layer23/l1ctl.c: fix: verify msg length against l1ctl_hdrVadim Yanitskiy1-2/+1
In l1ctl_recv() we actually expect to 'see' the L1CTL header instead of the DL info header. Let's fix this. Change-Id: Ic7d017bef04f3c186565d5dade36959df1019bd8
2018-10-03layer23/l1ctl.c: keep L1 header, drop L1CTL headerVadim Yanitskiy1-16/+5
There is no need to keep the L1CTL header in messages being sent towards the upper layers, but the L1 info header can be used by L2&3 to obtain some information, e.g. TDMA frame number. Change-Id: Id64249f1b7a1c2be578263ba62aa195c452ab7e8
2018-10-03trxcon/scheduler: add dedicated CBCH mode supportVadim Yanitskiy1-0/+4
This change extends sched_trx_chan_nr2pchan_config() with Osmocom specific cbits related to CBCH, so now one can to decode CBCH channels in dedicated mode (see L1CTL_DM_EST_REQ). Change-Id: I9347c45638223cac34f4b48eb736e51a5055a36f
2018-10-03l1ctl_proto.h: extend ccch_mode enum with CBCHVadim Yanitskiy3-1/+10
According to GSM TS 05.02, there are two ways to enable CBCH: a) replace sub-slot number 2 of CCCH+SDCCH/4 (comb. V), b) replace sub-slot number 2 of SDCCH/8 (comb. VII). Unlike SDCCH/8 (case b), CCCH+SDCCH/4 can be allocated on TS0 only, and shall not use frequency hopping. This means that implementing CBCH support on SDCCH/8 would require much more efforts than on combined CCCH+SDCCH/4, as in last case CBCH messages can be received without the need to switch from idle to dedicated mode. This change introduces a new ccch_mode item, which should be used by the higher layers to indicate presence of CBCH channel on C0/TS0, so the PHY would enable decoding of CBCH messages on CCCH+SDCCH/4 (case a) in idle mode. Regarding to CBCH on SDCCH/8 (case b), it makes sense to extend the 'l1ctl_dm_est_req', so it would be handled in dedicated mode on request from the higher layers. Change-Id: Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
2018-10-03trxcon/scheduler: add CCCH/SDCCH mframe layouts with CBCHHarald Welte3-0/+238
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel (CBCH) is a downlink only channel, which is used to carry the short message service cell broadcast (SMSCB). CBCH is optional, and uses the same physical channel as SDCCH. More precisely, CBCH replaces sub-slot number 2 of SDCCH channels when enabled. This change introduces the CBCH enabled multi-frame layouts, and two separate logical channel types: - GSM_PCHAN_CCCH_SDCCH4_CBCH (lchan TRXC_SDCCH4_CBCH), - GSM_PCHAN_SDCCH8_SACCH8C_CBCH (lchan TRXC_SDCCH8_CBCH). Both logical channels are separately identified using the following Osmocom specific cbits: - TRXC_SDCCH4_CBCH - 0x18 (0b11000), - TRXC_SDCCH8_CBCH - 0x19 (0b11001). The reason of this separation is that we somehow need to distinguish between CBCH on C0/TS0, and CBCH on CX/TS0. Unlike TRXC_SDCCH8_CBCH, TRXC_SDCCH4_CBCH is enabled automatically (TRX_CH_FLAG_AUTO), so CBCH messages can be decoded on C0 while being in idle mode. Change-Id: Iad9905fc3a8a012ff1ada26ff95af384816f9873
2018-10-03firmware/layer1: add scheduler tasks for CBCHAlex Badea4-0/+36
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel (CBCH) is a downlink only channel, which is used to carry the short message service cell broadcast (SMSCB). CBCH is optional, and uses the same physical channel as SDCCH. More precisely, CBCH replaces sub-slot number 2 of SDCCH channels when enabled. This change introduces the following CBCH related tasks: - MF_TASK_SDCCH4_CBCH (CBCH on C0/TS0 SDCCH/4), - MF_TASK_SDCCH8_CBCH (CBCH on SDCCH/8), which are identified using the following Osmocom specific cbits: - MF_TASK_SDCCH4_CBCH - 0x18 (0b11000), - MF_TASK_SDCCH8_CBCH - 0x19 (0b11001). The only way to enable these tasks at the moment is to send L1CTL_DM_EST_REQ message with required cbits and tn. Change-Id: I1d7f02cba1cd8f6527360589d2d2747b6426f78b
2018-10-03firmware/layer1: inform about unhandled scheduler tasksVadim Yanitskiy1-3/+5
The mframe_task2chan_nr() is used to get the channel number (encoded according to 08.58 Chapter 9.3.1) corresponding to a given multi-frame task type. It makes sense to at least print some debug message in cases when there is no matching channel number for a given task type. Change-Id: I34587b6c67015513de35d85a7a3291f452ee7f3b
2018-10-03trxcon/l1ctl.c: properly handle indicated CCCH modeVadim Yanitskiy1-12/+29
The 'ccch_mode' enum from 'l1ctl_proto.h' to be extended in the near future in order to reflect persistence of CBCH. Thus it should be handled in a switch statement. Change-Id: I75e3b8deac1da296efb178e65ff6992b5c407b80
2018-10-03trxcon/sched_lchan_desc.c: fix wrong chan_nr for PDCHVadim Yanitskiy1-2/+2
According to GSM TS 08.58, chapter 9.3.1, channel number 0x08 describes sub-slot number 0 of SDCCH/8+ACCH. This is definitely wrong. In OsmoBTS we use an Osmocom specific extension for packet switched channels - 0xc0, so let's use it here too. Change-Id: I11925408d6e63baf1eac880839ecd717843fba6a
2018-10-02layer23/app_ccch_scan.c: omit dummy (fill) framesVadim Yanitskiy1-0/+32
In some conditions it's required to maintain continuous burst transmission (e.g. on C0). If there is nothing to transmit at a given moment, either a LAPDm func=UI fill frame, or a "dummy" Paging Request is used. In case of 'ccch_scan' application, they are useless. Let's detect and omit them. Change-Id: I6ccecb1a78bdac3e467bdc14b7a01afbe17aa53c
2018-10-02layer23/app_ccch_scan.c: hexdump unhandled PCH/AGCH messagesVadim Yanitskiy1-2/+3
Change-Id: I81d6558525e7f68c4fcd6c6272224d58532e2efb
2018-10-02layer23/app_ccch_scan.c: print pdisc in error messageVadim Yanitskiy1-1/+2
Change-Id: Ic88f5d4b263610a376bbb9729e882097393ef2be
2018-10-02layer23/app_ccch_scan.c: clean up System Information handlingVadim Yanitskiy1-59/+64
Change-Id: I8c2594920fcad8a3e346b938bd0c20409f4d01c9
2018-10-02layer23/app_ccch_scan.c: print 'new-line' char locallyVadim Yanitskiy1-3/+2
Change-Id: I03da1329501ce9b3c5cca49a1654ba68e9bb6a98
2018-10-02layer23/app_ccch_scan.c: clean up copy-pasted codeVadim Yanitskiy1-47/+1
By definition, 'ccch_scan' application is intended to be used for monitoring of CCCH channels on C0/TS0. There is no need to send RACH requests, therefore there is no need to care about the mobile allocation from SI1 message. Most likely, this "dead" code was copy-pasted from mobile application. Let's clean it up! Change-Id: I7c2f47cbc825a5e5a50863d842729d3d8408b9dd
2018-09-28trxcon/scheduler: fix Measurement Reporting on SACCHVadim Yanitskiy3-14/+211
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel accompanies either a traffic or a signaling channel. It has the particularity that continuous transmission must occur in both directions, so on the Uplink direction measurement result messages are sent at each possible occasion when nothing else has to be sent. The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not applicable on SACCH channels! Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else messages" besides Measurement Reports can be send by the MS on SACCH channels. However, in sub-clause 3.4.1 it's stated that the interval between two successive measurement result messages shall not exceed one L2 frame. This change introduces a separate handler for SACCH primitives, which dequeues a SACCH primitive from transmit queue, if present. Otherwise it dequeues a cached Measurement Report (the last received one). Finally, if the cache is empty, a "dummy" measurement report is used. When it's possible, a non-MR primitive is prioritized. Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d Related: OS#2988
2018-09-28trxcon/sched_prim.c: drop redundant tn validationVadim Yanitskiy1-4/+0
Change-Id: I553b4cc39b2efd7b60346160c57f01ee4cf066be
2018-09-28trxcon/scheduler: pass talloc ctx directly to sched_prim_init()Vadim Yanitskiy2-6/+5
Enforcing pointer to a 'trx_instance' structure is not flexible, because it is used as parent talloc context only. Change-Id: I5ab2ef5cea76f955bf72ef54541b3b75cdc2d23f
2018-09-28trxcon/scheduler: pass lchan state to sched_prim_dequeue()Vadim Yanitskiy3-7/+7
Having access to a logical channel state is required by the follow-up change, which will introduce a separate function for dequeuing SACCH primitives. Change-Id: Ibde0acf8e6be224b1007be707a636eaad68c8d36
2018-09-21layer23/l1ctl.c: replace printf() calls by LOGPVadim Yanitskiy1-2/+2
Change-Id: I863fb668500b2010dfef7a63217255fd010c06d7