- osmocom-net-gprs - lists.osmocom.org

[PATCH] Add test vectors for EGPRS messages

by Saurabh Sharan

This patch is the test suite modification for the fix encoding of padding bits. New test vectors have been added both in downlink and uplink. --- tests/rlcmac/RLCMACTest.cpp | 7 +++++-- tests/rlcmac/RLCMACTest.ok | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 2 deletions(-)

8 years, 1 month

2
1
0 0

[PATCH] Fix encoding of padding bits to start with 0 bit

by Saurabh Sharan

This patch is for fixing encoding of padding bits according to the 3gpp spec 44.060 section 11, wherein it shall always start with 0 bit followed with spare padding bits. During introduction of basic EGPRS feature new hex dump messages from a different working network log were used in Unit test. These exposed the issue of incorrect handling of padding bits encoding in osmo-pcu. Corrections in the existing test vector of rlcmac is also updated. In testsuite tbf appropriate corrections for the Tbftest.err is also done. --- src/csn1.cpp | 7 ++++++- tests/rlcmac/RLCMACTest.cpp | 6 +++--- tests/rlcmac/RLCMACTest.ok | 18 +++++++++--------- tests/tbf/TbfTest.err | 18 +++++++++--------- 4 files changed, 27 insertions(+), 22 deletions(-)

8 years, 1 month

3
2
0 0

[PATCH 1/2] WIP..

by Holger Freyther

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> --- tests/rlcmac/RLCMACTest.cpp | 8 ++++---- tests/rlcmac/RLCMACTest.ok | 26 +++++++++++++++++--------- 2 files changed, 21 insertions(+), 13 deletions(-) diff --git a/tests/rlcmac/RLCMACTest.cpp b/tests/rlcmac/RLCMACTest.cpp index 66bc53c..124e643 100644 --- a/tests/rlcmac/RLCMACTest.cpp +++ b/tests/rlcmac/RLCMACTest.cpp @@ -89,7 +89,7 @@ void testRlcMacDownlink() std::string testData[] = { "4e082500e3f1a81d080820800b2b2b2b2b2b2b2b2b2b2b", // Packet Downlink Assignment - "48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Assignment + "48282407a6a07422720100032b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Assignment "47240c00400000000000000079eb2ac9402b2b2b2b2b2b", // Packet Uplink Ack Nack "47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b" // Packet Uplink Assignment "4913e00850884013a8048b2b2b2b2b2b2b2b2b2b2b2b2b" @@ -152,9 +152,9 @@ void testRlcMacUplink() bitvec_unhex(resultVector, "2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b"); std::string testData[] = { - "400e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Dummy Control Block - "400b8020000000000000002480e00b2b2b2b2b2b2b2b2b", // Packet Downlink Ack/Nack - "4016713dc094270ca2ae57ef909006aa0fc0001f80222b" // Packet Resource Request + "400e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b", // Packet Uplink Dummy Control Block + "400b8020000000000000002480e0032b2b2b2b2b2b2b2b", // Packet Downlink Ack/Nack + "4016713dc094270ca2ae57ef909006aa0fc0001f80222b", // Packet Resource Request "400a9020000000000000003010012a0800132b2b2b2b2b" }; diff --git a/tests/rlcmac/RLCMACTest.ok b/tests/rlcmac/RLCMACTest.ok index 99117ff..801de42 100644 --- a/tests/rlcmac/RLCMACTest.ok +++ b/tests/rlcmac/RLCMACTest.ok @@ -7,13 +7,13 @@ vector1 = 4e8250e3f1a81d882080b2b2b2b2b2b2b2b2b2b2b vector1 = 4e8250e3f1a81d882080b2b2b2b2b2b2b2b2b2b2b vector2 = 4e8250e3f1a81d882080b2b2b2b2b2b2b2b2b2b2b vector1 == vector2 : TRUE -vector1 = 4828247a6a074227210b2b2b2b2b2b2b2b2b2b2b2b +vector1 = 4828247a6a07422721032b2b2b2b2b2b2b2b2b2b2b =========Start DECODE=========== +++++++++Finish DECODE++++++++++ =========Start ENCODE============= +++++++++Finish ENCODE+++++++++++ -vector1 = 4828247a6a074227210b2b2b2b2b2b2b2b2b2b2b2b -vector2 = 4828247a6a074227210b2b2b2b2b2b2b2b2b2b2b2b +vector1 = 4828247a6a07422721032b2b2b2b2b2b2b2b2b2b2b +vector2 = 4828247a6a07422721032b2b2b2b2b2b2b2b2b2b2b vector1 == vector2 : TRUE vector1 = 4724c040000000079eb2ac9402b2b2b2b2b2b =========Start DECODE=========== @@ -32,21 +32,21 @@ vector1 = 47283c367513ba33304242b2b2b2b2b2b2b2b2b2b2b2b vector2 = 47283c367513ba33304242b2b2b2b2b2b2b2b2b2b2b2b vector1 == vector2 : TRUE UPLINK -vector1 = 40e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +vector1 = 40e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b =========Start DECODE=========== +++++++++Finish DECODE++++++++++ =========Start ENCODE============= +++++++++Finish ENCODE+++++++++++ -vector1 = 40e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b -vector2 = 40e1e61d11f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +vector1 = 40e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b +vector2 = 40e1e61d11d2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b vector1 == vector2 : TRUE -vector1 = 40b802000000002480e0b2b2b2b2b2b2b2b2b +vector1 = 40b802000000002480e032b2b2b2b2b2b2b2b =========Start DECODE=========== +++++++++Finish DECODE++++++++++ =========Start ENCODE============= +++++++++Finish ENCODE+++++++++++ -vector1 = 40b802000000002480e0b2b2b2b2b2b2b2b2b -vector2 = 40b802000000002480e0b2b2b2b2b2b2b2b2b +vector1 = 40b802000000002480e032b2b2b2b2b2b2b2b +vector2 = 40b802000000002480e032b2b2b2b2b2b2b2b vector1 == vector2 : TRUE vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b =========Start DECODE=========== @@ -56,3 +56,11 @@ vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b vector1 = 4016713dc09427ca2ae57ef90906aafc001f80222b vector2 = 4016713dc09427ca2ae57ef90906aafc001f80222b vector1 == vector2 : TRUE +vector1 = 40a90200000000301012a80132b2b2b2b2b +=========Start DECODE=========== ++++++++++Finish DECODE++++++++++ +=========Start ENCODE============= ++++++++++Finish ENCODE+++++++++++ +vector1 = 40a90200000000301012a80132b2b2b2b2b +vector2 = 40a90200000000301012a80132b2b2b2b2b +vector1 == vector2 : TRUE -- 2.6.3

8 years, 1 month

1
1
0 0

[PATCH] Add test vectors for EGPRS messages

by Holger Freyther

This patch is the test suite modification for the fix encoding of padding bits. New test vectors have been added both in downlink and uplink. --- tests/rlcmac/RLCMACTest.cpp | 7 +++++-- tests/rlcmac/RLCMACTest.ok | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 2 deletions(-)

8 years, 1 month

1
1
0 0

[PATCH] WIP: test patchwork test setup please ignore..

by Holger Hans Peter Freyther

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> --- TODO | 2 ++ 1 file changed, 2 insertions(+) diff --git a/TODO b/TODO index a449398..97500c8 100644 --- a/TODO +++ b/TODO @@ -1,4 +1,6 @@ * Make the TBF ul/dl list per BTS + + * Make the SBA per BTS * Make the tbf point to the BTS so we can kill plenty of parameters * Group more into in classes.. remove bts pointers. -- 2.6.3

8 years, 1 month

1
0
0 0

[PATCH] WIP: test patchwork test setup please ignore..

by Holger Hans Peter Freyther

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> --- TODO | 1 + 1 file changed, 1 insertion(+) diff --git a/TODO b/TODO index a449398..b154940 100644 --- a/TODO +++ b/TODO @@ -1,3 +1,4 @@ + * Make the TBF ul/dl list per BTS * Make the SBA per BTS * Make the tbf point to the BTS so we can kill plenty of parameters -- 2.6.3

8 years, 1 month

1
0
0 0

[PATCH] WIP: test patchwork test setup please ignore..

by Holger Hans Peter Freyther

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> --- TODO | 1 + 1 file changed, 1 insertion(+) diff --git a/TODO b/TODO index a449398..b154940 100644 --- a/TODO +++ b/TODO @@ -1,3 +1,4 @@ + * Make the TBF ul/dl list per BTS * Make the SBA per BTS * Make the tbf point to the BTS so we can kill plenty of parameters -- 2.6.3

8 years, 1 month

1
0
0 0

Regarding integration of NURAN L1 1.0

by Prasad Kaup

Hello, We are starting to integrate and test NURAN L1 1.0 with osmo-bts / osmo-pcu at Radisys. We downloaded latest osmo-bts master branch. When we checked the code, we see that NURAN specific code is present in osmo-bts/src/osmo-bts-litecell15. When we tried to compile osmo-bts/src/osmo-bts-litecell15 , we see the following error nrw/litecell15/litecell15.h: No such file or directory Let us know if these files are missing or we are missing some steps. Thanks and regards Prasad

8 years, 1 month

1
0
0 0

[PATCH] Structure modifications for FANR feature

by Aravind Sirsikar

Adds new variable m_fanr_enabled in the gprs_rlcmac_tbf structure Adds new variable m_is_fanr_capable in GprsMs class Adds new variable pan_allowed in mcs_info structure variable This is the fourth patch among series of patches for FANR feature --- src/gprs_coding_scheme.cpp | 60 ++++++++++++++++++++++++++------------------ src/gprs_ms.cpp | 1 + src/gprs_ms.h | 17 +++++++++++++ src/tbf.cpp | 3 ++- src/tbf.h | 14 +++++++++++ 5 files changed, 69 insertions(+), 26 deletions(-) diff --git a/src/gprs_coding_scheme.cpp b/src/gprs_coding_scheme.cpp index 232cee3..53ce868 100644 --- a/src/gprs_coding_scheme.cpp +++ b/src/gprs_coding_scheme.cpp @@ -30,23 +30,24 @@ static struct { unsigned int num_blocks; const char *name; GprsCodingScheme::HeaderType data_hdr; + bool pan_allowed; } mcs_info[GprsCodingScheme::NUM_SCHEMES] = { - {{0, 0}, {0, 0}, 0, 0, "UNKNOWN", GprsCodingScheme::HEADER_INVALID}, - {{23, 0}, {23, 0}, 20, 1, "CS-1", GprsCodingScheme::HEADER_GPRS_DATA}, - {{33, 7}, {33, 7}, 30, 1, "CS-2", GprsCodingScheme::HEADER_GPRS_DATA}, - {{39, 3}, {39, 3}, 36, 1, "CS-3", GprsCodingScheme::HEADER_GPRS_DATA}, - {{53, 7}, {53, 7}, 50, 1, "CS-4", GprsCodingScheme::HEADER_GPRS_DATA}, - - {{26, 1}, {26, 1}, 22, 1, "MCS-1", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3}, - {{32, 1}, {32, 1}, 28, 1, "MCS-2", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3}, - {{41, 1}, {41, 1}, 37, 1, "MCS-3", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3}, - {{48, 1}, {48, 1}, 44, 1, "MCS-4", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3}, - - {{60, 7}, {59, 6}, 56, 1, "MCS-5", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2}, - {{78, 7}, {77, 6}, 74, 1, "MCS-6", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2}, - {{118, 2}, {117, 4}, 56, 2, "MCS-7", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1}, - {{142, 2}, {141, 4}, 68, 2, "MCS-8", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1}, - {{154, 2}, {153, 4}, 74, 2, "MCS-9", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1}, + {{0, 0}, {0, 0}, 0, 0, "UNKNOWN", GprsCodingScheme::HEADER_INVALID,false}, + {{23, 0}, {23, 0}, 20, 1, "CS-1", GprsCodingScheme::HEADER_GPRS_DATA, false}, + {{33, 7}, {33, 7}, 30, 1, "CS-2", GprsCodingScheme::HEADER_GPRS_DATA, false}, + {{39, 3}, {39, 3}, 36, 1, "CS-3", GprsCodingScheme::HEADER_GPRS_DATA, false}, + {{53, 7}, {53, 7}, 50, 1, "CS-4", GprsCodingScheme::HEADER_GPRS_DATA, false}, + + {{26, 1}, {26, 1}, 22, 1, "MCS-1", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, true}, + {{32, 1}, {32, 1}, 28, 1, "MCS-2", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, true}, + {{41, 1}, {41, 1}, 37, 1, "MCS-3", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, true}, + {{48, 1}, {48, 1}, 44, 1, "MCS-4", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_3, false}, + + {{60, 7}, {59, 6}, 56, 1, "MCS-5", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2, true}, + {{78, 7}, {77, 6}, 74, 1, "MCS-6", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_2, true}, + {{118, 2}, {117, 4}, 56, 2, "MCS-7", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1, true}, + {{142, 2}, {141, 4}, 68, 2, "MCS-8", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1, true}, + {{154, 2}, {153, 4}, 74, 2, "MCS-9", GprsCodingScheme::HEADER_EGPRS_DATA_TYPE_1, false}, }; /* CPS table for Header Type 3 */ @@ -132,20 +133,29 @@ uint8_t GprsCodingScheme::get_cps(uint8_t ps, bool is_padding) GprsCodingScheme GprsCodingScheme::getBySizeUL(unsigned size) { + /* The size 31, 37, 46, 66, 84, 124, 148 corresponds to PAN field + * inclusion in egprs UL frame. i.e 4 bytes extra. */ switch (size) { case 23: return GprsCodingScheme(CS1); - case 27: return GprsCodingScheme(MCS1); - case 33: return GprsCodingScheme(MCS2); + case 27: return GprsCodingScheme(MCS1, EGPRS); + case 31: return GprsCodingScheme(MCS1,EGPRS); + case 33:return GprsCodingScheme(MCS2); + case 37: return GprsCodingScheme(MCS2,EGPRS); case 34: return GprsCodingScheme(CS2); case 40: return GprsCodingScheme(CS3); - case 42: return GprsCodingScheme(MCS3); - case 49: return GprsCodingScheme(MCS4); + case 42: return GprsCodingScheme(MCS3,EGPRS); + case 46: return GprsCodingScheme(MCS3,EGPRS); + case 49: return GprsCodingScheme(MCS4,EGPRS); case 54: return GprsCodingScheme(CS4); - case 62: return GprsCodingScheme(MCS5); - case 80: return GprsCodingScheme(MCS6); - case 120: return GprsCodingScheme(MCS7); - case 144: return GprsCodingScheme(MCS8); - case 156: return GprsCodingScheme(MCS9); + case 62: return GprsCodingScheme(MCS5,EGPRS); + case 66: return GprsCodingScheme(MCS5,EGPRS); + case 80: return GprsCodingScheme(MCS6, EGPRS); + case 84: return GprsCodingScheme(MCS6,EGPRS); + case 120: return GprsCodingScheme(MCS7, EGPRS); + case 124: return GprsCodingScheme(MCS7,EGPRS); + case 144: return GprsCodingScheme(MCS8, EGPRS); + case 148: return GprsCodingScheme(MCS8,EGPRS); + case 156: return GprsCodingScheme(MCS9, EGPRS); } return GprsCodingScheme(UNKNOWN); diff --git a/src/gprs_ms.cpp b/src/gprs_ms.cpp index cd4582f..67c3e95 100644 --- a/src/gprs_ms.cpp +++ b/src/gprs_ms.cpp @@ -137,6 +137,7 @@ GprsMs::GprsMs(BTS *bts, uint32_t tlli) : gprs_codel_set_interval(m_codel_state, codel_interval); } m_last_cs_not_low = now_msec(); + m_is_fanr_capable = false; } GprsMs::~GprsMs() diff --git a/src/gprs_ms.h b/src/gprs_ms.h index 3c91e3c..3cd94bd 100644 --- a/src/gprs_ms.h +++ b/src/gprs_ms.h @@ -130,6 +130,8 @@ public: /* internal use */ static void timeout(void *priv_); + bool is_fanr_capable() const; + void set_fanr_capable(bool); protected: void update_status(); GprsMs *ref(); @@ -161,6 +163,11 @@ private: gprs_llc_queue m_llc_queue; bool m_is_idle; + /* member to validate fanr support. will be set after + * after decoding RA capability of the MS + */ + bool m_is_fanr_capable; + int m_ref; LListHead<GprsMs> m_list; struct osmo_timer_list m_timer; @@ -182,6 +189,16 @@ inline bool GprsMs::is_idle() const return !m_ul_tbf && !m_dl_tbf && !m_ref && llist_empty(&m_old_tbfs); } +inline bool GprsMs::is_fanr_capable() const +{ + return this->m_is_fanr_capable; +} + +inline void GprsMs::set_fanr_capable(bool is_fanr_capable) +{ + this->m_is_fanr_capable = is_fanr_capable; +} + inline bool GprsMs::need_dl_tbf() const { if (dl_tbf() != NULL && dl_tbf()->state_is_not(GPRS_RLCMAC_WAIT_RELEASE)) diff --git a/src/tbf.cpp b/src/tbf.cpp index aedb9ae..93dd8c2 100644 --- a/src/tbf.cpp +++ b/src/tbf.cpp @@ -87,7 +87,8 @@ gprs_rlcmac_tbf::gprs_rlcmac_tbf(BTS *bts_, gprs_rlcmac_tbf_direction dir) : m_ta(0), m_ms_class(0), m_ms_list(this), - m_egprs_enabled(false) + m_egprs_enabled(false), + m_fanr_enabled(false) { /* The classes of these members do not have proper constructors yet. * Just set them to 0 like talloc_zero did */ diff --git a/src/tbf.h b/src/tbf.h index 1f5d928..6e482c7 100644 --- a/src/tbf.h +++ b/src/tbf.h @@ -177,6 +177,9 @@ struct gprs_rlcmac_tbf { void enable_egprs(); void disable_egprs(); + bool is_fanr_enabled() const; + void enable_fanr(); + /* attempt to make things a bit more fair */ void rotate_in_list(); @@ -261,6 +264,7 @@ protected: private: LListHead<gprs_rlcmac_tbf> m_ms_list; bool m_egprs_enabled; + bool m_fanr_enabled; mutable char m_name_buf[60]; }; @@ -343,6 +347,16 @@ inline void gprs_rlcmac_tbf::disable_egprs() m_egprs_enabled = false; } +inline bool gprs_rlcmac_tbf::is_fanr_enabled() const +{ + return m_fanr_enabled; +} + +inline void gprs_rlcmac_tbf::enable_fanr() +{ + m_fanr_enabled = true; +} + struct gprs_rlcmac_dl_tbf : public gprs_rlcmac_tbf { gprs_rlcmac_dl_tbf(BTS *bts); -- 1.7.9.5

8 years, 1 month

2
1
0 0

[PATCH] VTY changes for FANR feature

by Aravind Sirsikar

Enables user to Enable/Disable FANR feature from VTY interface This is second patch among series of patches for FANR feature --- src/bts.h | 1 + src/pcu_main.cpp | 4 ++++ src/pcu_vty.c | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 40 insertions(+) diff --git a/src/bts.h b/src/bts.h index ccb8025..7e3ea80 100644 --- a/src/bts.h +++ b/src/bts.h @@ -192,6 +192,7 @@ struct gprs_rlcmac_bts { uint8_t force_two_phase; uint8_t alpha, gamma; uint8_t egprs_enabled; + uint8_t fanr_enabled; uint8_t initial_mcs_dl; uint8_t initial_mcs_ul; uint8_t max_mcs_dl; diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp index 9f38742..32d234d 100644 --- a/src/pcu_main.cpp +++ b/src/pcu_main.cpp @@ -183,6 +183,10 @@ int main(int argc, char *argv[]) bts->initial_mcs_ul = 1; bts->max_mcs_ul = 9; bts->max_mcs_dl = 9; + + bts->egprs_enabled = true; + bts->fanr_enabled = false; + /* CS-1 to CS-4 */ bts->cs_lqual_ranges[0].low = -256; bts->cs_lqual_ranges[0].high = 6; diff --git a/src/pcu_vty.c b/src/pcu_vty.c index edc777d..90c828b 100644 --- a/src/pcu_vty.c +++ b/src/pcu_vty.c @@ -59,6 +59,11 @@ static int config_write_pcu(struct vty *vty) else vty_out(vty, " no egprs%s", VTY_NEWLINE); + if (bts->fanr_enabled) + vty_out(vty, " egprs fanr %s", VTY_NEWLINE); + else + vty_out(vty, " no egprs fanr%s", VTY_NEWLINE); + vty_out(vty, " flow-control-interval %d%s", bts->fc_interval, VTY_NEWLINE); if (bts->fc_bvc_bucket_size) @@ -201,6 +206,34 @@ DEFUN(cfg_pcu_no_egprs, return CMD_SUCCESS; } +#define EGPRS_FANR_STR "EGPRS FANR configuration\n" + +DEFUN(cfg_pcu_egprs_fanr, + cfg_pcu_egprs_fanr_cmd, + "egprs_fanr", + EGPRS_FANR_STR) +{ + struct gprs_rlcmac_bts *bts = bts_main_data(); + + bts->fanr_enabled = 1; + vty_out(vty, "%%EGPRS FANR is enabled %s", VTY_NEWLINE); + + return CMD_SUCCESS; +} + +DEFUN(cfg_pcu_no_egprs_fanr, + cfg_pcu_no_egprs_fanr_cmd, + "no egprs fanr", + NO_STR EGPRS_FANR_STR) +{ + struct gprs_rlcmac_bts *bts = bts_main_data(); + + bts->fanr_enabled = 0; + vty_out(vty, "%%EGPRS FANR is disabled %s", VTY_NEWLINE); + + return CMD_SUCCESS; +} + DEFUN(cfg_pcu_fc_interval, cfg_pcu_fc_interval_cmd, "flow-control-interval <1-10>", @@ -929,6 +962,8 @@ int pcu_vty_init(const struct log_info *cat) vty_install_default(PCU_NODE); install_element(PCU_NODE, &cfg_pcu_egprs_cmd); install_element(PCU_NODE, &cfg_pcu_no_egprs_cmd); + install_element(PCU_NODE, &cfg_pcu_egprs_fanr_cmd); + install_element(PCU_NODE, &cfg_pcu_no_egprs_fanr_cmd); install_element(PCU_NODE, &cfg_pcu_no_two_phase_cmd); install_element(PCU_NODE, &cfg_pcu_cs_cmd); install_element(PCU_NODE, &cfg_pcu_no_cs_cmd); -- 1.7.9.5

8 years, 1 month

2
1
0 0

[PATCH] Fix encoding of padding bits to start with 0 bit

by Saurabh Sharan

This patch is for fixing encoding of padding bits according to the 3gpp spec 44.060 section 11, wherein it shall always start with 0 bit followed with spare padding bits. During introduction of basic EGPRS feature new hex dump messages from a different working network log were used in Unit test. These exposed the issue of incorrect handling of padding bits encoding in osmo-pcu. Corrections in the existing test vector and new hex dump vectors shall be submitted in a separate patch. If only this patch is applied rlcmac testsuite will fail for few vectors. --- src/csn1.cpp | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/csn1.cpp b/src/csn1.cpp index 54cc411..82bf17f 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, 2 months

2
1
0 0

Incorrect Packet Downlink Assignment message in TbfTest.err

by Saurabh Sharan

Hello All, This mail is to highlight the necessity of the "[PATCH] Fix encoding of padding bits to start with 0 bit" In the latest master osmo-pcu 0.2.752-173e, the identified bug in encoding of padding bits is generating incorrect Control message. Example of an incorrect Packet Downlink Assignment message from the current TbfTest.err log is @ line number 3433 Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=0 block=0 data=4f 08 20 00 44 02 00 02 08 04 00 c0 0b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b Incorrect encoding has resulted in the analyzer interpreting PFI present with value 21. Whereas with the fix for encoding padding bits result is Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=0 block=0 data=4f 08 20 00 44 02 00 02 08 04 00 c0 03 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b Output of the message analyzer(http://www.3gpp-message-analyser.com/) is attached in the mail. Please review the patch and let us know procedure for a merge to master. Regards Saurabh

8 years, 2 months

1
0
0 0

[PATCH] Add test vectors for EGPRS messages

by Saurabh Sharan

This patch is the test suite modification for the fix encoding of padding bits. New test vectors have been added both in downlink and uplink. Correction in existing test vector is also done. --- tests/rlcmac/RLCMACTest.cpp | 13 ++++++----- tests/rlcmac/RLCMACTest.ok | 50 +++++++++++++++++++++++++++++++++++-------- 2 files changed, 49 insertions(+), 14 deletions(-)

8 years, 2 months

1
0
0 0

[PATCH] Introduction of new Header Types for FANR

by Prasad.Kaup＠radisys.com

From: Aravind Sirsikar <Arvind.Sirsikar(a)radisys.com> Defines new Header Type structures for FANR Signed-off-by: Prasad Kaup <Prasad.Kaup(a)radisys.com> --- src/rlc.h | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 106 insertions(+), 3 deletions(-) diff --git a/src/rlc.h b/src/rlc.h index f7c5457..81332ce 100644 --- a/src/rlc.h +++ b/src/rlc.h @@ -363,9 +363,55 @@ struct gprs_rlc_dl_header_egprs_1 { uint8_t bsn1_b; uint8_t bsn1_c:1, bsn2_a:7; - uint8_t bsn2_b:3, - cps:5; + cps:5; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.3.1.2 */ +struct gprs_rlc_dl_header_egprs_fanr_type1 { + uint8_t usf:3, + ces_p:3, + pani:1, + tfi_a:1; + uint8_t tfi_b:4, + pr:2, + bsn1_a:2; + uint8_t bsn1_b; + uint8_t bsn1_c:1, + bsn2_a:7; + uint8_t bsn2_b:3, + cps:5; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.3.2.2 */ +struct gprs_rlc_dl_header_egprs_fanr_type2 { + uint8_t usf:3, + ces_p:3, + pani:1, + tfi_a:1; + uint8_t tfi_b:4, + pr:2, + bsn_a:2; + uint8_t bsn_b; + uint8_t bsn_c:1, + cps:3, + dummy:4; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.3.3.2 */ +struct gprs_rlc_dl_header_egprs_fanr_type3 { + uint8_t usf:3, + ces_p:2, + pani:2, + tfi_a:1; + uint8_t tfi_b:4, + pr:2, + bsn_a:2; + uint8_t bsn_b; + uint8_t bsn_c:1, + cps:4, + spb:2, + dummy:1; } __attribute__ ((packed)); struct rlc_li_field { @@ -413,7 +459,7 @@ struct gprs_rlc_ul_header_egprs_2 { dummy:3; } __attribute__ ((packed)); - +/* TS 44.060 10.3a.4.1.1 */ struct gprs_rlc_ul_header_egprs_1 { uint8_t r:1, si:1, @@ -431,6 +477,63 @@ struct gprs_rlc_ul_header_egprs_1 { uint8_t spare2:6, dummy:2; } __attribute__ ((packed)); + +/* TS 44.060 10.3a.4.1.2 */ +struct gprs_rlc_ul_header_egprs_fanr_type1 { + uint8_t r:1, + si:1, + cv:4, + tfi_a:2; + uint8_t tfi_b:3, + bsn1_a:5; + uint8_t bsn1_b:6, + bsn2_a:2; + uint8_t bsn2_b; + uint8_t cps:5, + rsb:1, + pi:1, + pani:1; + uint8_t spare2:6, + dummy:2; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.4.2.2 */ +struct gprs_rlc_ul_header_egprs_fanr_type2 { + uint8_t r:1, + si:1, + cv:4, + tfi_a:2; + uint8_t tfi_b:3, + bsn1_a:5; + uint8_t bsn1_b:6, + cps_a:2; + uint8_t cps_b:1, + rsb:1, + pi:1, + pani:1, + spare:4; + uint8_t spare1:5, + dummy:3; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.4.3.2 */ +struct gprs_rlc_ul_header_egprs_fanr_type3 { + uint8_t r:1, + si:1, + cv:4, + tfi_a:2; + uint8_t tfi_b:3, + bsn1_a:5; + uint8_t bsn1_b:6, + cps_a:2; + uint8_t cps_b:2, + spb:2, + rsb:1, + pi:1, + pani:1, + dummy:1; +} __attribute__ ((packed)); + } inline bool gprs_rlc_v_b::is_state(int bsn, const gprs_rlc_dl_bsn_state type) const -- 2.1.4

8 years, 2 months

1
0
0 0

Public Osmocom User Manuals

by Harald Welte

Dear all, some of you may have already seen it on the RSS feed, on Twitter or on planet.osmocom.org[1]: sysmocom has decided that we will re-release our existing formerly sysmocom-internal User Manuals and VTY reference manuals under GNU GFDL. The hope is that with better documentation we can enable more people to use Osmocom software more easily, leading to more adoption. While those manuals are far from being complete or perfect, I had spent a lot of time in February on further polishing them for the upcoming public release. I do believe they provide a better stasting point than what all of what we had in the wiki (whether old trac or new redmine). The manuals are written in asciidoc[2], with the occasional use of mscgen[3] and graphviz[4], which I believe together are a pretty good set of tools to very efficiently and productively work on documentation, whilst focussing on actual content and not on formatting/syntax like when using docbook-xml or LaTeX. The osmo-gsm-manuals.git repository is pulled by our jenkins installation, which then builds the PDF manuals and pushes them to http://ftp.osmocom.org/docs/latest/ I seriously do hope that we will receive improvements and extensions for the manuals. As the asciidoc source is in yet another git repo, sending patches is as easy as it gets. Holger always states nobody ever contributes to manuals, and I would love to prove him wrong ;) In terms of overlapping information in the wiki and in the manuals: I'm in favor (and in the process) of removing outdated old wiki command line reference and VTY reference sections, and simply referring to the manuals instead. Please do read through the manuals and do send patches, whether it's a spelling fix, improved wording, adding missing information or fixing actual technical mistakes. In tems of further dccumentation improvements, Holger has volunteered to ensure that the Doxygen API of libosmocore is also automatically generated+pushed in a similar fashion to make it publicly web-visible. I'd also encurage everyone to contribute patches to covert those parts of libosmocore.git that don't hve doxygen annotation yet. Thanks in advance! Regards, Harald [1] http://projects.osmocom.org/news/47 [2] http://asciidoc.org/ [3] http://www.mcternan.me.uk/mscgen/ [4] http://www.graphviz.org/ -- - 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)

8 years, 2 months

2
1
0 0

[PATCH] Add constructors to gprs_rlc_v_b and gprs_rlc_v_n

by msuraev＠sysmocom.de

From: Max <msuraev(a)sysmocom.de> Fixes: Coverity: CID 1351738, 1351737 --- src/rlc.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/rlc.h b/src/rlc.h index 54f28df..93f0399 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); @@ -490,6 +490,16 @@ 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) -- 2.7.2

8 years, 2 months

1
0
0 0

[osmo-pcu 0.2.749-22d7] testsuite: 3 failed

by Saurabh Sharan

Hello All, In the latest master, Unit test for TBF is failing. Please find the attached tests/testsuite.log with this mail. I was working on resubmission of padding encoding patch wherein this failure was noticed. Regards Saurabh

8 years, 2 months

3
2
0 0

Support of Fast Ack/Nack reporting in osmoPCU

by Aravind Sirsikar

Hello All, We are currently working on providing the support of Fast Ack/Nack Reporting(FANR) feature in OsmoPCU. We have Identified and listed major changes in OsmoPCU as below. 1) Introduction of new header types in UL/DL a. Mainly due to presence of CES/P and PANI fields 2) Following Control Messages changes a. Packet Downlink Assignment b. Packet Uplink Assignment c. EGPRS Packet Channel Request 3) MS Radio Capability a. Extraction of Reduced Latency Capability 4) VTY interface changes to enable/disable the feature 5) Downlink PAN Handling 6) Uplink PAN Handling 7) RLC window modification a. Introduction of state variable to manage REPORTED and UNREPORTED states in UL direction b. Introduction of new state TENTATIVE_ACK in DL direction 8) TBF flow changes 9) Handling of Tentative Ack blocks during retransmission Note: There may be impacts on osmo-bts. But the impacts has not been considered yet. We plan to have a separate branch from master for this development. Please let us know your valuable feedback. Thanks, Aravind Sirsikar

8 years, 2 months

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, 2 months

2
2
0 0

Clarification on downlink window state variable

by Sangamesh Sajjan

Hello, Clarification required on Downlink window state GPRS_RLC_DL_BSN_RESEND in OSMO-PCU Could you please let us know the significance of the state GPRS_RLC_DL_BSN_RESEND while handling downlink window. Our understanding is that state GPRS_RLC_DL_BSN_RESEND is used in case of retransmission of UNACKED blocks, which can be done without having GPRS_RLC_DL_BSN_RESEND state. Kindly let us know if we are missing something in our understanding. This will help us in enhancing the state variable handling in FANR (FAST ACK NACK REPORTING) feature. We are planning to introduce new state (i.e GPRS_RLC_DL_BSN_TENTATIVE_ACK ) as part of FANR feature implementation. Thanks & Regards, Sangamesh

8 years, 2 months

1
0
0 0

Re: OpenGGSN

by Terje Kristoffer Hybbestad Skow

Thank you very much!! I will have some work getting through this, but I recon I'll have some more questions later. Again thank you 2016-03-01 12:39 GMT+01:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>: > On Tue, Mar 01, 2016 at 11:12:01AM +0100, Terje Kristoffer Hybbestad Skow > wrote: > > The "logfile /tmp/foo" did gave an error message saying "unrecognized > > option". > > It seems the logfile option was added on 2014-03-23 with commit > 9c0ff4fafe4276396125a52c89d36967566fe08c. It may make sense if you build > your osmocom stack from the git sources to benefit from the latest fixes. > > See http://git.osmocom.org, specifically you'd probably want to clone and > build > > git://git.osmocom.org/libosmocore > git://git.osmocom.org/openggsn > > The build steps being for example > > autoreconf -fi > ./configure > make > sudo make install > > > > I'm going to look at DNS packets going through a GGSN to try and find > ways > > to detect DNS tunnels, do you have any recommendations how to do this? > > I do not have the time or resources to use real UE's so I hope to > simulate > > it on a computer using VMs or something like that. > > > I have looked at this: http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS > as > > The BTS is for communicating with a phone over the air interface. Abis and > osmo-nitb are used for voice calls only. The SGSN is needed for real > networks, > you should be fine with the sgsnemu. So all you need is sgsnemu and > openggsn. > > You want to figure out how to use the sgsnemu, starting with a route into > the > tunnel device that sgsnemu opens up. So you need to look at the 'ip route' > commands (if you're on linux). I guess you won't need VMs; granted, it > might > make it easier to avoid circular routes (to IP addresses that should only > be > seen on the GGSN side), but certainly not a necessary prerequisite. > > I tried to ping through the sgsnemu tunnel once but saw, as I mentioned, > that > the GGSN thwarts GTP messages without a proper context being created > first. It > shouldn't be too hard, but I haven't investigated further. So you'd want to > understand the GTP Ctrl & User messages to setup a PGP context (TEIs and > stuff), and figure out how sgsnemu might make your life easier in that > regard. > You probably want to read ETSI 29.060 to figure out GTP: > > http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/03.19.00_60/ts_129… > You may find attached pcap file interesting (open in wireshark and note > that > the DNS queries are transmitted over GTP between SGSN and GGSN even though > wireshark tends to show only the DNS and src/dest enclosed in the GTP). > And again, you may look at > http://git.osmocom.org/openbsc/tree/openbsc/tests/gtphub/gtphub_test.c > about simplistic code examples of composing a PGP context conversation. > > If you'd like any more answers to questions you didn't ask ;) > just give us a shout... > > ~Neels > > -- > - Neels Hofmeyr <nhofmeyr(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 > * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte >

8 years, 2 months

1
0
0 0

Re: OpenGGSN

by Terje Kristoffer Hybbestad Skow

Thank you Neels! The "logfile /tmp/foo" did gave an error message saying "unrecognized option". I'm going to look at DNS packets going through a GGSN to try and find ways to detect DNS tunnels, do you have any recommendations how to do this? I do not have the time or resources to use real UE's so I hope to simulate it on a computer using VMs or something like that. I have looked at this: http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS as an idea of how to set up the testbed, but I do not know which of the nodes I really need. Do you have any idea? Regards Terje Kristoffer Skow 2016-02-29 18:50 GMT+01:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>: > Hey Terje, > > On Mon, Feb 29, 2016 at 12:46:30PM +0100, Terje Kristoffer Hybbestad Skow > wrote: > > Does this mailinglist also regard openGGSN? > > Yes, the Osmocom community has adopted maintenance of OpenGGSN, even > though it > wasn't written "here". > > > If so do I have some questions. I have problem setting it up correctly. > > To test the basic openggsn I used to do something like this: > > > sudo -s > > LD_LIBRARY_PATH=/usr/local/lib ./git/openggsn/ggsn/ggsn -f -c > ./localggsn.conf & > > ./git/openggsn/sgsnemu/sgsnemu --createif -l 127.0.0.1 -r 127.0.0.2 > > > With localggsn.conf as > > listen 127.0.0.2 > net 127.0.0.0/24 > pcodns1 8.8.8.8 > logfile /tmp/foo > > > The above works on linux because it allows implicitly creating the > 127.*.*.* > interfaces. On other OSes, you'd have to create those first on one of your > network interfaces. > > See http://git.osmocom.org/openggsn/tree/examples/ggsn.conf for more > config > options. > > I'd recommend to use wireshark to see what packets are transmitted back and > forth, if you're not already doing that. > > I've "recently" implemented GTPhub, which relays GTP, e.g. through a NAT. > If > that's of interest too, call again, and I can give you an example config > for > testing sgsnemu -> gtphub -> openggsn, too. > > To actually relay data through the tunnel interface that is created, AFAIK > you > first need to send a Create PDP Context message to the GGSN. Maybe read > http://git.osmocom.org/openbsc/tree/openbsc/tests/gtphub/gtphub_test.c > For testing real data, I used an actual sysmoBTS with a "special" SIM card > instead of sgsnemu, because here in the lab that was easier... :P > > Hope to have helped :) > > ~Neels > > > > -- > - Neels Hofmeyr <nhofmeyr(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 > * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte >

8 years, 2 months

2
1
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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 3 months

3
6
0 0

STP in osmocom?

by Kasper Nielsen

Several mails in mailing lists talks about OSMO STP for connecting between two points with sctp and m3ua. I cannot find the OSMO STP code anywhere? Is it public source code?

8 years, 9 months

1
0
0 0

openggsn fails on debian 8

by Kasper Nielsen

when trying to install on clean debian 8 I get errors. This is my bash: ./configure bash: ./configure: No such file or directory running alcohol && automake && autoheader && autoconf also gives lots of errors. How can I install openggsn?

8 years, 11 months

2
9
0 0

[PATCH 1/3] write_queue: Check the result of osmo_wqueue_enqueue and free

by Holger Hans Peter Freyther

The write_queue is designed to have a maximum amount of pending messages and will refuse to take new messages when it has been reached. The caller can decide if it wants to flush the queue and add the message again, create a log. But in all cases the ownership of the msgb has not been transferred. Fix the potential memory leak in the failure situation. --- src/openbts_sock.cpp | 5 ++++- src/sysmo_l1_if.c | 10 ++++++++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/src/openbts_sock.cpp b/src/openbts_sock.cpp index 2d9cae4..5e6f16c 100644 --- a/src/openbts_sock.cpp +++ b/src/openbts_sock.cpp @@ -79,7 +79,10 @@ struct l1fwd_hdl *l1fh = talloc_zero(NULL, struct l1fwd_hdl); int pcu_sock_send(struct msgb *msg) { - osmo_wqueue_enqueue(&l1fh->udp_wq, msg); + if (osmo_wqueue_enqueue(&l1fh->udp_wq, msg) != 0) { + LOGP(DPCU, LOGL_ERROR, "PCU write queue full. Dropping message.\n"); + msgb_free(msg); + } return 0; } diff --git a/src/sysmo_l1_if.c b/src/sysmo_l1_if.c index bef680e..c0721b8 100644 --- a/src/sysmo_l1_if.c +++ b/src/sysmo_l1_if.c @@ -36,7 +36,10 @@ static int l1if_req_pdch(struct femtol1_hdl *fl1h, struct msgb *msg) { struct osmo_wqueue *wqueue = &fl1h->write_q[MQ_PDTCH_WRITE]; - osmo_wqueue_enqueue(wqueue, msg); + if (osmo_wqueue_enqueue(wqueue, msg) != 0) { + LOGP(DL1IF, LOGL_ERROR, "PDTCH queue full. dropping message.\n"); + msgb_free(msg); + } return 0; } @@ -324,7 +327,10 @@ int l1if_pdch_req(void *obj, uint8_t ts, int is_ptcch, uint32_t fn, /* transmit */ - osmo_wqueue_enqueue(&fl1h->write_q[MQ_PDTCH_WRITE], msg); + if (osmo_wqueue_enqueue(&fl1h->write_q[MQ_PDTCH_WRITE], msg) != 0) { + LOGP(DL1IF, LOGL_ERROR, "PDTCH queue full. dropping message.\n"); + msgb_free(msg); + } return 0; } -- 2.3.5

8 years, 11 months

2
1
0 0

[PATCH 1/2] llist: Reduce the external dependencies of this test

by Holger Hans Peter Freyther

Debian is using the classic bfd linker and when passing libosmogb as link dependency it always wants/needs to resolve the bssgp_prim_cb symbol (which is to be provided by the application). Only keep the libosmocore dependency. Fixes: lib/libosmogb.so: undefined reference to `bssgp_prim_cb' collect2: error: ld returned 1 exit status Makefile:511: recipe for target 'llist/LListTest' failed --- tests/Makefile.am | 3 --- 1 file changed, 3 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index b822e46..77760f3 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -56,9 +56,6 @@ ms_MsTest_LDFLAGS = \ llist_LListTest_SOURCES = llist/LListTest.cpp llist_LListTest_LDADD = \ - $(top_builddir)/src/libgprs.la \ - $(LIBOSMOGB_LIBS) \ - $(LIBOSMOGSM_LIBS) \ $(LIBOSMOCORE_LIBS) \ $(COMMON_LA) -- 2.3.5

8 years, 11 months

1
1
0 0

OsmoBTS - OsmocomBB emulation project

by Dominiq T

Dear Osmcom, I am working on a project, where I am connecting OsmoBTS with OsmocomBB without hardware. I am trying to remove l1 on both sides and connect OsmoBTS with BB application via simple unix sockets. Based on the further recommendations, I am using osmobts-trx branch. Currently I am able to handle messages between BTS and TRX driver on clock and control ports, and on BB side I am in state that phone wants to connect into a cell (so its waiting for BCCH) . I am now trying to find a possible way how to handle messages on data port , between BTS – TRX ( TRX is removed, there is my application instead), and forward these messages to my customized BB l1 interface . The thing is that I need to send to BB phone (layer23) messages in structures from gsm_04_08.h (i.e. gsm48_system_information_type_3). I am not sure if I will be able to get needed from the messages coming on the data port 5702. I found, that PCU creates unix socket on “/tmp/pcu_bts” , but only in case sysmoBTS is in use (please correct me if I am wrong), so this will be not possible due compilation errors without HW. Here I found the gsm48_system_information_type_3 messages. So basically I need somehow to get this message structures on my custom l1 BB interface. Do you have any idea how to do this ? Any advice will be highly appreciated. Many thanks you for your attention :) Best regards, Dominik Tamaskovic.

9 years

2
2
0 0

Announcing OsmoDevCon 2015

by Harald Welte

Dear Osmocom.org project members, I'm happy to be able to announce the annual incarnation of OsmoDevCon. The Date is set for March 27 through 30. Venue: As usual, IN-Berlin e.V. in Berlin, Germany. Further details can be obtained from http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2015 Attendance, as usual, is restricted to people with an active history in the Project by contributions in terms of code, patches, discussions, documentation or in other form. = Registration = If you have wiki access, please add yourself to the #Requested section. Alternatively, you can send me private e-mail about it. After review, your (nick)name will be listed in the #Confirmed section. Looking forward to meeting all of you again soon! -- - 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)

9 years, 2 months

1
0
0 0

Re: Configure problem with openggsn

by nisse＠southpole.se

Holger Hans Peter Freyther <hfreyther(a)sysmocom.de> writes: > If you don't want to use linux/if.h then change it? E.g. something > like this? Thanks for the response. I did something similar. I don't have the code in front of me, (and the project where I used openggsn is not very active at the moment), but I think the result of these configure tests are unused. If tun.c never checks HAVE_NET_IF_H, the corresponding configure test could be deleted. Regards, /Niels

9 years, 5 months

1
0
0 0

Fwd: Running OpenGGSN with UmTRX(Osmobts-trx)

by Joe Ge

Hi All, I have installed OpenBSC +Osmo-BTS following Osmocom's netwrok from scratch link http://openbsc.osmocom.org/trac/wiki/network_from_scratch Now I would like to implemenet GPRS facility in the testbedusing OpenGGSN and Osmo-SGSN. I am using fairwaves UmDESK for this implementation. I followed the procedure as suggested in the http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS with the added modification as suggested in https://wush.net/trac/rangepublic/wiki/fairwaves.gprs But this doesn't seem to work out. Currently the systems execute properly with the following outputs *GGSN Output:* root@nist:/home/nist# ggsn cmdline_parser_configfile listen: 127.0.0.1 conf: /etc/ggsn.conf fg: 1 debug: 1 qos: 0x0b921f apn: internet net: 192.168.0.0/24 dynip: 192.168.0.0/24 pidfile: /var/run/ggsn.pid statedir: /var/lib/ggsn/ timelimit: 0 gtpclient: Initialising GTP tunnel openggsn[3822]: GTP: gtp_newgsn() started Creating tun interface Setting tun IP address *Osmo-SGSN Output:* root@nist:/home/nist# osmo-sgsn -c OpenBSC_GPRS/openbsc/openbsc/src/gprs/osmo_sgsn.cfg <0010> gprs_ns.c:199 NSVCI=65534 Creating NS-VC *Osmo-PCU Output:* root@nist:/home/nist# osmo-pcu No config file: 'osmo-pcu.cfg' Using default config. With these I also ran: Osmo-NITB Osmobts-TRX Osmo-TRX All of these run normally as well. My UE is able to detect the network as well but not able to connect with it. Given below are the config file entries *ggsn.conf:* listen 127.0.0.1 *osmo-sgsn.cfg:* gtp local-ip 127.0.0.2 ggsn 0 remote-ip 127.0.0.1 ..... encapsulation udp local-ip 127.0.0.2 *open-bsc.cfg*: gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 127.0.0.2 I had the following doubts regarding the given installation procedure 1. The fairwaves.gprs implementation using Chemeris's gprs-work seems to implement with Asterisk as PBX whereas I require it to run with the osmo-nitb. 2. The gprs-work branch still makes use of BTS transceiver and I wanted it to work with the Osmo-nitb implementation using osmobts-trx and osmo-trx Can somebody please help me out with this? Or is there any alternative implementation which can be tried to execute them together. Looking forward to hearing from you, With Regards, Jijo

9 years, 11 months

2
8
0 0

State of sysmocom/master and upcoming work

by Holger Hans Peter Freyther

Hi, Daniel and me spent another day in the sysmocom office to go through the PCU code. We finished clean-ups, made some simple manual tests and looked at the traces. We will work on the following items during the next weeks: * For DL handling and multi-slot allocation more than one slot will only be allocated _after_ the TBF is re-used. E.g. for a simple download this might mean a single slot is used for the entire download. Daniel made a prototype to send a packet downlink assignment directly _after_ the assignment through the CCCH has completed. We manage to run into a use after free in the TBF code but will work on it. The issue is that the start of a TBF will take a bit longer. We might want to add some heuristic to decide when or when not to do it. * Re-sending and window stalls. When the entire window has been sent once, resending will start but when the ACK/NACK is arrived the resending will conntinue. As it is more likely that frames have arrived we should stop the resending and increase the window. This will increase the throughput. cheers holger -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

10 years, 3 months

1
0
0 0

[PATCH 1/1] Set csnStream direction *after* csnStreamInit

by Daniel Willmann

Fixes a bug introduced in commit 402cdc. That commit sets direction to zero so setting it to 1 should be done after the call to csnStreamInit(). This issue was discovered by the rlcmac test. --- src/csn1.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/csn1.cpp b/src/csn1.cpp index 7f64823..258f7c9 100644 --- a/src/csn1.cpp +++ b/src/csn1.cpp @@ -544,11 +544,11 @@ csnStreamDecoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector, unsig guint8 length = bitvec_read_field(vector, readIndex, length_len); LOGPC(DCSN1, LOGL_NOTICE, "%s length = %d | ", pDescr->sz , (int)length); - arT.direction = 1; bit_offset += length_len; remaining_bits_len -= length_len; csnStreamInit(&arT, bit_offset, length); + arT.direction = 1; Status = serialize(&arT, vector, readIndex, pvDATA(data, pDescr->offset)); if (Status >= 0) -- 1.8.4.2

10 years, 3 months

3
2
0 0

Multislot allocation failures and defects

by Holger Hans Peter Freyther

Dear Andreas, I went through the multislot allocation algorithm and cleaned and structured the code in testable parts that take over parts of the allocation and I have added a unit test for some of the allocation cases (UL first, then DL.. e.g. due a RACH burst and then DL single, UL and DL update). Today morning I added a testcase that tests all PDCH combinations and all MS Classes and verifies that an allocation takes place and that the DL and UL first_common_ts do match. For (xxOxOOxO) and MS_Class=5 this assert is wrong. The alloc/AllocTest of the sysmocom/allocation-cleanups branch should show you this condition. While reading the code I noticed the following things. Could you please explain why these are problems or no problems. * select_first_ts (it exists after the refactoring). It initializes i and compares it but it will never increment it. This means that the code can look at PDCHs _outside_ of the tx_range. * first_common_ts handling. When assigning the DL tbf we pick a first_common_ts but when the actual UL assignment happens there might not be a free USF on the Uplink and at that point the phone might not listen on the TS we think. * Sum for Rx+Tx is not used. I see that in update_rx_win_max you modify the window to make some room. * select_ul_slots. "i" is not incremented in all cases which could potentially lead to using slots outside of the tx_range. For the MS Type == 1 handling you could introduce a different variable that counts how many slots were used? it would be nice if we could fix that during the 30C3. holger -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

10 years, 3 months

2
4
0 0

Coverity issues in gsm_rlcmac.cpp

by Holger Hans Peter Freyther

Dear Ivan, could you please have a look at the coverity issues in the gsm_rlcmac.cpp routines? Uninitialized scalar variable: gsm_rlcmac.cpp:5321 ar.direction not initialized gsm_rlcmac.cpp:5039 ar.direction not initialized gsm_rlcmac.cpp:5155 ar.direction not initialized gsm_rlcmac.cpp:4872 ar.direction not initialized Just initialize it in csnStreamInit? Out-of-bounds read: gsm_rlcmac.cpp:5502 " Overrunning array "data->RLC_DATA" of 20 bytes at byte offset 22 using index "i" (which evaluates to 22)." gsm_rlcmac.cpp:5440 " Overrunning array "data->RLC_DATA" of 20 bytes at byte offset 22 using index "i" (which evaluates to 22)." Maybe just add an assert that dataNumOctets <= 20? -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

10 years, 3 months

4
7
0 0

[PATCH] alloc_algorithm_b: Remove obsolete 'i' incrementation from for-loop

by Andreas Eversberg

--- src/gprs_rlcmac_ts_alloc.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gprs_rlcmac_ts_alloc.cpp b/src/gprs_rlcmac_ts_alloc.cpp index 58dd2e9..366732c 100644 --- a/src/gprs_rlcmac_ts_alloc.cpp +++ b/src/gprs_rlcmac_ts_alloc.cpp @@ -459,7 +459,7 @@ inc_window: "1 slot assigned\n"); break; } - if (++i == ms_max_txslots) { + if (i+1 == ms_max_txslots) { LOGP(DRLCMAC, LOGL_DEBUG, "- Done, because " "slots / window reached maximum " "allowed Tx size\n"); -- 1.8.1.5 --------------010607040705070003040009--

10 years, 3 months

1
0
0 0

[RFC] [ADMIN] Making lists subscriber-only?

by Harald Welte

Dear all, so far the osmocom.org mailing lists have always been in a 'non-members are manually moderated' mode. This has created a lot of work for manual list moderation, where a lot of the messages caught are simply spam, and only the occasional valid message is being received. I'd like to thank the list moderators for taking care of this. However, in more recent discussions, we were considering to move the lists to a completely closed mode, i.e. postings would automatically be rejected from non-members. The automatic response would contain a description of how to subscribe in 'nomail' mode, i.e. to subscribe in a way to be able to post to the list, while still not receiving any incoming traffic. The latter should be fine for occasional posters who don't want the bulk e-mail that goes with a full/regular subscription. Please provide feedback in case you disagree with that change. Unless there is major opposition, we will likely transition to the 'closed' mode within one month. Thanks, 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)

10 years, 3 months

6
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs