osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

5 participants
507 discussions

[PATCH] Add test vectors for EGPRS messages
by Saurabh Sharan 08 Mar '16

08 Mar '16

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(-)

1 0

[PATCH] Introduction of new Header Types for FANR
by Prasad.Kaup＠radisys.com 08 Mar '16

08 Mar '16

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

1 0

Public Osmocom User Manuals
by Harald Welte 07 Mar '16

07 Mar '16

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)

2 1

[PATCH] Add constructors to gprs_rlc_v_b and gprs_rlc_v_n
by msuraev＠sysmocom.de 03 Mar '16

03 Mar '16

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

1 0

[osmo-pcu 0.2.749-22d7] testsuite: 3 failed
by Saurabh Sharan 03 Mar '16

03 Mar '16

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

3 2

Support of Fast Ack/Nack reporting in osmoPCU
by Aravind Sirsikar 03 Mar '16

03 Mar '16

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

1 0

Support of 11 bit RACH support in osmoPCU
by Prasad Kaup 03 Mar '16

03 Mar '16

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

2 2

Clarification on downlink window state variable
by Sangamesh Sajjan 03 Mar '16

03 Mar '16

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

1 0

Re: OpenGGSN
by Terje Kristoffer Hybbestad Skow 01 Mar '16

01 Mar '16

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 >

1 0

Re: OpenGGSN
by Terje Kristoffer Hybbestad Skow 01 Mar '16

01 Mar '16

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 >

2 1

← Newer
1
...
39
40
41
42
43
44
45
...
51
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs