summaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2018-10-03mobile: add MNCC socket path to settingsVadim Yanitskiy4-6/+32
Previously the MNCC socket path was generated automatically, using concatenation of the '/tmp/ms_mncc_' prefix and MS name. Let's allow user to specify this manually, keeping a similar generation method for default value. Change-Id: I643356ac579bc5e765f668265ec803b22a73739c
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
2018-09-21layer23/l1ctl.c: drop redundant printf() callVadim Yanitskiy1-1/+0
Change-Id: I02bc581afb5a76c51fdef50ed40e2669c3eb3f2e
2018-09-16lua: Expose API to trigger a network reselectionHolger Hans Peter Freyther3-0/+27
Same as the "network search" VTY command but implemented as primitive and exposed to LUA. Change-Id: I096233a2ca9dd7daa358cebed0523cb8c0dbf593
2018-09-16Add includes so the file can be included by itselfHolger Hans Peter Freyther1-0/+5
Add missing dependencies to make this file be includeable as the only file. Change-Id: I05b5f689f389b89deb5ff49507486b246111fc59
2018-09-16Install to /bin as it doesn't require special privileges..Holger Hans Peter Freyther1-1/+1
This makes packaging the binary for the gsm tester more easy. Change-Id: Ibe572a4c17871785b623e70acc7f5da056f945e5
2018-09-16trxcon/scheduler: add TCH/H channel supportVadim Yanitskiy4-7/+331
Change-Id: Ibb2a0850692c5ff86b13b820af10b12085589e67
2018-09-16trxcon/scheduler: introduce TCH/H TDMA frame mapping helpresVadim Yanitskiy5-16/+207
Unlike xCCH, TCH/H channels are using block diagonal interleaving, so every single burst carries 57 bits of one traffic frame, and 57 bits of another one. Moreover, unlike TCH/F where both traffic and FACCH/F frames are interleaved over 8 bursts, a FACCH/H is interleaved over 6 bursts, while a traffic frame is interleaved over 4 bursts. This is why a TCH/H burst transmission can't be initiated on an arbitrary TDMA frame number. It shall be aligned as of stated in GSM 05.02, clause 7, table 1. This change introduces two basic functions: - sched_tchh_block_map_fn - checks if a TCH/H block transmission can be initiated / finished on a given frame number and a given channel type; - sched_tchh_block_dl_first_fn - calculates TDMA frame number of the first burst using given frame number of the last burst; and some auxiliary wrappers to simplify the usage of sched_tchh_block_map_fn(). Change-Id: Iaf4cb33f1b79df23f8a90c8b14ebe0cd9907fbb9
2018-09-16trxcon/scheduler: introduce TDMA frame math helpersVadim Yanitskiy3-12/+16
The 'normal' math operations, such as addition and substraction, are not applicable for TDMA frame numbers because they may result in out-of-range values. Having TDMA frame math helpers in a single place would allow one to avoid possible out-of-range result mistakes. Change-Id: Ibb66ba846cc3d6c2eaa88414569e5f3751128047
2018-09-15trxcon/scheduler: fix: don't send BFI in GSM48_CMODE_SIGN modeVadim Yanitskiy2-4/+11
GSM48_CMODE_SIGN means 'signaling only', so we shall not send bad frame indications in this state. Instead, it makes sense to send dummy L2 frames like we do for xCCH channels. Change-Id: Ie39d53522cafab265099076b3194fa96aff217ba
2018-09-14trxcon/scheduler.h: share FRAME_DURATION_uS definitionVadim Yanitskiy3-3/+4
Change-Id: I88be6088141af6bac8d34844b71193bfef51ad31
2018-09-07trxcon/l1ctl.c: refactor Timing Advance handlingVadim Yanitskiy2-8/+6
Change-Id: I0e4f18173347e3a7cb875f95d796e8ea20bfc4bf
2018-09-07trx_toolkit/fake_trx: drop Timing Advance range limitationVadim Yanitskiy1-6/+0
Despite the correct range of Timing Advance value is [0..63], there is a special feature in OsmocomBB which allows one to simulate the distance between both MS and a BTS by playing with the signal delay. So, let's drop the range limitation. Change-Id: I8fd2a2ab7784b38bde5ebcfd0359b7e2cb53f5a7
2018-09-07trxcon/trx_if.c: drop Timing Advance range limitationVadim Yanitskiy1-7/+3
Despite the correct range of Timing Advance value is [0..63], there is a special feature in OsmocomBB which allows one to simulate the distance between both MS and a BTS by playing with the signal delay. This is why a signed 'int8_t' type is used in L1CTL protocol. No need to limit the range, just forward it to TRX. Change-Id: I06774b315b8451bf14083da6b2849d6e8594abc8
2018-09-07common/l1ctl.c: fix: use signed type for TA in l1ctl_tx_param_req()Vadim Yanitskiy2-2/+2
Despite the correct range of Timing Advance value is [0..63], there is a special feature in OsmocomBB which allows one to simulate the distance between both MS and a BTS by playing with the signal delay. It was discovered that l1ctl_tx_param_req() is using an unsigned 'uint8_t' type for Timing Advance value, while other code and L1CTL protocol is using signed 'int8_t'. This may result in distortion of negative values, so let's fix this! Change-Id: I6ee42b5fa2ca9ebe187f0b933465c49f840a55c2
2018-09-07trxcon/trx_if.c: drop unused SETPOWER and ADJPOWERVadim Yanitskiy2-28/+0
I am not sure we need the both control commands, as every burst on DATA interface has a header that includes TX power. Change-Id: Id14603e71df6dedb5a843bb3e20a320192dbca3d
2018-09-07trxcon: distinguish between unimplemented and unknown messagesHarald Welte1-0/+10
Let's differentiate between 'expected' unimplemented messages like L1CTL_NEIGH_PM_REQ and truly unknonw message types. Change-Id: Id76993056fb514e6fb0242d505205316c61bb965
2018-09-06firmware/l23_api.c: cosmetic: use proper format specifierVadim Yanitskiy1-1/+1
The '%u' format specifier should be used for unsigned values. Change-Id: I1108c34e864304126e581d30b75bbd95b93f60b8
2018-09-06trxcon/l1ctl.c: fix: handle ARFCN from L1CTL_DM_EST_REQVadim Yanitskiy1-0/+10
A BSC may allocate a dedicated channel on any ARFCN, not necessary on the same one where a mobile station has requested this channel. For some reason, the ARFCN info of L1CTL_DM_EST_REQ message was not handled by trxcon. Let's fix this. Related: OS#3526 Change-Id: I16ed5c64236c159bfa39002b05094c1f6c171f6b
2018-09-06layer23: Use osmo_sock_unix_init_ofd() from libosmocoreHarald Welte3-105/+11
We don't need to hand-code unix domain socket initialization but can simply use our library function for it. As an added benefit, the library code already contains corner case handling for non-NUL terminated unix domain socket path. Change-Id: I57c724c78dbbbce0546ebe914e370f32c8c89703
2018-09-06osmoload: Use osmo_sock_unix_init_ofd() from libosmocoreHarald Welte1-20/+4
We don't need to hand-code unix domain socket initialization but can simply use our library function for it. As an added benefit, the library code already contains corner case handling for non-NUL terminated unix domain socket path. Change-Id: Iedcec4591cf0fcbd6f956ed022169eae10a9b16e
2018-09-06osmocon: Use osmo_sock_unix_init_ofd() from libosmocoreHarald Welte1-41/+4
We don't need to hand-code unix domain socket initialization but can simply use our library function for it. As an added benefit, the library code already contains corner case handling for non-NUL terminated unix domain socket path. Change-Id: I3ab69a971be555c9f9b5b7a7e5da53008a119504
2018-09-06osmocon: Add --enable-{werror,sanitize} configure flagsHarald Welte1-0/+27
Change-Id: I6a69ca514406fa18684ca2621be45f87ee8d64a4
2018-09-06trxcon/trx_if.c: use proper format specifiersVadim Yanitskiy1-4/+4
The '%u' format specifier should be used for unsigned values. Change-Id: I90200581036f8ab3969dd68664688f98cd2d3618
2018-09-06trxcon: avoid arfcn / band_arfcn naming confusionVadim Yanitskiy3-32/+32
In the most cases an ARFCN value is stored together with some flags (e.g. DL/UL flag, DCS flag), so it should be taken into account e.g. when printing. Let's use the proper naming. Change-Id: I0b7634c80986dbff9d0da421c6a044cd36c9fd01
2018-09-06trxcon/l1ctl.c: print timeslot number from L1CTL_DM_EST_REQVadim Yanitskiy1-5/+4
Change-Id: If092743c32b7a6f5da7c8339b0f7b92ccf8a7a8b
2018-09-06trxcon/l1ctl.c: drop meaningless 'tn > 7' checksVadim Yanitskiy1-10/+0
There is no need to check the range of timeslot number, which is decoded from GSM 08.58 channel number (9.3.1) by applying 0x07 mask, because any result of this operation is always within the correct range. Change-Id: Ib84417099d303bd3ae3557f48a5c40b812c6cdfc
2018-08-27cosmetic: add commandline helpPhilipp Maier1-1/+24
There is no helptext for the commandline options, which makes it difficult for new users to use the program. - Add commandline help Change-Id: I8d04644342acd64432742f96e32dc9f2e0e91c20
2018-08-27cosmetic: fix typoPhilipp Maier1-1/+1
Change-Id: Ib9c5cb1aa0aaf12b68f9d93f9ce9a27037b84a56
2018-08-24Allow lua code to register a fd for reading with the runtimeHolger Hans Peter Freyther1-0/+103
To have bi-directional communication we can pass credentials to the registry server and now we can register a callback when the registry is sending data to us. The callback needs to return if the fd should continue to be selected as I found no way to push the userdata as parameter on the stack. Lua code will look like: local host, port = "www.osmocom.org", 80 local tcp = socket.tcp() tcp:connect(host, port); tcp:send("GET / HTTP/1.0\r\n\r\n"); local cb = function() local s, status, partial = tcp:receive() print(s) if status == 'closed' then tcp:close() return 0 end return 1 end local foo = osmo.register_fd(tcp:getfd(), cb) Change-Id: I8254bdda1df2f8fe0a5eac894b931e7de5b426df
2018-08-24Forget about the callback after use and cancellationHolger Hans Peter Freyther1-0/+5
Don't try to unref something else after we have given up our spot in the table. Change-Id: I4e8db297e816d3d07a46147d5d3bdc0e8fae6c9a
2018-08-24osmocon: fix read buffer overrun in romload_prepare_block()Stefan Sperling1-1/+1
Address sanitizer triggered when trying to chainload firmware: ==18466==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x631000027850 at pc 0x7f5b94cfb733 bp 0x7ffe33e1ae30 sp 0x7ffe33e1a5d8 READ of size 1014 at 0x631000027850 thread T0 #0 0x7f5b94cfb732 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732) #1 0x563db4293e6e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 #2 0x563db4293e6e in romload_prepare_block osmocom-bb/src/host/osmocon/osmocon.c:473 #3 0x563db429541f in handle_read_romload osmocom-bb/src/host/osmocon/osmocon.c:959 #4 0x563db429541f in serial_read osmocom-bb/src/host/osmocon/osmocon.c:1168 #5 0x7f5b94722c83 in osmo_fd_disp_fds libosmocore/src/select.c:217 #6 0x7f5b94722f84 in osmo_select_main libosmocore/src/select.c:257 #7 0x563db4293b1c in main osmocom-bb/src/host/osmocon/osmocon.c:1525 #8 0x7f5b942b9b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #9 0x563db4293c79 in _start (prefix/sbin/osmocon+0x1c79) 0x631000027850 is located 0 bytes to the right of 77904-byte region [0x631000014800,0x631000027850) allocated by thread T0 here: #0 0x7f5b94d60b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x563db4294d65 in read_file osmocom-bb/src/host/osmocon/osmocon.c:314 Change-Id: Ie2955e11dd1af75574536774ef7ddf88ddf1fe8b
2018-08-24osmo_mcast_sock: make sure SO_REUSEADDR is appliedPhilipp Maier1-2/+3
virtphy uses UDP multicast to communicate with its osmo-bts-virtual counterpart. At the momemnt SO_REUSEADDR is not applied for those multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This makes prevents the proper function of UDP multicast. - Make sure OSMO_SOCK_F_UDP_REUSEADDR is set Change-Id: Ia1014ac5e0522e77178249cdc6398dec2168bffe Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874 Related: OS#3497
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-23 19:49:29 +0000