osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

5 participants
507 discussions

Re: Configure problem with openggsn
by nisse＠southpole.se 10 Nov '14

10 Nov '14

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

1 0

Fwd: Running OpenGGSN with UmTRX(Osmobts-trx)
by Joe Ge 16 May '14

16 May '14

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

2 8

State of sysmocom/master and upcoming work
by Holger Hans Peter Freyther 16 Jan '14

16 Jan '14

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

1 0

[PATCH 1/1] Set csnStream direction *after* csnStreamInit
by Daniel Willmann 16 Jan '14

16 Jan '14

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

3 2

Multislot allocation failures and defects
by Holger Hans Peter Freyther 15 Jan '14

15 Jan '14

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

2 4

Coverity issues in gsm_rlcmac.cpp
by Holger Hans Peter Freyther 15 Jan '14

15 Jan '14

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

4 7

[PATCH] alloc_algorithm_b: Remove obsolete 'i' incrementation from for-loop
by Andreas Eversberg 15 Jan '14

15 Jan '14

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

1 0

[RFC] [ADMIN] Making lists subscriber-only?
by Harald Welte 15 Jan '14

15 Jan '14

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)

6 5

Status of sysmocom/master W50
by Holger Hans Peter Freyther 25 Dec '13

25 Dec '13

Good Afternoon, last week at the sysmocom office Daniel and me continued to work on the window handling. We have now a proper abstraction that allows us to unit test the DL and UL window handling. The encode/decode of the RBB is now compatible to itself. While doing our manual tests (sending a big enough ICMP echo request) we noticed that in the alloc algorithm b case the we get a lot of NACKs. In the same setup (only alloc algorithm is changed) the A algorithm has no NACKs. I am now going to re-write the allocation handling. In terms of operation on the first DL assignment (through the PCH) we can only use a singleslot but when re-using the TBF we might go for multislot. In case the of UL handling we could always try to use multislot assignments. Is this understanding correct? 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

3 3

Current list of failures in the pcu
by Holger Hans Peter Freyther 06 Dec '13

06 Dec '13

Good Morning, we at sysmocom continued to add structure/architecture to the PCU code and started to systematically test the code (using something as simple as ICMP ping/reply) Observations: * "alloc algorithm b" has little (3kbit/s) more bandwidth than just using the single slot assignment with CS4. There are also some open coverity issues about this multi slot code. * Congestion is badly handled. When using a ping that creates IP fragments the LLC queue of the TBF gets so long that we expire half the IP fragments before sending them. This means the MS at the downlink never receives all the IP fragments of a PING. We played with the BSVC-FLOW-CONTROL parameters but they don't have any influence here. We have added counting of queue size and calculation of the average queue delay to the LLC class. One option is to drop packages based on the PDU lifetime and the current queue delay. $ sudo ping -s 1800 -i 0.1 10.23.42.6 (CS4, alloc-algorithm a) is enough to re-produce this issue. * RLC V(Q) V(R) handling. It appears that after and before the refactoring the Received Block Bitmap (RBB) is wrongly encoded. The encode and decode are not compatible to each other (thanks to the architecture sysmocom is adding to the code this can now be unit tested!). So as soon as we don't receive a frame from the UL. The send window at the phone and the PCU is going out of sync. After making changes to the window we have also witnesses that on a fully received window V(Q) and V(R) were WindowSize away from each other. <0005> tbf.cpp:1579 UL DATA TFI=0 received (V(Q)=55 .. V(R)=60) <0005> tbf.cpp:1624 - BSN 60 storing in window (55..118) <0005> rlc.cpp:173 - Raising V(R) to 61 <0005> tbf.cpp:1690 - Scheduling Ack/Nack, because 20 frames received. <0005> encoding.cpp:374 Encoding Ack/Nack for TBF(TFI=0 TLLI=0xfa45049d DIR=UL) (final=0) SSN=61 <0005> encoding.cpp:408 - V(N): "RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR" R=Received N=Not-Received This part might be something we broke but we will try to re-produce with a unit test. We will continue to work on unit-testing the RLC window handling if anyone outside sysmocom interested in getting a more stable PCU? 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

2 2

← Newer
1
...
42
43
44
45
46
47
48
...
51
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs