osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

6 participants
480 discussions

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

9 years, 3 months

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 >

9 years, 3 months

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 >

9 years, 3 months

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

9 years, 3 months

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

9 years, 3 months

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… >

9 years, 3 months

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

9 years, 3 months

Support of 11 bit RACH support in osmoPCU

by Prasad Kaup

9 years, 3 months

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)

9 years, 3 months

[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

9 years, 3 months

← Newer
1
...
37
38
39
40
41
42
43
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs