Hi.
Attached is a small patch which replaces direct call to comp128 from libosmocore to
auth api call. This will help to remove comp128 from libosmocore public api and to
use other auth functions in openbsc in future.
--
best regards,
Max, http://fairwaves.ru
Hi all,
We're moving this discussion to the mailing list, as it seems it is
more generic and complex than we've thought initially.
The issue arose when I started doing load testing of the OsmoTRX
transceiver and disabled all gating in it. As a result, all incoming
noise was processed as valid Normal Bursts and Access Bursts and sent
up to OsmoBTS. This leads to a situation, similar to a RACH flood,
when there are more RACH requests coming, than a BTS could reasonably
process. And this leads to an unbounded increase of the AGCH queue in
the BTS - it consumes a few Mb per minute.
I think that this is the root cause of the issue we've seen at a
Netherlands festival installation, when 20K phones suddenly started
connecting to our station after official networks went down. When the
amount of RACH requests exceeded available CCCH capacity (took <5
seconds), mobile phones stopped answering out IMM.ASS messages.
Hypothesis is that the AGCH queue became so long, requests were sent
too late for a phone to receive it. And thus no phones answered to our
IMM.ASS messages. Unfortunately, I wasn't able to collect enough data
to check this hypothesis during that time and we don't have another
big festival on hands atm.
An attached is a quick fix for the unbounded queue growth. It uses a
hardcoded value for the maximum queue length, which is fine for our
load testing, but not flexible enough for the real life usage. We
should make the AGCH queue long enough to keep high performance. At
the same time, it must not exceed MS timeout or _all_ IMM.ASS messages
will miss their target MS's.
We could make this parameter user-configurable on a BTS side, but it
seems more reasonable to automatically calculate it, depending on the
channel combination and timeout values. But this should be done on the
BSC side. So the questions are:
1) what is a good way to calculate it?
2) should we configure this queue length over OML, or move the queue
from BTS to BSC?
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi Jason,
On Fri, Nov 08, 2013 at 01:21:46PM +0000, Jason DSouza wrote:
> But I'm waiting at Opstart for Obj Class - RADIO_CARRIER to trigger
> trx-init() which is never received from BSC. That is where I'm struck
> now. All this so far is similar to sysmobts interface, something
> similar to bts_model_opstart() function in osmo-bts-sysmo.
Please see the following code from bts_ipaccess_nanobts.c:
==============
/* Callback function to be called whenever we get a GSM 12.21 state change event */
static int nm_statechg_event(int evt, struct nm_statechg_signal_data *nsd)
{
[...]
case NM_OC_RADIO_CARRIER:
trx = obj;
if (new_state->operational == NM_OPSTATE_DISABLED &&
new_state->availability == NM_AVSTATE_OK)
abis_nm_opstart(trx->bts, obj_class, trx->bts->bts_nr,
trx->nr, 0xff);
break;
==============
So the opstrart for the RADIO_CARRIER is sent in response to an incoming
NM_MT_STATECHG_EVENT_REP withe the operational state set to DISABLED and
the availability set to OK.
My guess is that you are not sending such a state event from the BTS to
the BSC. I can also not see that in the pcap file you have sent. All
OML messages in there relate to the Site MAnager or the BTS object
class, but there are no messages related to any other MOs.
As indicated, it is best to start from a known-working setup with a
supported BTS model, or at least from a protocol trace of an existing
supported configuration.
Please also make sure to set your 'bts model' to nanobts, I _think_ the
'bts model sysmobts' is still broken.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear Harald,
there is an open coverity issue in osmo-bts (CID 1040768) and it is about
mixing enum types.
enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb)
Currently the NET_DST information element (see GSM 24.008) is not
included in generated MM info messages even when the DST field in the
timezone info has been set via the VTY or the control interface.
This patch modifies gsm48_tx_mm_info() to append this information
element if (and only if) a non-zero DST has been configured. The
DST IE is not part of GSM 4.8. Therefore it will only be sent, if the
DST offset is configured to a value != 0.
Sponsored-by: On-Waves ehf
---
openbsc/src/libmsc/gsm_04_08.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 3cfc455..0d1ba7b 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -656,6 +656,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn)
struct tm* gmt_time;
struct tm* local_time;
int tzunits;
+ int dst = 0;
msg->lchan = conn->lchan;
@@ -749,6 +750,9 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn)
tzunits = tzunits + (bts->tz.mn/15);
ptr8[7] = bcdify(tzunits);
}
+ /* Convert DST value */
+ if (bts->tz.dst >= 0 && bts->tz.dst <= 2)
+ dst = bts->tz.dst;
}
else {
/* Need to get GSM offset and convert into 15 min units */
@@ -768,8 +772,19 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn)
}
else
ptr8[7] = bcdify(tzunits);
+
+ /* Does not support DST +2 */
+ if (local_time->tm_isdst)
+ dst = 1;
}
+#ifdef GSM48_IE_NET_DST
+ ptr8 = msgb_put(msg, 3);
+ ptr8[0] = GSM48_IE_NET_DST;
+ ptr8[1] = 1;
+ ptr8[2] = dst;
+#endif
+
DEBUGP(DMM, "-> MM INFO\n");
return gsm48_conn_sendmsg(msg, conn, NULL);
--
1.7.9.5
Dear Andreas,
going through the patchset of jolly/testing in OpenBSC it would be nice
to get most of the things merged (having TCH/H support for something like
the 31C3 is a nice goal).
I wanted to start with merging the Connection Failure Criteria code but
I am confused about the conversion. When parsing the criteria value from
from the VTY you divide by four and subtract (so 4 becomes 0). You ondo
this when saving the config and patching it in the nanoBTS attribute
array.
Wouldn't it be more easy to not doing the conversion?
holger
Hi all,
time is moving fast, and I want to start some initial discussion and
planning for OsmoDevCon 2014.
There are basically four questions which I'm raising below. Please
provide your feedback to the osmocom-event-orga mailing list only, to
avoid cross-posting over all the project lists.
= Who? =
My intention is to keep it an 'active developer/contributer only' event,
like we had it before. I would also want to keep the group relatively
small, to keep the 'Osmocom family' atmosphere.
If desired, we could have one half or full day of public prsentations in
a larger auditorium, but the developer meeting should be a close group,
as known so far.
= Where? =
If we keep the number of attendees within the same range as this year,
then I'm sure we could again hold it at the same venue. I know it is
not perfect, but it is a place that we have access to, 24 hours per day,
and free of cost for community projects like osmocom.org.
If the community wants a larger event, then this is something that would
require more funds and much more time organizing. And that is something
that I personally could not offer to take care of, sorry. I'm happy to
attend and support any larger events, but I'm unable to take care of
fundraising and venue research.
= When? =
Q1/2014. In January, I'm not aware of any 'blocker' events. February,
there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In
March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg
March 17-21). Did I miss any other FOSS / mobile event that might clash
in Q1?
So my preference woudl be to do it either late January (23-26) or in
February (6-9 or 13-16). Any preferences regarding preferred schedule?
Once we have some concencus here on the list [and we want to do it in
the same size / venue], I'll talk to IN-Berlin.
= What? =
I think that question is easy to answer, if we have the above three
figured out... There's no shortage of topics, I suppose.
You can start adding your suggestions to
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Good Morning,
during the 30C3 we had some "broken channels" because the BTS didn't
respond within four seconds to a Channel Activation/Deactivation. I
started to look at it with perf and "snprintf" appears to be called a
lot and did show up in the top.
snprintf is mostly called from within osmo_hexdump and gsm_lchan_name.
Both of these function calls are used in our logging calls throughout
the code.
Going forward I think we can do
* Remove some LOGP/DEBUG with osmo_hexdump (I did so for some call sites
in the osmo-bts)
* Start handlin -DNDEBUG inside logging.h and undefine/not define 'DEBUG'
in logging.h. But this would take away some code paths that would be
nice to look at.
* gsm_lchan_name could 'cache' the last lchan and then not call snprintf.
I did this once but it didn't appear to be much help. I will have
another look.
* Introduce a DEBUGQ, 'Q' for quick and check if the output would be
enabled and then log. This can be useful when the cost of checking
all targets twice is smaller than the cost of snprintf.
comments?
holger
diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index 1d57e22..a8476d2 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -27,6 +27,10 @@
#define DEBUGPC(ss, fmt, args...)
#endif
+#define DEBUGQ(ss, fmt, args) \
+ if (log_would_log(ss, LOGL_DEBUG)) \
+ logp(ss, __FILE__, __LINE__, 0, fmt ## args);
+
void osmo_vlogp(int subsys, int level, const char *file, int line,
int cont, const char *format, va_list ap);
@@ -215,6 +219,9 @@ const char *log_vty_command_description(const struct log_info *info);
struct log_target *log_target_find(int type, const char *fname);
extern struct llist_head osmo_log_target_list;
+/* helper to check if it would log without using filter_fn */
+int log_would_log(int subsys, unsigned int level);
+
/*! @} */
#endif /* _OSMOCORE_LOGGING_H */
diff --git a/src/logging.c b/src/logging.c
index 2e3a80a..1e64ba5 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -268,6 +268,26 @@ err:
target->output(target, level, buf);
}
+
+static int cat_enabled(const struct log_target *tar,
+ const struct log_category *category, int level)
+{
+ /* subsystem is not supposed to be logged */
+ if (!category->enabled)
+ return 0;
+
+ /* Check the global log level */
+ if (tar->loglevel != 0 && level < tar->loglevel)
+ return 0;
+
+ /* Check the category log level */
+ if (tar->loglevel == 0 && category->loglevel != 0 &&
+ level < category->loglevel)
+ return 0;
+
+ return 1;
+}
+
/*! \brief vararg version of logging function */
void osmo_vlogp(int subsys, int level, const char *file, int line,
int cont, const char *format, va_list ap)
@@ -286,17 +306,8 @@ void osmo_vlogp(int subsys, int level, const char *file, int line,
va_list bp;
category = &tar->categories[subsys];
- /* subsystem is not supposed to be logged */
- if (!category->enabled)
- continue;
- /* Check the global log level */
- if (tar->loglevel != 0 && level < tar->loglevel)
- continue;
-
- /* Check the category log level */
- if (tar->loglevel == 0 && category->loglevel != 0 &&
- level < category->loglevel)
+ if (!cat_enabled(tar, category, level))
continue;
/* Apply filters here... if that becomes messy we will
@@ -799,4 +810,19 @@ int log_init(const struct log_info *inf, void *ctx)
return 0;
}
+int log_would_log(int subsys, unsigned int level)
+{
+ struct log_target *tar;
+
+ llist_for_each_entry(tar, &osmo_log_target_list, entry) {
+ if (!cat_enabled(tar, &tar->categories[subsys], level))
+ continue;
+
+ if ((tar->filter_map & LOG_FILTER_ALL) != 0)
+ return 1;
+ }
+
+ return 0;
+}
+
/*! @} */
Dear all,
just a quick reminder:
On Sat, Nov 30, 2013 at 02:57:20PM +0100, Harald Welte wrote:
> Please make sure to add your name to the list at
> https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 until December
> 31st (latest). If you don't have a wiki account, ask somebody who has
> one, apply for a wiki account or send an e-mail to me.
so today is the last chance to indicate your intrest in attending
OsmoDevCon.
I'm surprised to not have seen the following names in the list: pablo,
peter, nion, steve-m, dmitry, kaber. It would be great to have you
around again this year.
Looking forward to meeting all of you again!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Has anyone experienced these cards (as can be found on eBay) failing
after a matter of months? I have some I programmed ~1 year ago and
which worked fine in a bunch of Calypso handsets with NITB, but now I
get "SIM card absent" whenever I try to make a call (but LUR is
accepted OK and can see programmed IMSI in NITB debug).
An operator SIM and an R&S test SIM is working fine with the setup.
Also tried reprogramming the SuperSIM card (command used below).
Regards,
Andrew
//
./pySim-prog.py -d /dev/ttyUSB0 -n OpenBSC -c 44 -x 001 -y 01 -i
001010000000053 -s 1234567890000000003 -k
DEADBEEF0C0FFEE0F00D013370D00F03
Insert card now (or CTRL-C to cancel)
Autodetected card type fakemagicsim
Generated card parameters :
> Name : OpenBSC
> SMSP : e1ffffffffffffffffffffffff058100445555ffffffffffff000000
> ICCID : 1234567890000000003
> MCC/MNC : 1/1
> IMSI : 001010000000053
> Ki : DEADBEEF0C0FFEE0F00D013370D00F03
> OPC : 56078bafca0ce95e81089288cbfb296e
Programming ...
Done !
--
Andrew Back
http://carrierdetect.com
Hello,
For those who use nanoBTS for OpenBSC, I made a short video about how to
properly reset the nanoBTS when something goes wrong.
In the video demonstrates how to manually shirt the TIB pins
For 110 series (Oval Shaped) : http://www.youtube.com/watch?v=VjW2EAP7wss
For 165 series (Rectangular) : http://www.youtube.com/watch?v=9H-H5J8XxOE
And happy holidays to all
Cheers,
Pierre
The attached message was received as a bounce, but either the bounce
format was not recognized, or no member addresses could be extracted
from it. This mailing list has been configured to send all
unrecognized bounce messages to the list administrator(s).
For more information see:
https://lists.osmocom.org/mailman/admin/openbsc/bounce
Hello list,
I'm Nikola and I'm quite new to OpenBSC. Last two days I played little bit
with OpenBSC compilation on FreeBSD and with few changes the work is done.
I am sending the diff file. Not sure about __BYTE_ORDER declaration but
hope someone can help (I am not developer).
Regards,
Nikola
diff --git a/openbsc/src/libbsc/arfcn_range_encode.c b/openbsc/src/libbsc/arfcn_range_encode.c
index 02a75a5..45a49da 100644
--- a/openbsc/src/libbsc/arfcn_range_encode.c
+++ b/openbsc/src/libbsc/arfcn_range_encode.c
@@ -213,7 +213,7 @@ int range_enc_range512(uint8_t *chan_list, int f0, int *w)
write_orig_arfcn(chan_list, f0);
range512 = (struct gsm48_range_512 *) &chan_list[0];
- range512->form_id = chan_list[0] = 0x44;
+ range512->form_id = 0x44;
/* W(1) */
range512->w1_hi = HIGH_BITS(w, 1, 9, 7);
hi,
just found a bug in range 512 channel list encoding. the useless write of 0x44 to chan_list[0] will destroy the LSB, which is part of frequency 0, previously written by write_orig_arfcn(). after fixing this, a frequency of ARFCN 512 encodes correctly.
regards,
andreas
Hi Andreas,
I can confirm, that the patches for the local release and for the TRAU
mux are working with Nokia InSite, finally the handover is available
and working for us with your patches :-)
The local release problem also affected the SMS service, it seems this
patch also solves that problem too.
I will send you the software versions on my two InSite and metrosite
units to keep track and check if we can get a newer version that solves this BTS SW
bug. Note that the Insite units are very old, it is more likely to get
newer software for the MetroSite which is also affected by this
problem.
Thanks again for your hard work!
BR,
Csaba
E1 based BTS use TRAU muxer to decode TRAU frames. After changing
channel from one timeslot to another (due to handover or assignment),
the TRAU muxer must be updated. The call reference of the call is
disconnected from the old channel and connected to the new channel.
---
openbsc/include/openbsc/gsm_data.h | 14 ++++++++++++++
openbsc/include/openbsc/trau_mux.h | 3 +++
openbsc/src/libbsc/bsc_api.c | 5 +++++
openbsc/src/libbsc/handover_logic.c | 7 +++++--
openbsc/src/libmsc/gsm_04_08.c | 19 ++++++++++++++++---
openbsc/src/libtrau/trau_mux.c | 18 ++++++++++++++++++
6 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h
index 7c3ca84..41fe328 100644
--- a/openbsc/include/openbsc/gsm_data.h
+++ b/openbsc/include/openbsc/gsm_data.h
@@ -382,6 +382,20 @@ static inline int is_nokia_bts(struct gsm_bts *bts)
return 0;
}
+static inline int is_e1_bts(struct gsm_bts *bts)
+{
+ switch (bts->type) {
+ case GSM_BTS_TYPE_BS11:
+ case GSM_BTS_TYPE_RBS2000:
+ case GSM_BTS_TYPE_NOKIA_SITE:
+ return 1;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
enum gsm_auth_policy gsm_auth_policy_parse(const char *arg);
const char *gsm_auth_policy_name(enum gsm_auth_policy policy);
diff --git a/openbsc/include/openbsc/trau_mux.h b/openbsc/include/openbsc/trau_mux.h
index 3de50f7..d211d8d 100644
--- a/openbsc/include/openbsc/trau_mux.h
+++ b/openbsc/include/openbsc/trau_mux.h
@@ -51,6 +51,9 @@ int trau_recv_lchan(struct gsm_lchan *lchan, uint32_t callref);
/* send trau from application */
int trau_send_frame(struct gsm_lchan *lchan, struct gsm_data_frame *frame);
+/* switch trau muxer to new lchan */
+int switch_trau_mux(struct gsm_lchan *old_lchan, struct gsm_lchan *new_lchan);
+
/* callback invoked if we receive TRAU frames */
int subch_cb(struct subch_demux *dmx, int ch, uint8_t *data, int len, void *_priv);
diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c
index 86d2493..e567038 100644
--- a/openbsc/src/libbsc/bsc_api.c
+++ b/openbsc/src/libbsc/bsc_api.c
@@ -31,6 +31,7 @@
#include <openbsc/handover.h>
#include <openbsc/debug.h>
#include <openbsc/gsm_04_08.h>
+#include <openbsc/trau_mux.h>
#include <osmocom/gsm/protocol/gsm_08_08.h>
@@ -419,6 +420,10 @@ static void handle_ass_compl(struct gsm_subscriber_connection *conn,
return;
}
+ /* switch TRAU muxer for E1 based BTS from one channel to another */
+ if (is_e1_bts(conn->bts))
+ switch_trau_mux(conn->lchan, conn->secondary_lchan);
+
/* swap channels */
osmo_timer_del(&conn->T10);
diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c
index 9cf26af..36a758b 100644
--- a/openbsc/src/libbsc/handover_logic.c
+++ b/openbsc/src/libbsc/handover_logic.c
@@ -39,6 +39,7 @@
#include <openbsc/signal.h>
#include <osmocom/core/talloc.h>
#include <openbsc/transaction.h>
+#include <openbsc/trau_mux.h>
struct bsc_handover {
struct llist_head list;
@@ -264,6 +265,10 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan)
osmo_timer_del(&ho->T3103);
+ /* switch TRAU muxer for E1 based BTS from one channel to another */
+ if (is_e1_bts(new_lchan->conn->bts))
+ switch_trau_mux(ho->old_lchan, new_lchan);
+
/* Replace the ho lchan with the primary one */
if (ho->old_lchan != new_lchan->conn->lchan)
LOGP(DHO, LOGL_ERROR, "Primary lchan changed during handover.\n");
@@ -278,8 +283,6 @@ static int ho_gsm48_ho_compl(struct gsm_lchan *new_lchan)
rsl_lchan_set_state(ho->old_lchan, LCHAN_S_INACTIVE);
lchan_release(ho->old_lchan, 0, RSL_REL_LOCAL_END);
- /* do something to re-route the actual speech frames ! */
-
llist_del(&ho->list);
talloc_free(ho);
diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c
index 0c6b100..bc4a9c3 100644
--- a/openbsc/src/libmsc/gsm_04_08.c
+++ b/openbsc/src/libmsc/gsm_04_08.c
@@ -1648,6 +1648,9 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
lchan = trans->conn->lchan;
bts = lchan->ts->trx->bts;
+ /* store receive state */
+ trans->tch_recv = enable;
+
switch (bts->type) {
case GSM_BTS_TYPE_NANOBTS:
case GSM_BTS_TYPE_OSMO_SYSMO:
@@ -1655,10 +1658,12 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
LOGP(DCC, LOGL_ERROR, "Error: RTP proxy is disabled\n");
return -EINVAL;
}
- /* in case, we don't have a RTP socket yet, we note this
- * in the transaction and try later */
+ /* In case, we don't have a RTP socket to the BTS yet, the BTS
+ * will not be connected to our RTP proxy and the socket will
+ * not be assigned to the application interface. This method
+ * will be called again, once the audio socket is created and
+ * connected. */
if (!lchan->abis_ip.rtp_socket) {
- trans->tch_recv = enable;
DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable);
return 0;
}
@@ -1677,6 +1682,14 @@ static int tch_recv_mncc(struct gsm_network *net, uint32_t callref, int enable)
case GSM_BTS_TYPE_BS11:
case GSM_BTS_TYPE_RBS2000:
case GSM_BTS_TYPE_NOKIA_SITE:
+ /* In case we don't have a TCH with correct mode, the TRAU muxer
+ * will not be asigned to the application interface. This is
+ * performed by switch_trau_mux() after successful handover or
+ * assignment. */
+ if (lchan->tch_mode == GSM48_CMODE_SIGN) {
+ DEBUGP(DCC, "queue tch_recv_mncc request (%d)\n", enable);
+ return 0;
+ }
if (enable)
return trau_recv_lchan(lchan, callref);
return trau_mux_unmap(NULL, callref);
diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c
index c9d77cf..7b9bac0 100644
--- a/openbsc/src/libtrau/trau_mux.c
+++ b/openbsc/src/libtrau/trau_mux.c
@@ -31,6 +31,7 @@
#include <osmocom/core/talloc.h>
#include <openbsc/trau_upqueue.h>
#include <osmocom/core/crcgen.h>
+#include <openbsc/transaction.h>
/* this corresponds to the bit-lengths of the individual codec
* parameters as indicated in Table 1.1 of TS 06.10 */
@@ -518,3 +519,20 @@ int trau_send_frame(struct gsm_lchan *lchan, struct gsm_data_frame *frame)
return subchan_mux_enqueue(mx, dst_e1_ss->e1_ts_ss, trau_bits_out,
TRAU_FRAME_BITS);
}
+
+/* switch trau muxer to new lchan */
+int switch_trau_mux(struct gsm_lchan *old_lchan, struct gsm_lchan *new_lchan)
+{
+ struct gsm_network *net = old_lchan->ts->trx->bts->network;
+ struct gsm_trans *trans;
+
+ /* look up transaction with TCH frame receive enabled */
+ llist_for_each_entry(trans, &net->trans_list, entry) {
+ if (trans->conn && trans->conn->lchan == old_lchan && trans->tch_recv) {
+ /* switch */
+ trau_recv_lchan(new_lchan, trans->callref);
+ }
+ }
+
+ return 0;
+}
--
1.8.1.5
--------------080108050203060401030404--