summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
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
2018-08-24jenkins.sh: Don't only build-verify layer23 but all other host programs, tooHarald Welte1-4/+7
Change-Id: I204d19ce3ac085add92242c0a03bffb9abc9113d
2018-08-23osmocon: fix use of an initialized variableStefan Sperling1-1/+2
osmocon.c: In function ‘read_file’: osmocon.c:317:3: warning: ‘fd’ may be used uninitialized in this function Change-Id: If07c58d5b55c18c05345607064eace02748935f8
2018-08-17trxcon/sched_clck.c: fix time delta calculationsStefan Sperling2-35/+31
Use osmo_clock_gettime() to read the monotonic clock instead of gettimeofday() which could drift backwards. This requires switching the scheduler clock from struct timeval to struct timespec. Expand some variables to 64 bits in order to keep types used in calculations compatible. The previous implementation unconditionally subtracted microsecond values from different time measurements, causing overflow if the current measurement was taken in less of a fraction of a second than the past measurement. Use timespecsub() for the subtraction instead which accounts for fractions of a second correctly. Change-Id: Ic93f90685c6d6dc28dfc4ad48c998e0eac113cf8 Related: OS#3467
2018-08-15trxcon/scheduler: get rid of useless lchan->rsl_modeVadim Yanitskiy5-26/+5
This field of the logical channel state structure was not used at all as there is nothing related to A-bis / RSL in trxcon itself. Change-Id: Iec1abf777a74cf57deadafa95e2337cba5d02842
2018-08-15trxcon/scheduler: fix: properly generate BFI for TCH/HVadim Yanitskiy1-4/+10
When relying on GSM 04.08 channel mode (GSM48_CMODE_*), one should distinguish between Bm (full rate) and Lm (half rate) channels. This change prevents the scheduler from generating TCH/F BFI instead of TCH/H BFI on the corresponding channels. Change-Id: I4547aa7f6d38637692fef8a0122e85fb52039a46
2018-08-15trxcon/scheduler: pass lchan to sched_bad_frame_ind()Vadim Yanitskiy4-14/+10
Instead of passing the information about a logical channel, it makes sense to pass the pointer to its state where everything is stored. This approach would allow to avoid adding more arguments every time, e.g. in case of AMR. Change-Id: I91fe86fef43aac68776a58c9acc37ef2a9ee8042
2018-08-14trxcon/sched_prim.c: properly handle both TCH/H and FACCH/H primsVadim Yanitskiy3-6/+86
Initially it was assumed that FACCH prioritization should be done in the same way for both TCH/F and TCH/H. Moreover, it was not possible to confirm this, because TCH/H was (and still) not implemented yet. But according to the specs: - unlike FACCH/F, FACCH/H transmissions shall be aligned within a multiframe, i.e. can only be initiated on particular frame numbers (see GSM 05.02, clause 7); - unlike FACCH/F, a FACCH/H frame steals two TCH/F frames; so the TCH/H (including FACCH/H) primitives should be handled separately from the TCH/F (including FACCH/F) primitives. Change-Id: I9b59f60e1cbac8fb8fd557b6c67b5e376c0a6bbb
2018-08-14trxcon/sched_prim.c: refactor prim dequeuing logicVadim Yanitskiy1-55/+83
The previous primitive dequeuing logic (especially for TCH/F channels) was a bit complicated, and it could not be possible to reuse the existing code parts in the upcoming implementation of both TCH/H and FACCH/H channels without changing anything. In particular, this change introduces two internal functions: - prim_dequeue_one(), which merely dequeues a primitive of a given channel type (e.g. TRXC_SDCCH4_0); - prim_dequeue_tch(), which dequeues either a FACCH, or a speech TCH primitive of a given channel type (Lm or Bm). So the logic of the TCH/F prim dequeuing function has become cleaner, and the upcoming TCH/H prim dequeuing function, where FACCH/H prioritization is more complex than FACCH/F, will reuse the introduced functions. Change-Id: Ib82ad2480ab1bc6b1df9576eb2bf5acbd398bf66
2018-08-14trxcon/sched_trx.h: add missing parentheses to PRIM_IS_*Vadim Yanitskiy1-2/+2
Change-Id: Ifa7d9f806b3f18f2dfec931252f5119441b30e8a
2018-08-11layer23: Replace all instances of strncpy() by osmo_strlcpyHarald Welte7-23/+15
This gives us working/safe zero termination without overflowing the destination string size. Change-Id: Ica6098ceba2bd01ce3b216085442cc5eed0ca507
2018-08-11layer23: Fix possible buffer overflow writing NUL beyond end of stringHarald Welte1-1/+1
settings.c: In function ‘gsm_random_imei’: settings.c:188:26: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=] sprintf(rand + 8, "%07ld", random() % 10000000); ^ settings.c:188:2: note: ‘sprintf’ output between 8 and 9 bytes into a destination of size 8 sprintf(rand + 8, "%07ld", random() % 10000000); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: Id949487111235cd4af5ff068f1dce2f4b0801480
2018-08-11layer23: Use osmo_strlcpy() to avoid non-terminated stringsHarald Welte3-3/+3
settings.c:191:2: warning: ‘strncpy’ output may be truncated copying 15 bytes from a string of length 15 -Wstringop-truncation] strncpy(set->imeisv, set->imei, 15); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC subscriber.o CC support.o CC transaction.o CC vty_interface.o CC voice.o CC mncc_sock.o CC primitives.o mncc_sock.c: In function ‘osmo_unixsock_listen’: mncc_sock.c:318:2: warning: ‘strncpy’ specified bound 108 equals destination size [-Wstringop-truncation] strncpy(local.sun_path, path, sizeof(local.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC script_lua.o vty_interface.c: In function ‘cfg_gps_device’: vty_interface.c:1144:2: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] strncpy(g.device, argv[0], sizeof(g.device)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AR libmobile.a Change-Id: Id52978f3bf7a8abea62237d7c32f8f87e1bb34a1
2018-08-11layer23: Fix compiler warnings about string operation truncationHarald Welte1-4/+4
This fixes the below warnings: gsm322.c: In function ‘gsm322_cs_ba_range’: gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(lower_text, gsm_print_arfcn(index2arfcn(lower)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] gsm322.c:3481:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(higher_text, gsm_print_arfcn(index2arfcn(higher)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gsm322.c: In function ‘gsm322_cs_powerscan’: gsm322.c:2862:2: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(s_text, gsm_print_arfcn(index2arfcn(s)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gsm322.c:2863:2: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(e_text, gsm_print_arfcn(index2arfcn(e)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: I08f938cfb2589574e90d5831a00c0140f71d5bfe
2018-08-11layer23: Fix compiler warning about snprintf buffer too smallHarald Welte1-1/+1
gsm322.c:366:22: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=] sprintf(string, "-%d", 110 - rxlev); ^ gsm322.c:366:2: note: ‘sprintf’ output between 3 and 6 bytes into a destination of size 5 sprintf(string, "-%d", 110 - rxlev); Change-Id: I7b19fef89ba0cb0c1edbdd62c46ad8395e44145b
2018-08-11layer23: fix unaligned store in osmo_send_l1()Harald Welte1-5/+2
This fixes the following alignment issue uncovered by asan: l1l2_interface.c:169:7: runtime error: store to misaligned address 0x61600001ab99 for type 'uint16_t', which requires 2 byte alignment 0x61600001ab99: note: pointer points here 00 00 00 00 00 00 06 0a 01 19 19 40 18 00 07 00 01 03 49 06 15 00 40 01 c0 00 00 00 00 00 00 00 ^ Change-Id: Ie65b428107d35bac99bc870fdbc4dc509ca2f33c
2018-08-11layer23: Add --enable-sanitize and --enable-werror configure flagsHarald Welte1-0/+27
We use this in the network-side Osmocom projects (CNI) and it's useful to have the same flags also for the OsmocomBB host software. Change-Id: I45800c937d665fdbd2dd6b0cee38408f587f1a9f
2018-08-02trx_toolkit/fake_trx: introduce basic path loss simulationVadim Yanitskiy3-0/+123
This change introduces a couple of new CTRL commands for path loss simulation, in particular a possibility to drop some amount of bursts according to some TDMA frame period, separately for both Uplink and Downlink directions. Examples: FAKE_DROP 4 - drop 4 consistent (period=1) bursts, FAKE_DROP 16 2 - drop 16 even bursts (period=2). Change-Id: Ib210138a03e2377c79875a4ff2f2bb58a43cfa46 Related: OS#3428
2018-08-02trx_toolkit/burst_fwd.py: separate burst preprocessingVadim Yanitskiy1-15/+24
This change separates burst preprocessing (i.e. both RSSI and ToA calculation) from BurstForwarder.transform_msg() because it's not actually related to the message transformation process. Change-Id: Ia7ad970593f38d9a9401975eb6dae67cd0c94e11
2018-07-28trxcon: make both Valgrind and trxcon happyVadim Yanitskiy1-0/+5
Change-Id: If5c349082757bb30408477b1ef528934eded0232
2018-07-24trxcon/scheduler: fix: check primitive len before encodingVadim Yanitskiy3-3/+29
We used to trust (and still doing this) the messages coming from L1CTL interface too much, and not to check the primitive length before passing the payload to the libosmocoding API. As was discovered and described in OS#3415, sending a L1CTL message (either DATA_REQ, or TRAFFIC_REQ) with an incorrect length (lower than expected) may cause heap overflow. Let's explicitly check a primitive before encoding, and drop it if its length doesn't match the expected value(s). Change-Id: I258ee9f6d0124b183b1db23a73f1e523fcea89a8 Fixes: OS#3415
2018-07-23Move from libc random() to osmo_get_rand_id (2nd attempt)Holger Hans Peter Freyther8-8/+61
When starting multiple mobile in the same second, the libc random number generator will be seeded to exactly the same value. The random bits inside the RACH request(s) will be exactly the same across multiple mobile and when the channel fails they all pick the same randomized back-off timing. Use stronger random numbers and replace all calls to random(2) with osmo_get_rand_id. Add a fallback to try random(). [v2: Add helper to make sure the result is int and between 0 and RAND_MAX] Change-Id: Icdd4be88c62bba1e9d954568e48f0c12a67ac182
2018-07-21trx_toolkit/trx_sniff.py: fix memleak: don't store packetsVadim Yanitskiy1-1/+1
The Scapy itself was the actual cause of continuously growing memory consumption. It was configured to store the captured packets, what isn't required for this tool. Change-Id: I0c6d9b76398e148b7febd94aa37aa2fa22d19b3f
2018-07-17mobile: use osmo_init_logging2 with proper talloc contextVadim Yanitskiy1-13/+5
Change-Id: I231ac9987ff3c13fafcd272b7d9aae3938ab5972
2018-07-17Revert "Move from libc random() to osmo_get_rand_id"Vadim Yanitskiy4-18/+5
It was decided to migrate to osmo_get_rand_id() and use random() as a fall-back. But there is a critical difference between both functions: osmo_get_rand_id() fills an input buffer with random bytes (0x00 - 0xff), while *random() returns a value in range between 0 and RAND_MAX. osmo_get_rand_id() was used in a wrong way, so in some cases we could get a negative value (how about IMEI starting from '-'?), what isn't expected in many cases and could lead to unexpected behaviour and segmentation faults... This reverts commit 6d49b049ee304f1ea0e4801df61e69713b01f0f8. Change-Id: I7b2a8a5c63cf64360a824926a2219fd7e419b1bb
2018-07-16trxcon: fix tail bits at the front of Access burstPiotr Krysik1-1/+10
Currently Access Burst generated by trxcon has 8 zero bits at the beginning. According to the 3GPP 05.02 specification (Chapter 5.2.7 Access burst) custom 8-bit extended tail bits sequence should be used: (BN0, BN1, BN2 ... BN7) = (0,0,1,1,1,0,1,0) After this fix trxcon sets correct 8-bit sequence at the front of Access burst. Change-Id: I1f624e783de6c585d2e292965c9e5810b0a4f27d
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 13:05:57 +0000