February 2016 - osmocom-net-gprs

by Saba Arshad

Hello, I want to use the local sims having different MNC/MCC for implementing GPRS using osmocoms with OpenBTS same as I have used them for GSM calls and sms using only openBTS. But your site http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS says, "it is currently not possible". As it is long when posted on this site so I want to ask is it possible *now* to use the local sims? Hope you have understood my question. Waiting for your reply. Thanks. Regards, Saba Arshad

7 years, 1 month

2
1
0 0

Support of 11 bit RACH support in osmoPCU

by Prasad Kaup

Hello All, We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues We have identified impacts to be in osmo-pcu, osmo-bts and osmocore Main changes identified are osmo-pcu: * In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind * Corresponding function prototypes due to change in data type * 11 bit RACH handling in bts.cpp * Changes in encoding.cpp to support immediate assignment with EGPRS allocation osmocore: * In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param" * Function prototype changes osmobts: * Function prototype changes due to change in data type Please let us know your valuable feedback. We plan to have a separate branch from master for this development. Please let us know the procedure to do this. Regards Prasad

8 years, 1 month

2
2
0 0

RE: PCU scheduling and PACCH timeout question

by Saurabh Sharan

Hello Max, Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below 1. There seems to be difference in FN UL versus DL being processed at any given time by the order of approx. 10 FNs, example given below a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 b. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972 c. From above example difference in time is 48milliseconds or approx.. 10FN duration 2. For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2 b. Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6 Please let me know if these are known behavior in your integration environment ? These time variations may have an impact on the poll response behavior from MS as well. Regards Saurabh -----Original Message----- From: Max [mailto:msuraev@sysmocom.de] Sent: Thursday, February 25, 2016 3:58 PM To: osmocom-net-gprs(a)lists.osmocom.org; Saurabh Sharan <Saurabh.Sharan(a)radisys.com> Subject: PCU scheduling and PACCH timeout question Hello. I'm trying to debug issue with current OsmoPCU master when some basebands ignore polling requests. The debug output from RLCMAC layer and corresponding .pcap files are attached. The issue appears somewhere after line 112 in debug.log The corresponding packet in pcu.pcapng is 6866 After receiving PACKET_CONTROL_ACK from phone we're trying to schedule polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 (packet 6874) which subsequently fails. This seems suspiciously close but I have not found in the spec yet if this is legitimate thing to do. There are several other occurrences like that in both log and pcap. Have you experienced something like this? Do you have an idea why only some basebands are affected while others work fine? -- Max Suraev <msuraev(a)sysmocom.de<mailto:msuraev@sysmocom.de>> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

8 years, 1 month

3
5
0 0

OpenGGSN

by Terje Kristoffer Hybbestad Skow

Hi Does this mailinglist also regard openGGSN? If so do I have some questions. I have problem setting it up correctly. Does anyone have a configuration file for both ggsn and sgsnemu that works? Which flags are necessary to use and what should they be set to? I understand it can differ based on IP addresses and similar, but can someone please help? I'm using this program for my master thesis. Regards Terje Kristoffer H. Skow

8 years, 1 month

2
1
0 0

Fwd: New Defects reported by Coverity Scan for Osmocom

by Holger Freyther

Hi guys, FYI after adding the do{} while and the log_check_level call coverity has found some dead code. The found_partial is a funny case of dead code. :) holger > Begin forwarded message: > > From: scan-admin(a)coverity.com > Subject: New Defects reported by Coverity Scan for Osmocom > Date: 29 February 2016 at 17:47:54 GMT+1 > To: holger(a)freyther.de > > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 3 new defect(s) introduced to Osmocom found with Coverity Scan. > 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 3 of 3 defect(s) > > > ** CID 70677: Control flow issues (DEADCODE) > /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b() > > > ________________________________________________________________________________________________________ > *** CID 70677: Control flow issues (DEADCODE) > /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b() > 901 dl_slots, 'D'), > 902 single ? ", single" : ""); > 903 > 904 /* assign downlink */ > 905 if (dl_slots == 0) { > 906 LOGP(DRLCMAC, LOGL_NOTICE, "No downlink slots " >>>> CID 70677: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 907 "available\n"); > 908 return -EINVAL; > 909 } > 910 slotcount = pcu_bitcount(dl_slots); > 911 first_ts = ffs(dl_slots) - 1; > 912 avail_count = pcu_bitcount(reserved_dl_slots); > > ** CID 70676: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload() > > > ________________________________________________________________________________________________________ > *** CID 70676: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload() > 118 return NULL; > 119 } > 120 } > 121 if (rtph->padding) { > 122 if (payload_len < 0) { > 123 DEBUGPC(DLMUX, "received RTP frame too short for " >>>> CID 70676: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 124 "padding length\n"); > 125 return NULL; > 126 } > 127 payload_len -= payload[payload_len - 1]; > 128 if (payload_len < 0) { > 129 DEBUGPC(DLMUX, "received RTP frame with padding " > > ** CID 70675: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create() > > > ________________________________________________________________________________________________________ > *** CID 70675: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create() > 51 LOGP(DLINP, LOGL_ERROR, "unsupported channel type `%s'\n", > 52 cur->name); > 53 return NULL; > 54 } > 55 if (found_partial) { > 56 LOGP(DLINP, LOGL_ERROR, "Sorry, channel type `%s' does not " >>>> CID 70675: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 57 "support subtype `%u'\n", cur->name, subtype_id); > 58 return NULL; > 59 } > 60 > 61 c = talloc_zero_size(osmo_chan_ctx, > 62 sizeof(struct osmo_chan) + cur->datasiz); > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/osmocom?tab=overview > > To manage Coverity Scan email notifications for "holger(a)freyther.de", click https://scan.coverity.com/subscriptions/edit?email=holger%40freyther.de&tok… >

8 years, 1 month

1
0
0 0

Support of 11 bit RACH support in osmoPCU

by Prasad Kaup

Hello All, We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues We have identified impacts to be in osmo-pcu, osmo-bts and osmocore Main changes identified are osmo-pcu: * In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind * Corresponding function prototypes due to change in data type * 11 bit RACH handling in bts.cpp * Changes in encoding.cpp to support immediate assignment with EGPRS allocation osmocore: * In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param" * Function prototype changes osmobts: * Function prototype changes due to change in data type Please let us know your valuable feedback. We plan to have a separate branch from master for this development. Please let us know the procedure to do this. Regards Prasad

8 years, 1 month

2
1
0 0

Support of 11 bit RACH support in osmoPCU

by Prasad Kaup

Hello All, We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues We have identified impacts to be in osmo-pcu, osmo-bts and osmocore Main changes identified are osmo-pcu: * In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind * Corresponding function prototypes due to change in data type * 11 bit RACH handling in bts.cpp * Changes in encoding.cpp to support immediate assignment with EGPRS allocation osmocore: * In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param" * Function prototype changes osmobts: * Function prototype changes due to change in data type Please let us know your valuable feedback. We plan to have a separate branch from master for this development. Please let us know the procedure to do this. Regards Prasad

8 years, 1 month

1
0
0 0

Re: [PATCH] Refactor coding scheme assignment code

by Holger Freyther

> On 24 Feb 2016, at 12:57, msuraev(a)sysmocom.de wrote: Moving it to the BTS list. After we had some performance issues today (and just pointing out the need for a stable test setup and some repeated measurements). I looked at the code more carefully and have some more comments we should > > +inline static GprsCodingScheme assign_cs(GprsCodingScheme current, BTS *bts, bool uplink, GprsCodingScheme::Mode mode) > +{ "assign" is a misleading name. It doesn't have a side-effect so it should be called pick_cs (or such). Please make "current" const as well. > + GprsCodingScheme tmp = GprsCodingScheme::UNKNOWN; > + struct gprs_rlcmac_bts * b = bts->bts_data(); > + > + if (GprsCodingScheme::GPRS == mode) { > + if (!current.isGprs()) { > + tmp = GprsCodingScheme::getGprsByNum(uplink ? b->initial_cs_ul : b->initial_cs_dl); > + if (!tmp.isValid()) > + return GprsCodingScheme::CS1; > + } > + } else { > + if (!current.isEgprs()) { > + tmp = GprsCodingScheme::getEgprsByNum(uplink ? b->initial_mcs_ul : b->initial_mcs_dl); > + if (!tmp.isValid()) > + return GprsCodingScheme::MCS1; > + } > + } > + > + return tmp; > +} > + > void GprsMs::set_mode(GprsCodingScheme::Mode mode) > { > + GprsCodingScheme tmp; > m_mode = mode; > > if (!m_bts) > return; > > - switch (m_mode) { > - case GprsCodingScheme::GPRS: > - if (!m_current_cs_ul.isGprs()) { > - m_current_cs_ul = GprsCodingScheme::getGprsByNum( > - m_bts->bts_data()->initial_cs_ul); > - if (!m_current_cs_ul.isValid()) > - m_current_cs_ul = GprsCodingScheme::CS1; > - } > - if (!m_current_cs_dl.isGprs()) { > - m_current_cs_dl = GprsCodingScheme::getGprsByNum( > - m_bts->bts_data()->initial_cs_dl); > - if (!m_current_cs_dl.isValid()) > - m_current_cs_dl = GprsCodingScheme::CS1; > - } > - break; > - > - case GprsCodingScheme::EGPRS_GMSK: > - case GprsCodingScheme::EGPRS: > - if (!m_current_cs_ul.isEgprs()) { > - m_current_cs_ul = GprsCodingScheme::getEgprsByNum( > - m_bts->bts_data()->initial_mcs_ul); > - if (!m_current_cs_dl.isValid()) > - m_current_cs_ul = GprsCodingScheme::MCS1; > - } > - if (!m_current_cs_dl.isEgprs()) { > - m_current_cs_dl = GprsCodingScheme::getEgprsByNum( > - m_bts->bts_data()->initial_mcs_dl); > - if (!m_current_cs_dl.isValid()) > - m_current_cs_dl = GprsCodingScheme::MCS1; > - } > - break; > - } > + tmp = assign_cs(m_current_cs_ul, m_bts, true, mode); > + if (tmp) > + m_current_cs_ul = tmp; > + > + tmp = assign_cs(m_current_cs_dl, m_bts, false, mode); > + if (tmp) > + m_current_cs_dl = tmp; let us change the code-flow here. There is a subtle difference between operator bool() and isValid but we avoid that by: a.) By passing m_current_cs_ul/m_current_cs_dl as pointer and really assign b.) By making sure pick_cs always returns a valid result? diff --git a/src/gprs_ms.cpp b/src/gprs_ms.cpp index 78f03f8..98c4fda 100644 --- a/src/gprs_ms.cpp +++ b/src/gprs_ms.cpp @@ -209,6 +209,25 @@ void GprsMs::stop_timer() unref(); } +static inline void assign_cs(GprsCodingScheme *current, BTS *bts, bool uplink, GprsCodingScheme::Mode mode) +{ + struct gprs_rlcmac_bts * b = bts->bts_data(); + + if (GprsCodingScheme::GPRS == mode) { + if (current->isGprs()) + return; + *current = GprsCodingScheme::getGprsByNum(uplink ? b->initial_cs_ul : b->initial_cs_dl); + if (!current->isValid()) + *current = GprsCodingScheme::CS1; + } else { + if (current->isEgprs()) + return; + *current = GprsCodingScheme::getEgprsByNum(uplink ? b->initial_mcs_ul : b->initial_mcs_dl); + if (!current->isValid()) + *current = GprsCodingScheme::MCS1; + } +} + void GprsMs::set_mode(GprsCodingScheme::Mode mode) { m_mode = mode; @@ -216,38 +235,11 @@ void GprsMs::set_mode(GprsCodingScheme::Mode mode) if (!m_bts) return; - switch (m_mode) { - case GprsCodingScheme::GPRS: - if (!m_current_cs_ul.isGprs()) { - m_current_cs_ul = GprsCodingScheme::getGprsByNum( - m_bts->bts_data()->initial_cs_ul); - if (!m_current_cs_ul.isValid()) - m_current_cs_ul = GprsCodingScheme::CS1; - } - if (!m_current_cs_dl.isGprs()) { - m_current_cs_dl = GprsCodingScheme::getGprsByNum( - m_bts->bts_data()->initial_cs_dl); - if (!m_current_cs_dl.isValid()) - m_current_cs_dl = GprsCodingScheme::CS1; - } - break; - - case GprsCodingScheme::EGPRS_GMSK: - case GprsCodingScheme::EGPRS: - if (!m_current_cs_ul.isEgprs()) { - m_current_cs_ul = GprsCodingScheme::getEgprsByNum( - m_bts->bts_data()->initial_mcs_ul); - if (!m_current_cs_dl.isValid()) - m_current_cs_ul = GprsCodingScheme::MCS1; - } - if (!m_current_cs_dl.isEgprs()) { - m_current_cs_dl = GprsCodingScheme::getEgprsByNum( - m_bts->bts_data()->initial_mcs_dl); - if (!m_current_cs_dl.isValid()) - m_current_cs_dl = GprsCodingScheme::MCS1; - } - break; - } + assign_cs(&m_current_cs_ul, m_bts, true, mode); + assign_cs(&m_current_cs_dl, m_bts, false, mode); + + LOGP(DRLCMAC, LOGL_DEBUG, "MS IMSI=%s mode set to %s: UL=%s, DL=%s\n", + imsi(), tmp.modeName(mode), m_current_cs_ul.name(), m_current_cs_dl.name()); } void GprsMs::attach_tbf(struct gprs_rlcmac_tbf *tbf)

8 years, 1 month

1
0
0 0

[PATCH] Explicitly initialize m_v_n and m_v_b

by msuraev＠sysmocom.de

From: Max <msuraev(a)sysmocom.de> Call reset() to initialize m_v_b in gprs_rlc_dl_window() and m_v_n in gprs_rlc_ul_window() constructors. Add constructors to gprs_rlc_v_b and gprs_rlc_v_n. Not sure about all the intimate details of constructor calls in c++ so used both. Fixes: Coverity: CID 1351738, 1351737 --- src/rlc.h | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/rlc.h b/src/rlc.h index 54f28df..eb527a0 100644 --- a/src/rlc.h +++ b/src/rlc.h @@ -143,8 +143,7 @@ struct gprs_rlc_v_b { void mark_invalid(int bsn); void reset(); - - + gprs_rlc_v_b(); private: bool is_state(int bsn, const gprs_rlc_dl_bsn_state state) const; void mark(int bsn, const gprs_rlc_dl_bsn_state state); @@ -216,6 +215,7 @@ struct gprs_rlc_v_n { bool is_received(int bsn) const; gprs_rlc_ul_bsn_state state(int bsn) const; + gprs_rlc_v_n(); private: bool is_state(int bsn, const gprs_rlc_ul_bsn_state state) const; void mark(int bsn, const gprs_rlc_ul_bsn_state state); @@ -448,6 +448,7 @@ inline gprs_rlc_dl_window::gprs_rlc_dl_window() : m_v_s(0) , m_v_a(0) { + m_v_b.reset(); } inline const uint16_t gprs_rlc_dl_window::v_s() const @@ -490,10 +491,21 @@ inline const int16_t gprs_rlc_dl_window::distance() const return (m_v_s - m_v_a) & mod_sns(); } +inline gprs_rlc_v_b::gprs_rlc_v_b() +{ + reset(); +} + +inline gprs_rlc_v_n::gprs_rlc_v_n() +{ + reset(); +} + inline gprs_rlc_ul_window::gprs_rlc_ul_window() : m_v_r(0) , m_v_q(0) { + m_v_n.reset(); } inline bool gprs_rlc_ul_window::is_in_window(uint16_t bsn) const -- 2.7.2

8 years, 1 month

3
3
0 0

[PATCH] Expand RLCMAC diagnostics output

by msuraev＠sysmocom.de

From: Max <msuraev(a)sysmocom.de> When smth bad happens (e. g. we hit timeout in RLCMAC) on TBF - obtain corresponding MS object and print extended information about it and its TBFs to aid troubleshooting. Diagnostic function should not change state hence make it const with no return value. --- src/bts.cpp | 2 +- src/tbf.cpp | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- src/tbf.h | 2 +- 3 files changed, 84 insertions(+), 9 deletions(-) diff --git a/src/bts.cpp b/src/bts.cpp index 715fb51..75766f1 100644 --- a/src/bts.cpp +++ b/src/bts.cpp @@ -1254,7 +1254,7 @@ int gprs_rlcmac_pdch::rcv_control_block( bitvec *rlc_block, uint32_t fn) { RlcMacUplink_t * ul_control_block = (RlcMacUplink_t *)talloc_zero(tall_pcu_ctx, RlcMacUplink_t); - LOGP(DRLCMAC, LOGL_DEBUG, "+++++++++++++++++++++++++ RX : Uplink Control Block +++++++++++++++++++++++++\n"); + LOGP(DRLCMAC, LOGL_DEBUG, "+++++++++++++++++++++++++ RX : Uplink Control Block on FN = %d ++++++++++++++\n", fn); decode_gsm_rlcmac_uplink(rlc_block, ul_control_block); LOGPC(DCSN1, LOGL_NOTICE, "\n"); LOGP(DRLCMAC, LOGL_DEBUG, "------------------------- RX : Uplink Control Block -------------------------\n"); diff --git a/src/tbf.cpp b/src/tbf.cpp index 69b9e3a..5f81e8b 100644 --- a/src/tbf.cpp +++ b/src/tbf.cpp @@ -490,7 +490,7 @@ void gprs_rlcmac_tbf::poll_timeout() if (!(state_flags & (1 << GPRS_RLCMAC_FLAG_TO_UL_ACK))) { LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling " "PACKET CONTROL ACK for PACKET UPLINK ACK\n"); - rlcmac_diag(); + rlcmac_diag("POLL TIMEOUT for PACKET CONTROL ACK for PACKET UPLINK ACK"); state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_UL_ACK); } ul_ack_state = GPRS_RLCMAC_UL_ACK_NONE; @@ -514,7 +514,7 @@ void gprs_rlcmac_tbf::poll_timeout() LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling " "PACKET CONTROL ACK for PACKET UPLINK " "ASSIGNMENT.\n"); - rlcmac_diag(); + rlcmac_diag("POLL TIMEOUT for PACKET CONTROL ACK for PACKET UPLINK ASSIGNMENT"); state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_UL_ASS); } ul_ass_state = GPRS_RLCMAC_UL_ASS_NONE; @@ -534,7 +534,7 @@ void gprs_rlcmac_tbf::poll_timeout() LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling " "PACKET CONTROL ACK for PACKET DOWNLINK " "ASSIGNMENT.\n"); - rlcmac_diag(); + rlcmac_diag("POLL TIMEOUT for PACKET CONTROL ACK for PACKET DOWNLINK ASSIGNMENT"); state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_DL_ASS); } dl_ass_state = GPRS_RLCMAC_DL_ASS_NONE; @@ -555,7 +555,7 @@ void gprs_rlcmac_tbf::poll_timeout() if (!(dl_tbf->state_flags & (1 << GPRS_RLCMAC_FLAG_TO_DL_ACK))) { LOGP(DRLCMAC, LOGL_NOTICE, "- Timeout for polling " "PACKET DOWNLINK ACK.\n"); - dl_tbf->rlcmac_diag(); + dl_tbf->rlcmac_diag("POLL TIMEOUT for PACKET DOWNLINK ACK"); dl_tbf->state_flags |= (1 << GPRS_RLCMAC_FLAG_TO_DL_ACK); } dl_tbf->n3105++; @@ -872,7 +872,7 @@ void gprs_rlcmac_tbf::handle_timeout() case 3195: LOGP(DRLCMAC, LOGL_NOTICE, "%s T%d timeout during " "transsmission\n", tbf_name(this), T); - rlcmac_diag(); + rlcmac_diag("TRANSMISSION TIMEOUT"); /* fall through */ case 3193: LOGP(DRLCMAC, LOGL_DEBUG, @@ -887,8 +887,33 @@ void gprs_rlcmac_tbf::handle_timeout() } } -int gprs_rlcmac_tbf::rlcmac_diag() +static inline void print_tbf_diag(const struct gprs_rlcmac_tbf * t, bool uplink) { + const char * d = uplink ? "UL" : "DL"; + + LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s %s\n", d, t->name()); + LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF 1st TS = %d, 1st common TS = %d, ctrl TS = %d\n", + d, t->first_ts, t->first_common_ts, t->control_ts); + LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF TSC = %d, DL: "OSMO_BIT_SPEC", UL: "OSMO_BIT_SPEC", mslot upgradeable: %d\n", + d, t->tsc(), OSMO_BIT_PRINT(t->dl_slots()), OSMO_BIT_PRINT(t->ul_slots()), t->upgrade_to_multislot); + + unsigned i; + for (i = 0; i < 8; i++) + if (t->pdch[i]) + if (t->pdch[i]->is_enabled()) + LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s PDCH[%d] USF = %d, last RTS FN = %d, TSC = %d, TS = %d\n", + d, i, t->pdch[i]->assigned_usf(), t->pdch[i]->last_rts_fn, t->pdch[i]->tsc, t->pdch[i]->ts_no); + + if (GPRS_RLCMAC_POLL_SCHED == t->poll_state) + LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF poll. scheduled: FN = %d, TS = %d\n", d, t->poll_fn, t->poll_ts); + else + LOGP(DRLCMAC, LOGL_NOTICE, "- MS %s TBF no polling\n", d); +} + +void gprs_rlcmac_tbf::rlcmac_diag(const char * context) const +{ + GprsMs * m = ms(); + LOGP(DRLCMAC, LOGL_NOTICE, "- RLCMAC diag. report for %s:\n", context); if ((state_flags & (1 << GPRS_RLCMAC_FLAG_CCCH))) LOGP(DRLCMAC, LOGL_NOTICE, "- Assignment was on CCCH\n"); if ((state_flags & (1 << GPRS_RLCMAC_FLAG_PACCH))) @@ -902,7 +927,57 @@ int gprs_rlcmac_tbf::rlcmac_diag() else if (direction == GPRS_RLCMAC_DL_TBF) LOGP(DRLCMAC, LOGL_NOTICE, "- No downlink ACK received yet\n"); - return 0; + if (is_tfi_assigned()) + LOGP(DRLCMAC, LOGL_NOTICE, "- TBF's TFI = %d\n", tfi()); + else + LOGP(DRLCMAC, LOGL_NOTICE, "- No TFI is assigned to this TBF yet\n"); + + if (is_tlli_valid()) + LOGP(DRLCMAC, LOGL_NOTICE, "- TBF's TLLI = 0x%x\n", tlli()); + else + LOGP(DRLCMAC, LOGL_NOTICE, "- No TLLI is assigned to this TBF yet\n"); + + LOGP(DRLCMAC, LOGL_NOTICE, "- MS IMSI = %s, GPRS class = %d, EGPRS class = %d, TA = %d, TLLI = 0x%x\n", + m->imsi(), m->ms_class(), m->egprs_ms_class(), m->ta(), m->tlli()); + LOGP(DRLCMAC, LOGL_NOTICE, "- MS 1st common TS = %d, current PACCH = %d\n", + m->first_common_ts(), m->current_pacch_slots()); + LOGP(DRLCMAC, LOGL_NOTICE, "- MS DL: "OSMO_BIT_SPEC" (RSRVD: "OSMO_BIT_SPEC"), UL: "OSMO_BIT_SPEC" (RSRVD: "OSMO_BIT_SPEC")\n", + OSMO_BIT_PRINT(m->dl_slots()), OSMO_BIT_PRINT(m->reserved_dl_slots()), OSMO_BIT_PRINT(m->ul_slots()), OSMO_BIT_PRINT(m->reserved_ul_slots())); + + if (m->is_idle()) + LOGP(DRLCMAC, LOGL_NOTICE, "- MS id idle\n"); + if (m->need_dl_tbf()) + LOGP(DRLCMAC, LOGL_NOTICE, "- MS needs DL TBF\n"); + + if (m->dl_tbf()) { + struct gprs_rlcmac_dl_tbf * dl = m->dl_tbf(); + print_tbf_diag(dl, false); + + if (m->dl_tbf()->need_control_ts()) + LOGP(DRLCMAC, LOGL_NOTICE, "- MS DL TBF needs ctrl TS\n"); + + if (m->dl_tbf()->have_data()) + LOGP(DRLCMAC, LOGL_NOTICE, "- MS DL TBF have data\n"); + } else + LOGP(DRLCMAC, LOGL_NOTICE, "- MS have no DL TBF\n"); + + if (m->ul_tbf()) { + struct gprs_rlcmac_ul_tbf * ul = m->ul_tbf(); + print_tbf_diag(ul, true); + + LOGP(DRLCMAC, LOGL_NOTICE, "- MS UL TBF USF: %d %d %d %d %d %d %d %d\n", + m->ul_tbf()->m_usf[0], + m->ul_tbf()->m_usf[1], + m->ul_tbf()->m_usf[2], + m->ul_tbf()->m_usf[3], + m->ul_tbf()->m_usf[4], + m->ul_tbf()->m_usf[5], + m->ul_tbf()->m_usf[6], + m->ul_tbf()->m_usf[7]); + } else + LOGP(DRLCMAC, LOGL_NOTICE, "- MS have no UL TBF\n"); + + LOGP(DRLCMAC, LOGL_NOTICE, "- RLCMAC diag. report complete\n\n"); } struct msgb *gprs_rlcmac_tbf::create_dl_ass(uint32_t fn, uint8_t ts) diff --git a/src/tbf.h b/src/tbf.h index ad8ad4c..b556e0c 100644 --- a/src/tbf.h +++ b/src/tbf.h @@ -112,7 +112,7 @@ struct gprs_rlcmac_tbf { uint8_t tsc() const; - int rlcmac_diag(); + void rlcmac_diag(const char * context) const; int update(); void handle_timeout(); -- 2.7.2

8 years, 1 month

1
0
0 0

PCU scheduling and PACCH timeout question

by Max

Hello. I'm trying to debug issue with current OsmoPCU master when some basebands ignore polling requests. The debug output from RLCMAC layer and corresponding .pcap files are attached to ticket http://projects.osmocom.org/issues/1524 The issue appears somewhere after line 112 in debug.log The corresponding packet in pcu.pcapng is 6866 After receiving PACKET_CONTROL_ACK from phone we're trying to schedule polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127 (packet 6874) which subsequently fails. This seems suspiciously close but I have not found in the spec yet if this is legitimate thing to do. There are several other occurrences like that in both log and pcap. Have you experienced something like this? Do you have an idea why only some basebands are affected while others work fine? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

8 years, 1 month

1
0
0 0

RE: [PATCH] fix for encoding of padding bits

by Saurabh Sharan

Hello Harald, We had tried the option of sending one patch through git send-email. This was our first attempt so wanted to confirm whether we followed the process correctly. Please note that I am unable to see this patch(mail below) in Archive maintained at http://lists.osmocom.org/pipermail/osmocom-net-gprs/ Regards Saurabh -----Original Message----- From: Saurabh Sharan [mailto:saurabh.sharan@radisys.com] Sent: Tuesday, February 23, 2016 4:29 PM To: osmocom-net-gprs(a)lists.osmocom.org Cc: Saurabh Sharan <Saurabh.Sharan(a)radisys.com> Subject: [PATCH] fix for encoding of padding bits --- src/csn1.cpp | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/csn1.cpp b/src/csn1.cpp index 54cc411..9262c81 100644 --- a/src/csn1.cpp +++ b/src/csn1.cpp @@ -2400,7 +2400,12 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector guint8 bits_to_handle = remaining_bits_len%8; if (bits_to_handle > 0) { - guint8 fl = filler&(0xff>>(8-bits_to_handle)); + /*section 11 of 44.060 + *The padding bits may be the 'null' string. Otherwise, the + *padding bits starts with bit '0', followed by 'spare padding'. + *< padding bits > ::= { null | 0 < spare padding > ! < Ignore : 1 bit** = < no string > > } ; + */ + guint8 fl = filler&(0xff>>(8-bits_to_handle + 1)); bitvec_write_field(vector, writeIndex, fl, bits_to_handle); LOGPC(DCSN1, LOGL_NOTICE, "%u|", fl); remaining_bits_len -= bits_to_handle; -- 1.7.9.5

8 years, 1 month

2
3
0 0

Support for Fast Ack/Nack Report in osmoPCU

by Saurabh Sharan

Hello All, We are currently working on providing the support of FANR in osmoPCU. We are in design phase and will share the design details soon. Please provide your valuable feedback on the design. Regards Saurabh

8 years, 1 month

2
1
0 0

Support of Basic EGPRS in OsmoPCU

by Saurabh Sharan

Hello All, We would like to provide the information that since Dec-2015 we have been working on adding the EGPRS support in OsmoPCU. We have provided the support for Basic EGPRS feature, details of which explained below. We would like to make the code available in Public domain so that we receive the feedback from all and upon approval would contribute to the master branch. Following are the features added: 1) EGPRS MCS 1 to MCS 9 coding scheme support 2) Radio Link Control Block Structure Updates 3) MCS Selection 4) Transmission and reception data flows for MCS1 to MCS9 5) EGPRS incremental redundancy (IR) mode, RLC function 6) EGPRS Window selection 7) RLC Re-segmentation and split block support 8) RLC retransmission based on coding families A, A', B and C We have taken interim rebase from the master during Jan-2016. Regards, Saurabh

8 years, 1 month

3
3
0 0

EDGE over osmo-pcu

by Jacob Erlbeck

Hi everybody, we have just done the first download of an Internet page using the current bleeding EDGE development version of the OSMO-PCU. Supported are MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction. The download of 'www.osmocom.org' has been documented in a PCAP file and can be downloaded from https://openbsc.osmocom.org/trac/wiki/osmo-pcu To decode the data blocks, an experimental patch for the gsmtab dissector is also available from there. Cheers Jacob -- - Jacob Erlbeck <jerlbeck(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

8 years, 2 months

4
8
0 0

[PATCH 0/3] Fix handling PDP update messages

by Daniel Willmann

From: Daniel Willmann <daniel(a)totalueberwachung.de> Hello, it seems PDP context updates was never really used/tested to an Update PDP context would not go through. The following patches fix that (at least for gtpv1). Regards Daniel Daniel Willmann (3): gtp: Pass pdp along when calling gtp_req() in gtp_update_context() gtp: Make gtp_update_pdp_conf() work for gtp0 and gtp1 connections gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly gtp/gtp.c | 162 +++++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 118 insertions(+), 44 deletions(-) -- 2.1.4 -- - Daniel Willmann <dwillmann(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

8 years, 2 months

3
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs February 2016