Age | Commit message (Collapse) | Author | Files | Lines |
|
lchans under a BORKEN TS should be counted as used just as BORKEN
lchans under a normal TS.
Change-Id: Ic3dbc6b176d5dcff7ed2589bb875abf93e9f7ab0
|
|
This is a corner case but still we should count the events to
know when is this happening. And for the number of paging requests
to match the number of paging responses.
Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
|
|
Now we can monitor the situation with the BORKEN lchans and TS in our
BTS's over time.
Change-Id: I427bbe1613a0e92bff432a7d76592fe50f620ebe
|
|
Change-Id: Ic87c325a73690ede1b81b4d33bac65a1a4beea2d
|
|
Copy the RPM spec file from:
https://build.opensuse.org/project/show/home:mnhauke:osmocom:nightly
Related: OS#4550
Change-Id: Id0f7568953cbf55d4a2278cf088bb37af0d19d78
|
|
I notice that some merges seem to have missed updating the
bsc_vty_reference.xml file. Re-generating it from current master yields these
changes.
Change-Id: I75269cbed8dd62be23293fd2c1470af6f61e6ad2
|
|
Not sure why this specific message is ERROR while similar ones around
are DEBUG. So let's fix this disparity by demoting this message level.
Change-Id: I655d4555f037def354aacbc5f089794f5fe811ed
|
|
The "CHAN RQD: reason" message is purely informational and is a part
of normal operation. Nothing to NOTICE there. Let's demote this to
DEBUG.
Change-Id: I325f2beb3248ed8eb25d1d8494c3868c5be4b758
|
|
We're sending multiple RESET messages to establish a conection with
an MSC and MSC can (and often will) respond with multiple RESET ACK
messages. We should not treat this as an ERROR as it used to be
in the original code.
Change-Id: I109d638d5167e24f0357e3541415b9e7269aa5d1
|
|
Change-Id: If8f76af4d1e0eb2d7b3534e620e2816cdbbe0b7d
|
|
The "new SIGTRAN connection" message is sent on every new transaction
between an MS and MSC, i.e. A LOT during normal operation. Let's
demote it to INFO and clarify that this is about SCCP connection
instead of a generic SIGTRAN term.
Change-Id: I711b70ae84aa98f43ea3f807ea5c8464b71ca6bb
|
|
"Paging request failed" message can be logged e.g. when we're already
paging this subscriber which means we get hundreds of these messages
in a perfectly normal situation. Let's demote this to INFO and adjust
the wording.
Change-Id: I97214796906ac599338e87b2b4b5465ab6b2447a
|
|
Change-Id: I771ef866aba6af9e2a10a06e593eef78b7405377
|
|
Change-Id: Ifb84d7ceddc772e3e1ae59c8d5859b6be6f1b4eb
|
|
Change-Id: I29e42687ac084a60007f0b1ec6ec0a102fb4007f
|
|
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
|
|
Without a properly allocated MSC struct, touching counters crashes
the test.
Change-Id: I7498d2891259be9b532845627f14ac75e98e703e
|
|
Addresses CID 210261.
Change-Id: Ic7e7c92c5b9ff696fa7f4cd0d69451cd22333f71
|
|
It should be fine if we receive PDCH_ACT_ACK late. We should just go
into the PDCH state as normal.
Change-Id: If816b681e0b2e76fb7122cf211e15eeee92451ee
|
|
In the lchan_fsm_borken() we request to change the state to
LCHAN_ST_WAIT_RF_RELEASE_ACK in response to a late
LCHAN_EV_RSL_CHAN_ACTIV_ACK event but this transition is prohibited
by the FSM definition, so the channels stay in the BORKEN state
forever. :(
Change-Id: I17a9b935a116eb842fd0239ef53d73bef35e6511
|
|
Change-Id: Ideba357678a59e3f314a0d618d181a233a43b4de
|
|
Change-Id: Ie6debad36a49005676ff47eda644c90eee5dc461
|
|
Explanation from Harald:
There are plenty of things that can happen above the bare SCTP/M3UA
connection which can happen, such as SCCP or MTP level routing
problems.
The fact that a MSC responds to a BSSMAP reset tells us that all of
the underlying SS7 transport network is operational and the MSC
responds to us.
Go draw an IP analogy: Saying "SIGTAN connection up" here is like
saying "Ethernet link up" when you get an ICMP response.
Change-Id: If9d37c94f2f2b6cffef97f445774766993f538db
|
|
Parts of Osmo-BSC want to see the NM state as valid ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0db11819d23e40272c4aa6fd093365b9c13f7bcf
|
|
Change-Id: I88c8025940a0eecb034b1c70f76ea17937fa0325
|
|
Change-Id: I3f08d71b58b4e8d6f61376d85c2051e194aa8e43
|
|
It's useful to know how many BTS are actually configured to compare
it to a number of connected BTS's.
Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
|
|
Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
|
|
I originally assumed that after a complete scan with llist_for_each_entry
the loop counter would be either NULL or a valid entry. That's just not
the case.
Fixes: CID#210256
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iad647b74771c4ac406a88effd371ed7748c8847e
|
|
There is no bb_transc oject.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I34bb808cd21575ff25d36e6df028b140935a008f
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I1ca4a6ac6ec2f4e40c8421f31871d9c9e5ac5de5
|
|
Change-Id: Iee7e87922f2aa034840993b4bfad3de8defbf5f1
|
|
Change-Id: Ie199104fd4a6c0d5218f56b958d12fac4612fd78
|
|
Change-Id: If20632cfe63b78c2cb17c1bb9d12207a4956be64
|
|
osmo_stat_item_group_alloc() should be initialized with the BTS number.
Change-Id: Iedef08af56ab6985894d89ff7b285246424ca9e7
|
|
Change-Id: I985bf8ac4ce6136812692c06b6dc78edc6bde652
|
|
Change-Id: I4e66b3c864f6c54332fd6dabb0ec549c3590a1f2
|
|
Change-Id: I2eac4c93061204aeb8f3d223f7e78158c61c7156
|
|
From the CS perspective, there is no difference whether this is
a dynamic TS in NONE/PDCH mode or a static TCH in UNUSED mode since
BSC can switch into USED mode at any moment. So we should count
dynamic timeslots in the "total" count.
A bit of a challenge here is that GSM_PCHAN_TCH_F_TCH_H_PDCH
timeslots could be either switched to a single TCH/F or to
two TCH/H, so the total can't be calculated reliably beforehand.
In this code we assume TCH/F since this gives a lower total
count.
Change-Id: Iabd70e8adbf15eb3b7a7be597281ea99b352317b
|
|
The OM2K link "per-trx" only comes up after MCTR is setup. So that means
we need to wait for it before trying to boot the TRX itself.
He we simply apply a "dumb" 5 sec timeout as this is the most reliable
way I found to get this working reliably.
Tracking the link state proved difficult and unreliable:
- Multiple TRX can be present with their link coming up in random
order.
- They can already be up at the start (BTS already initialized from
a previous boot) and so the link may actually come up, down, and
up again.
- All of theses transitions might happens before/after we get to the
OM2K_BTS_S_WAIT_TRX state depending on how the LAPD timeout
expire, if the BTS config was actually changed or not and how much
time it takes to apply the new config.
So all in all, what we must do is wait for the link to stabilize ...
hence just waiting 5 second.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I55a06e08b9c52ff6e97e8c72f2d55770809eba51
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I1caafa2e87c6198bf3b1a77f0fa1edc774deeef9
|
|
Currently only supports a single MCTR with fixed configuration
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I776b0016837e018500ef69acb2f30a274008818e
|
|
Starting from G12R13 the MCTR swiches to BSC controlled mode. And
although we think we know how to configure it (via MCTR Conf Req),
something doesn't work right and the timeslot configuration is not
accepted. (TS Conf Result shows "Data not according to request").
So as a workaround for now, we use this version of the protocol where
we don't configure the MCTR (it's in "BTS controlled mode") and with
this protocol, the BTS accepts our timeslot config and we can bring
the system up.
This commit add a generic option to limit either OML or RSL IWD
version to any value. It also keeps track of the actual negotation
version so we can react to it in other places of the code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65
better version limit
Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ief9093706d6ca20f8162ca541dcc4669c13e2cbc
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I9417f433f759ce21b8b6e0b74cd686df5388f8c5
|
|
* OM2K_DEI_FREQ_SPEC_RX:
(hop << 15) | (rx_addr << 10) | arfcn
. hop Hopping marker
. rx_addr is not really the TRX number, it's just a sequential number
different for all TRX, doesn't need to be 'in-order' of TRX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_SPEC_TX:
(hop << 15) | (tx_id << 10) | arfcn
tx_id Pretty much same as rx_id except here we know that the order
doesn't have to match TRX order. It seems to even vary from one
reboot to another on some real-world capture we got.
. hop Hopping marker
. tx_addr Same as 'rx_addr' above but for TX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_LIST:
Groups of 3 bytes (24 bits), 1 per frequency used.
(tx_addr << 20) | (rx_addr << 16) | (is_c0 << 10) | arfcn
. tx_addr See above
. rx_addr See above
. is_c0 Must be 1 if that ARFCN hosts the C0. (first TRX of a MCTR)
. arfcn The ARFCN number
(Note MAIO must also be set properly on the different TRX/TS sharing
a frequency ... )
The way we generate theses here is what we gathered from real-world
traces:
- Each 'TX' of each TRX is set to the ARFCN set in that TRX config
- Each 'RX' of each TRX is configures as 'hopping'
(which I assume means it will just pick the appropriate freq ?)
- For each TS, we use :
. tx_addr of the TRX that has the ARFCN we want to TX on
. rx_addr of the TRX where the TS we're configuring is
. arfcn The actual ARFCN we want to add to the list
This is incomplete but will work for the 1 MCTR case.
Config for multiple MCTR or multiple virtual-bts still need to be
handled but it's not yet known exactly how those need to be
configured.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie39a857543adaa11d1822346d8563ce3718412c8
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ic2a84ea406e9a39332313d63b27d73f334d4e0a0
|
|
During the configuration of the TS object through OML we must use
pchan_from_config since it's too early to use anything else.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iecdc911a79b66d8f3d746347710ad697cb288174
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I4b4389fd2e7bf0b3078b8ff60f6ea109114a4475
|