The following issue was found by Andreas Bogk. The l1ctl_info_dl
struct is supposed to be packed but we included the struct gsm_time
which was not packed and added three bytes of padding. Pack the
structure to avoid that.
We now
* properly decode the L1 header of SACCH frames
* properly hand-off SACCH payload such as SI5/SI6
* display the summary of the GSMTAP and SACCH_L1 dissectors in the protocol tree
* use GSMTAP for uplink frames (generated by layer23; sent to L1)
* only use GSMTAP if the user specifies the '-i dstip' arguments
* properly encode the GSMTAP channel type
* requires GSMTAP protocol version 0x02 (see next commit for wireshark patch)
* print HDLC packets received from L2
* print Tx MAC block as it is written to DSP API RAM
* ensure we don't msgb_free() a message that we've enqueued for l1s
Tx support is considered experimental and potentially dangerous.
Thus, the default build of the firmware does not have Tx support
enabled.
If you want Tx support, compile with -DCONFIG_TX_ENABLE by uncommenting
the apropriate line in Makefile.inc
L1 and L2 now pass UI frames like BCCH and CCCH downlink up into
L3, which detects an IMMediate ASSignment command and instructs
the L1 to switch to SDCCH/4.
From this point on, SDCCH/4 and SACCH4/C messages end up in our
L2 LAPDm implementation and are forwarded to L3.
Using the following changes, it is now possible to receive the PCH and AGCH
messages in the PC-side layer3, as well as trigger RACH sending inside the phone
from the PC:
* merge l1_dedic_mode_data_ind, l1_dedic_mode_data_req and l1_ccch_info_ind into l1_data_ind
* add partial LAPDm implementation (layer2/src/lapdm.c)
* introduce RSLms between LAPDm and L3 (layer2/src/osmocom_rslms.c)
* use new layer1 header field of msgb
* tx_ph_rach_req() and tx_ph_data_req() to send data from PC to target
* implement DEDIC_MODE_DATA_REQ on firmware side
This enables the layer2 to identify on which channel
(BCCH/CCCH/SDCCH/TCH/...) the respective message was received.
* Encode MFrame Task Number + SACCH info in 'p3' parameter
* Generate channel number and link identifier
* Decode channel number in layer2 program
The idea of the third parameter is that it can be specified on a
tdma_schedule_set() level. The multi-frame scheduler can thus use
it to pass some context information into the l1s_{cmd,resp}_*()
functions, such as the MF TASK and whether or not it is SDCCH or
SACCH.
Holger Hans Peter Freyther
Harald Welte