summaryrefslogtreecommitdiffstats
path: root/src/host
AgeCommit message (Collapse)AuthorFilesLines
2023-03-19WIP: burst_process: Initial Fax (FA) frame supportlaforge/csd_decodeHarald Welte2-1/+67
Change-Id: Id4e198a79a56a7a100a84af9dc334b48242f6cfd
2023-03-19burst_process: Add GSMTAP outputHarald Welte1-19/+40
Change-Id: I9feb08fc0bb01b2fcf9b373360e1fab7f5031308
2023-03-05HACK: add burst_ind file containing /usr/share/common-licenses in ULHarald Welte1-0/+0
starts with Apache license. Change-Id: I85a9ab279ea8f4907586e408d4f5075e0088257f
2023-03-01HACK: WIP to post-process burst_ind .dat files with 9.6 NT CSDHarald Welte7-7/+553
Change-Id: I907a4e7dae76c4aef532df44b246b3a4f66c3043
2022-02-03host/osmocon: fix setting custom baudrate for CP210xVadim Yanitskiy1-5/+5
Sniffing requires higher baudrates, so in serial_up_to_eleven() we try first to set a non-standard baudrate=406250, which is known to work well with USB-UART converters based on FTDI's FT232 chip. Contrary to the FTDI's converters, CP210x based ones cannot be configured to use a non-standard baudrate directly. They require special mappings to be present in the EEPROM, so then using a setting baudrate=B460800 would actually make it use 406250. Normally, setting baudrate=406250 should fail for CP210x, so we fall-back to setting baudrate=B460800 if I_HAVE_A_CP210x is defined. However, for some weird reason, osmo_serial_set_custom_baudrate() *succeeds* setting non-standard baudrate=406250, what makes osmocon unable to communicate with the firmware. This looks like a regression in libosmocore, so let's try to work it around by moving the baudrate=406250 setting into the else block. Change-Id: I6c8a8227e5e5862a0f6b4121a6e67a9a2dda2a6d
2022-02-03layer23/ccch_scan: handle SI Type 1 in dump_bcch()Vadim Yanitskiy1-0/+14
Change-Id: I7a27d96070872a1b89809aab1a0d75608ef18d74
2022-02-03layer23/ccch_scan: fix unused variable in local_burst_decode()Vadim Yanitskiy1-2/+0
Change-Id: I647c39a7d75c3b05bf36eb6d07f934228d00cebf
2022-02-03[HACK] Add burst deciphering supportSylvain Munaut1-2/+69
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2022-02-03[HACK] host/layer23: Add local burst processing for cleartext burstsSylvain Munaut4-1/+269
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2022-02-03[HACK] host/layer23: Wire application logic for a simple demo sniff appSylvain Munaut1-3/+168
This listen for IMM.ASS and follows them Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2022-02-03[HACK] Disptach the received BURST_IND with a signalSylvain Munaut2-0/+44
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2022-02-03[HACK] Increase speed of l1ctl to 408250bps after bootVadim Yanitskiy1-0/+32
This is required to deal with the increased traffic of a passive listener Note that it break the 'auto-restart' of osmocon when active because the bootloader will send the prompt at 115200 baud and we won't see it ... Change-Id: I59e1f88e057c5a4e3605c55fb14436645339447b Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2021-12-14treewide: remove FSF addressOliver Smith73-292/+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: I73be012c01c0108fb6951dbff91d50eb19b40c51
2021-11-25gprsdecode: Don't leak memory in gsmtap_sendmsg()Harald Welte1-1/+1
Change-Id: Ib9e439ad6f24c573abb6da1523713a669898d23f Depends: libosmocore I106b09f2a49bf24ce0e8d11fd4d4ee93e9cafdf5 Related: OS#5329
2021-11-15logging: use meaningful default loglevelsPhilipp Maier2-20/+20
Some logging categories use LOGL_INFO or even LOGL_DEBUG. Lets set those to LOGL_NOTICE to have a less crowded default log output. Change-Id: I3faefccae2218b17bd942bc2afac7d8e515897b7 Related: OS#2577
2021-10-16layer23/osmocon: require libosmocore >= 1.5.0 in configure.acHarald Welte2-2/+2
This should give a meaningful error message if people use too old libosmocore. Change-Id: I7d9950b5eaa836ed1ac86045bd5364fed221e369
2021-10-08262-10 is "DB Netz AG" and not "DB Systel"Harald Welte1-1/+1
Change-Id: Idbce4bade4305fabbedcf15c5bd9253fbb371744
2021-07-04trxcon/scheduler: unify and enrich decoding error messagesVadim Yanitskiy4-15/+8
Regarding the removal of burst_mask2str() from the TCH/H handler, it does not make sense to print it because the mask is already shifted and an earlier logging should already contain this info. Change-Id: I42d20e2da73c21ca366dd246244cd716c8ccb459 Related: OS#4823
2021-06-16trxcon/trx_if: send NOPE indications if there is no burstVadim Yanitskiy1-5/+4
In a typical setup operating on the real radio interface, it's the duty of the transceiver (e.g. osmo-trx) to send NOPE.ind to the L1 implementation (e.g. osmo-bts-trx). However, in a virtual environment for ttcn3-bts-test we use a fake transceiver, which due to its simplicity cannot send NOPE indications itself. The lack of queues and buffering does not allow us to implement NOPE indications in fake_trx.py, so the easiest approach is to generate them from trxcon. Send TRXD PDUs without the burst bits, and fake_trx.py will tranform them info NOPE.ind for us. Change-Id: I1c7f1315b8ef44f651efd6a22fb5b854f65c0946 Related: SYS#5313, OS#1569
2021-06-16trxcon/scheduler: introduce and use struct sched_burst_reqVadim Yanitskiy10-162/+146
Similar to what we do in osmo-bts-trx, group everything related to an Uplink burst into a structure. Pass a pointer to this structure to the logical channel handlers. This makes the code easier to read, and facilitates sending NOPE indications to the transceiver (will be introduced in the upcoming patch). Get rid of sched_trx_handle_tx_burst(), and instead just call sched_trx_a5_burst_enc() directly from sched_frame_clck_cb(). Change-Id: Id45b27180c233fdc42ae1ef0b195554dd299a056 Related: SYS#5313, OS#1569
2021-06-16trxcon/scheduler: cosmetic: move TDMA frame number calculationVadim Yanitskiy1-7/+5
Change-Id: I79efdfa543d37889dc6749eb25aab4e1639749c6
2021-06-09host/layer23/ccch_scan: skip CCCH frames with wrong lengthVadim Yanitskiy1-0/+7
It's not clear why do we get frames with unexpected length, but we definitely should not crash. Just log and ignore them. Change-Id: I85392becbffdb3ba7365decfd8f3769abe3c02c7 Related: OS#5171
2021-04-29trxcon: fix legacy length expectations for TRXDv0 Rx PDUsVadim Yanitskiy1-1/+1
158 is basically: 8 + 148 + 2, where the last two are padding bytes sent by legacy TRXDv0 transceivers. We don't need them, so do not drop PDUs without these leggacy padding bytes. Change-Id: I6c0734bc4669ccde2a93940c9cf50fdbbd67cb00
2021-02-19tests: Replace deprecated API log_set_print_filenamePau Espin Pedrol1-1/+2
Change-Id: I9d24365d2be528477f1c190c698a81bfc7f2d2df
2020-11-30trxcon/scheduler: invalidate hard-coded Measurement resultsVadim Yanitskiy1-2/+2
This is what trxcon sends to the network before the first SACCH block is received from the higher layers. The indicated values are of course invalid because they're hard-coded. According to 3GPP TS 44.018, table 10.5.2.20.1: 0 The measurement results are valid 1 The measurement results are not valid Change-Id: I7da767e146aec7cef1de71e4d735d6a02b6c5642 Related: SYS#4918
2020-11-30trxcon/scheduler: clarify the content of Measurement resultsVadim Yanitskiy1-2/+15
Change-Id: I26546dcbc853166e351d00260936b1b9d584ae03
2020-11-30trxcon/scheduler: clarify Measurement results paddingVadim Yanitskiy1-2/+2
Table 10.5.2.20.0 "Measurement Results Contents" in 3GPP TS 44.018 is clear on what should be used as padding - '0**', i.e. zeroes. Change-Id: I4db6845c98aded10291134f416da98fd0f4f58e3
2020-11-25mobile: generate coredump and exit upon SIGABRT receivedPau Espin Pedrol1-2/+9
Previous code relied on abort() switching sigaction to SIG_FDL + retriggering SIGABRT in case the signal handler returns, which would then generate the coredump + terminate the process. However, if a SIGABRT is received from somewhere else (kill -SIGABRT), then the process would print the talloc report and continue running, which is not desired. Change-Id: Ied0f47378a5d348b857424adb5c874c1c093b485 Fixes: OS#4865
2020-11-25trxcon: generate coredump and exit upon SIGABRT receivedPau Espin Pedrol1-3/+13
Previous code relied on abort() switching sigaction to SIG_FDL + retriggering SIGABRT in case the signal handler returns, which would then generate the coredump + terminate the process. However, if a SIGABRT is received from somewhere else (kill -SIGABRT), then the process would print the talloc report and continue running, which is not desired. Change-Id: I6d80f3f2742d397e47f4f2970c951f2cf6d58172 Fixes: OS#4865
2020-11-25trxcon: Handle signal SIGABRTPau Espin Pedrol1-0/+1
The signal handler was coded as if it was handling SIGABRT, but the signal handler was not overwritten so it is actually used. Change-Id: I5c597f3410fc97be138db6f3976df59f393819b6
2020-11-11Use osmo_fd_*_{disable,enable}Harald Welte1-6/+6
Change-Id: If4c7f946852d153bd472e5c704f8d517d26ca22e Depends: libosmocore.git Idb89ba7bc7c129a6304a76900d17f47daf54d17d
2020-11-11Use osmo_fd_*_{disable,enable}Harald Welte1-14/+14
Change-Id: I65d37821873767e61a7eca029f9b30938a299683 Depends: libosmocore.git Idb89ba7bc7c129a6304a76900d17f47daf54d17d
2020-11-05trxcon/l1ctl_link: use osmo_store16be() in l1ctl_link_send()Vadim Yanitskiy1-3/+3
Change-Id: I96ca1c581d028a1f3c89c83a575fd8dbc9751962
2020-10-25osmocon: More decoding of tpu_debug (on compal/rffe_dualband)Harald Welte1-1/+61
Let's give a more human-readable decode of the TPU instructions, naming the TSPACT pin names as well as the device_id/strobe. Change-Id: Iac1ac74ac3e41cff9d3d347a167b43af58cc6e59
2020-10-23gsm48_rr: Don't swap ber with snr in "MON:" log lineHarald Welte1-1/+1
I was quite confused why I constantly see a bit error rate reported by gsm48_rr, while at the same time the actual L1CTL_DATA_IND did all state num_biterr == 0. So the log statement was broken ... Change-Id: I09bb6c606a8437b213bb444949c78a7c8a10542c
2020-10-21mobile: Use osmo_fd_setup() in script_lua.cHarald Welte1-4/+3
Change-Id: Ib6f97b9b8f3af63b81b92071b7fdb1fd55da89a5
2020-10-19trxcon/l1ctl: fix: send confirmation for TCH mode requestVadim Yanitskiy1-2/+5
Both REQ and CNF share the same message structure, so we can cheat a bit by changing the message type and sending it back. Change-Id: I6f403ed0506b4b1872361d9976d3186bfe514b52 Related: OS#4799
2020-10-18Use osmo_fd_setup() whenever applicable.Harald Welte6-46/+22
Change-Id: If9b636c295fc6b5349a54c70662f09efa616ee63
2020-10-18Use OSMO_FD_* instead of deprecated BSC_FD_*Harald Welte8-37/+37
Change-Id: Ibf64b18288b9109927035f650d6ef7ad9f15d688
2020-10-16fix trx_if_tx_burst(): do not drop Uplink bursts in TRX_STATE_RSP_WAITVadim Yanitskiy1-0/+2
Some commands, such as SETTA or SETPOWER, are expected to be sent when the transceiver is powered on. We should not drop Uplink bursts while waiting TRXC response. For now it's easier to comment out the state check completely, because the existing TRXC state machine is quite messy. Change-Id: Iefe6030200b11b29a5790d1f4aa4070ed1d9a493
2020-10-13layer23/cbch-sniff: fix: use Osmocom specific RSL channel numberVadim Yanitskiy1-2/+13
This way the layer1 can activate proper CBCH task and send us CBCH block with proper RSL channel number, so they do not end up being routed to LAPDm and rejected there. Change-Id: Ib1d5c99587202a9d94aeb7b63de7ae8c4fb15af0
2020-10-13layer23/cbch-sniff: fix: do not blindly assume presence of CBCHVadim Yanitskiy1-1/+1
We cannot blindly assume that CBCH is present on TS0/SDCCH4 before decoding CBCH Channel Description in System Information Type 4. Change-Id: Ie8ce572df292d0b03c0f743bcf26184619176321
2020-07-31layer23/mobile: implement handling of TCH test loop commandsVadim Yanitskiy7-15/+239
For more information, see 3GPP TS 44.014, sections: - 5.1 "Single-slot TCH loops", and - 8 "Message definitions and contents". This feature has nothing to do with the Mobility Management, so let's handle GSM48_PDISC_TEST messages in the Radio Resources layer implementation (gsm48_mm.c -> gsm48_rr.c). Change-Id: If8efc57c7017aa8ea47b37c472d1bbb1914389ca
2020-07-30layer23/mobile: fix a memory leak (msgb) in gsm48_rr_data_ind()Vadim Yanitskiy1-1/+3
Change-Id: I55dcccf5b7d27d012908759954182eaec434d26b
2020-07-30layer23/mobile: fix wrong message type in gsm48_rr_tx_rr_status()Vadim Yanitskiy1-1/+1
Change-Id: I57c6a4e1e725da52c50e2a28e56627a3f3827c62
2020-07-29layer23/mobile: cosmetic: use GSM48_PDISC_TEST from gsm_04_08.hVadim Yanitskiy1-1/+1
Change-Id: Ie1f14b37f6138f5a019a25bdbc8a3531418df6c2
2020-07-13trxcon/scheduler: reduce default Uplink burst scheduling advanceVadim Yanitskiy1-2/+2
In general, premature scheduling of to be transmitted bursts inevitably increases the time delay between Uplink and Downlink. The more we advance TDMA frame number, the greater gets this delay. 20 TDMA frames is definitely more than a regular transceiver needs to pre-process a burst before transmission. Change-Id: Ia9b142b59d95f2cd7b2394596cf72c0bcd36d711 Related: OS#4487
2020-07-12trxcon/scheduler: check TDMA frame order, drop out of order burstsVadim Yanitskiy1-5/+26
When running together with fake_trx.py (mostly used back-end), it is currently possible that Downlink bursts are received in a wrong order if more than one transceiver is configured (multi-trx mode). This is how it looks like: DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0 DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0 DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632) so here a burst with TDMA fn=633 was received earlier than a burst with TDMA fn=632. The burst loss detection logic considered the latter one as lost, and substituted it with a dummy burst. When finally the out-of-order burst with TDMA fn=632 was received, we got the large number of allegedly elapsed frames: ((632 + 2715648) - 633) % 2715648 == 2715647 Given that late bursts get substituted, the best thing we can do is to reject them and log an error. Passing them to the logical channel handler (again) might lead to undefined behaviour. Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772 Related: OS#4658, OS#4546
2020-07-08trxcon/scheduler: fix subst_frame_loss(): do not compensate too muchVadim Yanitskiy1-0/+1
It's not something that we should be trying to fix, if the whole TDMA multi-frame is lost. For some yet unknown reason, sometimes the difference between the last processed TDMA frame number and the current one is so huge, so trxcon eats a lot of CPU trying to compensate nearly the whole TDMA hyper-frame: sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632) Let's just print a warning and do not compensate more than one TDMA multi-frame period corresponding to the current layout. Change-Id: I56251d0d2f6fa19195ff105d3bdfbc22df6db8cd
2020-07-07trxcon/scheduler: subst_frame_loss(): print current TDMA fnVadim Yanitskiy1-2/+2
Change-Id: I3d769ba3cbadc19bac0b25224460af8f06d0d776
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-01 22:12:20 +0000