osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

5 participants
507 discussions

umerged timing advance patch for pcu
by jolly 10 May '13

10 May '13

hi ivan, there is still one patch left in my jolly/meas branch that has not been mergen: commit 890ae7e4fcf7d74c238ed2ce0e3f090f1af492c2 and the fixup: commit 784f9004ba3576ede57dada63876451f32d2d852 it keeps the timing advance from a TBF and uses it for new TBFs, so the mobile can be at any distance. this was tested up to 4 km (with sysmobts). if it is ok, i will combine these patches and push the result to master. regards, andreas

2 1

PCU VTY tests can not be enabled
by Holger Hans Peter Freyther 25 Apr '13

25 Apr '13

Dear Ivan, it appears to that starting from your configure.ac change the vty tests can not be eanbled anymore. E.g. compare this with the build results on the jenkins after your change. do you have time to fix that today? 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 3

[PATCH] main: The normal way to stop an application is to send SIGTERM, handle it
by Holger Hans Peter Freyther 19 Mar '13

19 Mar '13

From: Holger Hans Peter Freyther <zecke(a)selfish.org> Make the code handle SIGTERM. This way the pcu can be easily stopped with a sysvinit script. --- src/pcu_main.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp index f135cfd..4fae14b 100644 --- a/src/pcu_main.cpp +++ b/src/pcu_main.cpp @@ -114,6 +114,7 @@ void sighandler(int sigset) switch (sigset) { case SIGINT: + case SIGTERM: /* If another signal is received afterwards, the program * is terminated without finishing shutdown process. */ -- 1.7.10.4

2 1

problems with dissecting
by jolly 02 Mar '13

02 Mar '13

hi, steve and me experienced a problem with dissecting a "packet resource request" at pcu. the patch i attached will show the following output: $ make && src/osmo-pcu PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 | Exist_ACCESS_TYPE = 1 | ACCESS_TYPE = 3 | : ID | Choice PacketResourceRequestID = 1 | u.TLLI = 0x7ee0e8fd | : End ID | Exist_MS_Radio_Access_capability = 1 | : MS_Radio_Access_capability | MS_RA_capability_value { | Choice MS_RA_capability_value_Choice = 1 | u.Content length = 34 | RF_Power_Capability = 4 | Exist_A5_bits = 1 | A5_bits = 96 | ES_IND = 1 | PS = 0 | VGCS = 0 | VBS = 0 | Exist_Multislot_capability = 1 | : Multislot_capability | Exist_HSCSD_multislot_class = 0 | Exist_GPRS_multislot_class = 1 | GPRS_multislot_class = 10 .... this is all correct, but then i patched the get_ms_class_by_capability() function at grps_rlcmac_data.c: ... printf("we have = %d\n", cap->Count_MS_RA_capability_value); for (i = 0; i < cap->Count_MS_RA_capability_value; i++) { printf("index=%d\n", cap->MS_RA_capability_value[i].IndexOfAccTech); printf("exists multislot capability %d\n", cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability); printf("exists class %d\n", cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_GPRS_multislot_class); printf("class %d\n", cap->MS_RA_capability_value[i].u.Content.Multislot_capability.GPRS_multislot_class); ... the output continues as this: we have = 2 index=2 exists multislot capability 0 exists class 1 class 10 index=0 exists multislot capability 0 exists class 0 class 0 the "class 10" is correct, also it is correct that the class only exists in the first entry of the capability array. the output of the dissector states that multislot capability exists (Exist_Multislot_capability = 1), but if i look at the structure, this field is not set. i looked at the dissector code, but don't really understand why CSN_NEXT_EXIST works for some elements and not for others. any ideas? regards, andreas

3 4

[ANNOUNCE] OsmoDevCon 2013-04-04 till 2013-04-07, Berlin
by Harald Welte 26 Feb '13

26 Feb '13

Dear fellow Osmcoom developers, it is my pleasure to finally announce the date + venue of OsmoDevCon 2013: Date: April 04 through April 07, 2013 Place: IN-Berlin, Lehrter Str. 53, Berlin Like last year, this is an event for developers of the various Osmocom proejects. Reservation and confirmation of reservation is required. The event is free of charge. The Room is made available by IN-Berlin e.V., an Internet related non-profit organization. Lunch catering will be sponsored (so far by sysmocom GmbH, but if any other sponsors come up, we are happy to share the cost). So all you have to cover is your own travel + accomodation costs, as well as breakfast and dinner. If you are an active developer and cannot afford travel/accomodation, please let me know and I'll see if we can do something about it. If you would like to attend, please send a message to laforge(a)gnumonks.org applying for registration of the event. The registration deadline is March 5, i.e. one week from now. There is no detailed schedule of talks yet. I will start a separate discussion suggesting / collecting topics in the next couple of days. More information is (and will be made) available at http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2013 Further discussion regarding the event should be directed at the osmocom-event-orga(a)lists.osmocom.org mailing list, to avoid cross-posting over the various project-specific lists. Best regards and happy hacking, 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)

1 0

Invalid decoding of some PACKET_RESOURCE_REQUESTs
by Steve Markgraf 19 Feb '13

19 Feb '13

Hi, I noticed a bug in the dissector, which seems to happen when then Exist_A5_bits field is set to 0, and results in the following fields (Exist_Multislot_capability/Exist_GPRS_multislot_class) being decoded incorrectly. Thus, get_ms_class_by_capability() is returning NULL instead of the GPRS_multislot_class, which is interestingly dissected correctly. This is one of the messages where this happens: 4017dfb83a3f628a7045500898f28109100297e0080b2b If I add it to the RLCMACTest it fails, so I propose it should be added ;) My quite recent version of Wireshark (1.8.2) is decoding this message fine, see the attachment. I've gone through the recent changes on packet-gsm_rlcmac.c and packet-csn1.c in Wireshark, but couldn't spot the commit that fixed it so far. Regards, Steve

1 0

Idea for synchonous logging/review of debug + GSMTAP
by Harald Welte 30 Jan '13

30 Jan '13

Hi all, one of the problems when debugging PCU issues is: How to take proper logs on-site where a problem shows up and give them back to the developer(s) for analysis. If you capture the PCU stdout or configure file-based logging, you will have a hard time corellating that with PCAP traces taken on the RLC/MAC side and/or on the Gb side. Therefore I propose a new idea here and would like to get your review: What about implementing a "GSMTAP" log target for libosmocore? This way we could encapsulate the log messages into a special GSMTAP message, which would be sent synchronously in the GSMTAP stream together with RLC/MAC messages on the lower end. The same could in fact be utilized in osmo-bts, too. This way we could capture BTS log/debug output in-order to L1 messages that we receive and transmit. What do you think about it? I would be willing to draft the GSMTAP sub-header format and write + submit the wireshark dissector, if somebody wants to write libosmocore log target. Ideally we would log _all_ messages to that target, and include the subsystem and log level in a header field, so the log verbosity could still be adjusted at the point of review, instead only at the time of logging. Regards, 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)

4 7

Default build is broken since the 17th of January
by Holger Hans Peter Freyther 21 Jan '13

21 Jan '13

Hi, the default build is broken since the 17th of october. Anynone feels responsible to fix it after the merge? Build results can be seen here[1]. It probably has to with enabling sysmobts support but not direct PDCH queue access. holger [1] http://jenkins.osmocom.org/jenkins/job/osmo-pcu/label=linux_i386_debian_squ…

5 10

lack of progress in PCU patch merging / git (ab)use
by Harald Welte 17 Jan '13

17 Jan '13

Dear all, it is a pity to see that since many weeks there has been no progress on merging any of Andreas' work. I think everyone involved is to be blamed to some extent. Andreas because the provided branches are not kept clean, Ivan probably for lack of time, and me for not paying more attention and helping this process along. The general life-cycle in any project, including osmo-pcu, should be as follows: * contributor starts on some improvements, creates private branch * master advances meanwhile * contributor rebases (not merges!) his changes on top of more recent master * contributor indicates that his branch is ready for merge * maintainer merges (some of?) the commits of the contributor branch * contributor re-bases remaining commits on new master * contributor requests merge of remaing patches ... If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I get grey hair (to say the least). One would normally expect: 1) 'jolly' to be based on some (maybe not current) master 2) 'jolly_dsp' to be based on 'jolly' Neither of the two is the case. I've tried to * rebase jolly on top of master as well as * rebase jolly_dsp on top of jolly and both are impossible due to the series of merges and the unclear ancestry / relationship of the branches. Or, just for fun, try 'git diff origin/jolly..origin/jolly_dsp. It shows you anything else but what one would expect Andreas: Please take some time to clean up the mess. Your 'jolly' branch should contain a series of clean per-feature commit's on top of current master, and 'jolly_dsp' should be a set of few patches on top of 'jolly'. This way there is always a clean queue of changesets that Ivan can merge (or cherry-pick). I can understand that if I was in Ivan's place, I would not really know where to even start merging some of those contributions. Thanks for everyone's attention. Please take some time to get this resolved. Let me know if you have some questions. There are plenty of people with lots of git experience around (Holger, Pablo, myself) who can help if something is unclear. Regards, 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)

5 9

Suspected memory leak in PCU
by Harald Welte 16 Jan '13

16 Jan '13

Hi all, while running osmo-pcu, it appears that it is leaking memory. At startup time it consumes 4188 kBytes of virtual memory (on sysmobts-v2), while after about 8MBytes of data transfer of a single GPRS-MS over 48 hours, the virtual size has expanded to 8584 kBytes. Now I know that VSS is not RSS, etc. - but the fact that it always only increasees, and increases with traffic is a clear indication of some leakage somewehere. Unfortunately it also seems talloc is not used correctly in osmo-pcu, as a USR1 signal doesn't really show any allocated objects beyond two. So somehow either not all allocations are done with talloc, or the allocation hierarchy does not link the objects to the root talloc context. Regards, 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)

4 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs