From arnysch at gmx.net Tue Nov 8 12:42:29 2011 From: arnysch at gmx.net (Arnold Schulz) Date: Tue, 08 Nov 2011 13:42:29 +0100 Subject: [PATCH] Solved: LCR + Asterisk + NanoBTS: Strange Voice Behaviour "Dropping incompatible voice frame on lcr/1" In-Reply-To: <7670e91391aa.4e9f2782@studenti.unimi.it> References: <75a0b6309ba6.4e9f0bc3@studenti.unimi.it> <7660940dbf0a.4e9f231f@studenti.unimi.it> <7670e91391aa.4e9f2782@studenti.unimi.it> Message-ID: <4EB923B5.7030707@gmx.net> Hello everyone, Am 19.10.2011 19:39, schrieb Luca Bongiorni: > As you can see from Asterisk, there is a mismatch: > "NOTICE[2315]: channel.c:2960 __ast_read: Dropping incompatible voice frame on lcr/1 of format alaw since our native format has changed to 0x0 (nothing)" got same error on my Arm big endian system. Attached patch fixes this. Could this be applied to the sources on git.misdn.eu (Andreas?, ...?). Cheers, Arnold -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lcr-git.misdn.eu-20111107.patch URL: From andreas at eversberg.eu Tue Nov 8 15:17:21 2011 From: andreas at eversberg.eu (Andreas Eversberg) Date: Tue, 08 Nov 2011 16:17:21 +0100 Subject: [PATCH] Solved: LCR + Asterisk + NanoBTS: Strange Voice Behaviour "Dropping incompatible voice frame on lcr/1" In-Reply-To: <4EB923B5.7030707@gmx.net> References: <75a0b6309ba6.4e9f0bc3@studenti.unimi.it> <7660940dbf0a.4e9f231f@studenti.unimi.it> <7670e91391aa.4e9f2782@studenti.unimi.it> <4EB923B5.7030707@gmx.net> Message-ID: <4EB94801.8090406@eversberg.eu> Arnold Schulz wrote: > Could this be applied to the sources on git.misdn.eu > (Andreas?, ...?). thanx, applied! From andreas at eversberg.eu Tue Nov 1 09:04:38 2011 From: andreas at eversberg.eu (jolly) Date: Tue, 01 Nov 2011 10:04:38 +0100 Subject: [RFC] MNCC introduce a hello packet to include a version number In-Reply-To: <4EAA6A94.8020208@freyther.de> References: <4EA16304.4010201@freyther.de> <4EAA6A94.8020208@freyther.de> Message-ID: <4EAFB626.7060801@eversberg.eu> hi holger, it is fine for me. when you apply it, be sure to add it to osmocombb too, since it will use the sam e interface. regards, andreas Holger Hans Peter Freyther wrote: > On 10/21/2011 02:18 PM, Holger Hans Peter Freyther wrote: >> Hi Jolly, all, > > Hi, > is the approach okay? > > holger From laforge at gnumonks.org Thu Nov 10 14:07:44 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 10 Nov 2011 15:07:44 +0100 Subject: GSM network at 28C3 Message-ID: <20111110140744.GN23710@prithivi.gnumonks.org> Hi all, I wanted to write this mail earlier, but somehow didn't get around to. MAny people have been assuming that there again will be a GSM network at the 28C3 conference in late december. However, given the large amount of work that was involved in the GSM network at the camp this summer, I have decided that I want to pull out a bit of this network operation. This means that I hope there will be some other project members that will step up to make it happen again. I've already applied for the regulatory license some 4 weeks ago (no response yet, but I doubt there will be any problems). So that should be OK (6 ARFCN, GSM 1800, 200mW each, indoor). The BTSs have always come from a quite large number of individuals and companies, and I'm sure we will be able to pool them together again. Whoever is able to provide a GSM1800 nanoBTS during the event should probably add themselves (and the number of BTS) to the following wiki page: http://openbsc.osmocom.org/trac/wiki/FieldTests/28c3 The BTSs will have to be available from at least 23rd of december to 31st december. Likely they'll be unmounted on 30th night, but nobody can guarantee that. What needs to be done: * BTS physical installation, patching + PoE This is typically done on dec 24 or 25, depends a bit when roh is doing the patching and when the house technicians lift up the big cross beam in the main hall * configuring osmo-nitb + LCR to connect with the POC, do some testing This again involves getting some physical E1 line from/to the PoC patched, and when the POC is available for configuring their side of the link * programming of SIM cards we have some 100 to 150 left-over 16in1 sim cards from the camp, but sysmocom will soon receive 1000 sysmoSIM' cards. Those cards store only one IMSI (not 16), but are otherwise much more flexible in terms of programming. You can create any file (DF/EF) and put any content inside, even files not specified in TS 11.11. The cards will need to be programmed (simple, quick). sysmocom will take care they are of that. * selling of SIM cards In the past, this has been done by the POC. However, there has been some discontempt with the fact that they get all the user questions and cannot do anything regarding GSM, and also they never got any share of the money (not that we made huge profits on it anyway). So I'd suggest to involve the POC more in the network, give them telnet access to the BSC so they can try to anlyze problems themselves, and maybe see if (at least in the beginning) one of the OpenBSC project members could spend some time at the POC desk to help with SIM card sales and user questions * putting together a publik wiki page (mostly copy+paste from last year) * Testing of newer BTSs. Both Fairwaves as well as sysmocom are develoing some new BTSs. We probably don't want them operational during all of the event, the network should run on nanoBTS. But when we feel like doing a test, we will shut down one nanoBTS and start up one of the new BTS models and check for bugs / performance. All in all, I will not be gone completely from the even GSM network but still be around and willing to help if some nasty problem needs to be debugged. And thanks at this point for the kind help of Peter Stuge and Khorben for helping with GSM @ the camp, as well as the POC for the SIM card sales in past years! [please make sure to keep the Cc list of this mail, as I don't think the POC guys are on the openbsc list...] Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andreas at eversberg.eu Thu Nov 10 15:37:42 2011 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 10 Nov 2011 16:37:42 +0100 Subject: GSM network at 28C3 In-Reply-To: <20111110140744.GN23710@prithivi.gnumonks.org> References: <20111110140744.GN23710@prithivi.gnumonks.org> Message-ID: <4EBBEFC6.1080909@eversberg.eu> Harald Welte wrote: > This means that I hope there will be some other project members that > will step up to make it happen again. > hi harald, me and a friend will arrive on day 0 (december 26th). we can help to setup the network and test it. additionally we can set up a mobile helpdesk for selling (programming) SIM cards and answering questions. i try to get tables and seats close to the POC again. therefore i would appreciate to get in contact with the orga. regards, andreas p.s. since the gym is not open on day 0, we're still looking for a place to stay for the night. (in case there is something left of that night...:) From 246tnt at gmail.com Thu Nov 10 20:21:52 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 10 Nov 2011 21:21:52 +0100 Subject: GSM network at 28C3 In-Reply-To: <20111110140744.GN23710@prithivi.gnumonks.org> References: <20111110140744.GN23710@prithivi.gnumonks.org> Message-ID: Hi, I have two rugby 1800 (that can be put as multi-trx) and by then I should also have two Nokia E1 units. Since I'm not local I'd have to ship them to someone before the event and ship them back after. So not the most practical solution but at least if there isn't enough "local" BTS, they're available. I'm only getting to Berlin on Day 0 in the early afternoon (landing at TXL at 1115 + a good 1h30 for TXL->Hotel->BCC). I can help with whatever if left to do when I get there (config / cabling / whatever) And I'd be happy to help test / debug the newer BTS models during the event and also help track down bug as they happen :) wrt to the Wiki: I didn't find how to create an account ... maybe it's not enabled yet. Cheers, Sylvain From jluebbe at lasnet.de Fri Nov 11 10:25:43 2011 From: jluebbe at lasnet.de (Jan =?ISO-8859-1?Q?L=FCbbe?=) Date: Fri, 11 Nov 2011 11:25:43 +0100 Subject: GSM network at 28C3 In-Reply-To: <20111110140744.GN23710@prithivi.gnumonks.org> References: <20111110140744.GN23710@prithivi.gnumonks.org> Message-ID: <1321007143.18823.7.camel@polaris.local> Hi! On Thu, 2011-11-10 at 15:07 +0100, Harald Welte wrote: > What needs to be done: > > * BTS physical installation, patching + PoE > This is typically done on dec 24 or 25, depends a bit when roh is > doing the patching and when the house technicians lift up the big > cross beam in the main hall > * configuring osmo-nitb + LCR to connect with the POC, do some testing > This again involves getting some physical E1 line from/to the PoC > patched, and when the POC is available for configuring their side of > the link I could arrive around 10 am on the 25th and help with that. If that's not needed, I'd arrive on the 26th. > * programming of SIM cards > we have some 100 to 150 left-over 16in1 sim cards from the camp, but > sysmocom will soon receive 1000 sysmoSIM' cards. Those cards store > only one IMSI (not 16), but are otherwise much more flexible in terms > of programming. You can create any file (DF/EF) and put any content > inside, even files not specified in TS 11.11. > The cards will need to be programmed (simple, quick). sysmocom will > take care they are of that. You mean they will already be programmed? Otherwise I'd have no problem with handling that like at the Camp. > * selling of SIM cards > In the past, this has been done by the POC. However, there has been > some discontempt with the fact that they get all the user questions > and cannot do anything regarding GSM, and also they never got any > share of the money (not that we made huge profits on it anyway). > > So I'd suggest to involve the POC more in the network, give them > telnet access to the BSC so they can try to anlyze problems > themselves, and maybe see if (at least in the beginning) one of the > OpenBSC project members could spend some time at the POC desk to help > with SIM card sales and user questions At least for some shifts I'd be willing to handle this. > * putting together a publik wiki page (mostly copy+paste from last year) I've adjusted the page from last year and stored it in the OpenBSC wiki as the Congress wiki is not open yet. http://openbsc.osmocom.org/trac/wiki/FieldTests/28c3/CongressWiki Regards, Jan From peter at stuge.se Fri Nov 11 15:20:18 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 11 Nov 2011 16:20:18 +0100 Subject: GSM network at 28C3 In-Reply-To: <20111110140744.GN23710@prithivi.gnumonks.org> References: <20111110140744.GN23710@prithivi.gnumonks.org> Message-ID: <20111111152018.23094.qmail@stuge.se> Harald Welte wrote: > * BTS physical installation, patching + PoE > This is typically done on dec 24 or 25 I don't know if I will be in Berlin 24-25, if yes then I will help with installation. > * configuring osmo-nitb + LCR to connect with the POC, do some testing > This again involves getting some physical E1 line from/to the PoC > patched, and when the POC is available for configuring their side of > the link I'll help with this too. I expect POC will be well prepared and early on site at c3 like they were at camp, and I think it's critical for our credibility at POC, with the organizers and ultimately with our network users that we set up MOC in parallel. The lesson learned at camp is that it is really key to execute setup earlier than neccessary. Day 0 is *much* too late. If we can not be on site 24 and 25 then we need to prepare and test setup before the 24th. > * selling of SIM cards > In the past, this has been done by the POC. However, there has been > some discontempt with the fact that they get all the user questions > and cannot do anything regarding GSM, and also they never got any > share of the money (not that we made huge profits on it anyway). POC feedback at camp was fairly clear; they're happy to sell SIM cards as long as the network is stable, so that they do not get swamped with mobile questions for which they have no answers and no way to find information. As for sharing profit, I think that it's only fair to contribute to the POC coffee fund with some money left over from SIM sales. > So I'd suggest to involve the POC more in the network, give them > telnet access to the BSC so they can try to anlyze problems > themselves, I don't mind giving POC access, but this assumes that POC has interest in OpenBSC, which I don't think is so wise. Not that POC can not or will not have interest, but it's not good to depend on that, and they would also be starting nearly from scratch learning about OpenBSC, which is not the position you want to be in as helpdesk staff. > and maybe see if (at least in the beginning) one of the > OpenBSC project members could spend some time at the POC > desk to help with SIM card sales and user questions I disagree. Either we have MOC and POC at the same table, or we decide that MOC will have no public helpdesk at all, and we arrange a private channel for the POC helpdesk to talk to second level MOC staff. A dedicated MOC helpdesk is of course hugely preferable for network users. It is not so easy to decide on what to do in this situation. I think many of the candidates for cluey MOC staff are looking forward to doing development work together during the congress, rather than doing operations. I think the two are nearly mutually exclusive.. //Peter From holger at freyther.de Mon Nov 14 08:02:58 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 14 Nov 2011 09:02:58 +0100 Subject: GSM network at 28C3 In-Reply-To: <20111110140744.GN23710@prithivi.gnumonks.org> References: <20111110140744.GN23710@prithivi.gnumonks.org> Message-ID: <4EC0CB32.8060400@freyther.de> On 11/10/2011 03:07 PM, Harald Welte wrote: > Hi all, > > The BTSs have always come from a quite large number of individuals and > companies, and I'm sure we will be able to pool them together again. > Whoever is able to provide a GSM1800 nanoBTS during the event should > probably add themselves (and the number of BTS) to the following wiki > page: http://openbsc.osmocom.org/trac/wiki/FieldTests/28c3 Hi all, we have had some volunteers. I would propose to introduce some more clear responsibilities to avoid a bad surprise on ground: - Who will handle the communication toward the POC, show them how to monitor/access the system, make sure we 'staff' user support? Like now and once we are at the venue? - Who will be picking up equipment and return it (nanoBTS, ask harald for his netgear PoE switches, patch cable, locks), emphasis is in properly returning the equipment, but probably also equipment for the radio room itself. Do we have the radio room? - Who will handle the communication toward the NOC/roh to get our GSM network patched up properly. This might require being at the venue on the 24th/25th. - Radio Room/Door Control, do we have the radio room? Who wants to makes sure we have the key(s) in time? Responsibility will be also to lock the room he/she leaves.. make sure it is never empty. should we have other tasks, anyone wants to step up? holger From andreas at eversberg.eu Mon Nov 14 08:29:44 2011 From: andreas at eversberg.eu (jolly) Date: Mon, 14 Nov 2011 09:29:44 +0100 Subject: GSM network at 28C3 In-Reply-To: <4EC0CB32.8060400@freyther.de> References: <20111110140744.GN23710@prithivi.gnumonks.org> <4EC0CB32.8060400@freyther.de> Message-ID: <4EC0D178.5060409@eversberg.eu> Holger Hans Peter Freyther wrote: > - Who will handle the communication toward the POC, show them how to > monitor/access the system, make sure we 'staff' user support? Like > now and once we are at the venue? > hi holger, since i plan to setup a "MOC" with tables and seats close to the POC, i can handle the communication toward the POC. regards, andreas From 246tnt at gmail.com Fri Nov 11 14:56:21 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 11 Nov 2011 15:56:21 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer Message-ID: Hi, While updating libosmocore in osmocom-bb, a problem arised: 100%CPU usage and hanging. Turns out 'mobile' sometimes call osmo_timer_schedule for an already scheduled timer. Obviously this used to work and now it doesn't. The question is : Was there a defined semantics for this case previously ? Or is it supposed to be unsupported ? What would you expect it to do ? Cheers, Sylvain From laforge at gnumonks.org Fri Nov 11 17:50:31 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 11 Nov 2011 18:50:31 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: References: Message-ID: <20111111175031.GM4627@prithivi.gnumonks.org> Hi all, On Fri, Nov 11, 2011 at 03:56:21PM +0100, Sylvain Munaut wrote: > While updating libosmocore in osmocom-bb, a problem arised: 100%CPU > usage and hanging. Turns out 'mobile' sometimes call > osmo_timer_schedule for an already scheduled timer. > > Obviously this used to work and now it doesn't. The question is : Was > there a defined semantics for this case previously ? Or is it supposed > to be unsupported ? What would you expect it to do ? I think a second/follow-up timer_schedule should re-schedule the existing timer safely. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pablo at gnumonks.org Sat Nov 12 21:55:55 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sat, 12 Nov 2011 22:55:55 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: <20111111175031.GM4627@prithivi.gnumonks.org> References: <20111111175031.GM4627@prithivi.gnumonks.org> Message-ID: <20111112215555.GA12856@1984> On Fri, Nov 11, 2011 at 06:50:31PM +0100, Harald Welte wrote: > Hi all, > > On Fri, Nov 11, 2011 at 03:56:21PM +0100, Sylvain Munaut wrote: > > While updating libosmocore in osmocom-bb, a problem arised: 100%CPU > > usage and hanging. Turns out 'mobile' sometimes call > > osmo_timer_schedule for an already scheduled timer. > > > > Obviously this used to work and now it doesn't. The question is : Was > > there a defined semantics for this case previously ? Or is it supposed > > to be unsupported ? What would you expect it to do ? > > I think a second/follow-up timer_schedule should re-schedule the > existing timer safely. The patch attached should recover the former behaviour, sorry for missing this case. From pablo at gnumonks.org Sat Nov 12 21:52:10 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sat, 12 Nov 2011 22:52:10 +0100 Subject: [PATCH] timer: fix active timer re-scheduling situation Message-ID: This patch re-adds support the timer re-scheduling situation which used to be supported until I introduced the rb-tree based timer. Signed-off-by: Pablo Neira Ayuso --- src/timer.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/timer.c b/src/timer.c index 6852983..e68040f 100644 --- a/src/timer.c +++ b/src/timer.c @@ -68,6 +68,7 @@ static void __add_timer(struct osmo_timer_list *timer) */ void osmo_timer_add(struct osmo_timer_list *timer) { + osmo_timer_del(timer); timer->active = 1; INIT_LLIST_HEAD(&timer->list); __add_timer(timer); -- 1.7.2.5 --FCuugMFkClbJLl1L-- From 246tnt at gmail.com Sat Nov 12 22:07:03 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 12 Nov 2011 23:07:03 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: <20111112215555.GA12856@1984> References: <20111111175031.GM4627@prithivi.gnumonks.org> <20111112215555.GA12856@1984> Message-ID: > The patch attached should recover the former behaviour, sorry for > missing this case. Oops, sorry, we actually continued on IRC. Look at the first few commits of http://cgit.osmocom.org/cgit/libosmocore/log/?h=sylvain/for_jolly They bring in some fixes/cleanups from the kernel for rbtree then something that fixes the timer. This patch keeps the list head intact and just remove the timer from the tree and re-adds it at the right place. Cheers, Sylvain From pablo at gnumonks.org Sun Nov 13 00:28:30 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 01:28:30 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: References: <20111111175031.GM4627@prithivi.gnumonks.org> <20111112215555.GA12856@1984> Message-ID: <20111113002830.GA13256@1984> On Sat, Nov 12, 2011 at 11:07:03PM +0100, Sylvain Munaut wrote: > > The patch attached should recover the former behaviour, sorry for > > missing this case. > > Oops, sorry, we actually continued on IRC. > > Look at the first few commits of > http://cgit.osmocom.org/cgit/libosmocore/log/?h=sylvain/for_jolly > > They bring in some fixes/cleanups from the kernel for rbtree then > something that fixes the timer. This patch keeps the list head intact > and just remove the timer from the tree and re-adds it at the right > place. Hm, I think I found one weird scenario which is not handled fine with your patch. Say you have two timers A and B. Assume both expire on the same time (and they are inserted in the eviction list in this order, first A, then B). Then, A re-schedules B in its callback. B is reinserted in the tree, however, B is still in the eviction list. With aeeb7070f84437aa608a3d843346b1efa916d175, since we don't touch the list head. B will be removed from the tree, but I think it should remain there as it has been rescheduled. Yes, this scenario is strange, but I think we try to cover all possible situations. So I think my patch should be applied instead. Thanks for collecting the patches that went into rbtree.c in the linux kernel, btw. From 246tnt at gmail.com Sun Nov 13 09:07:58 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 13 Nov 2011 10:07:58 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: <20111113002830.GA13256@1984> References: <20111111175031.GM4627@prithivi.gnumonks.org> <20111112215555.GA12856@1984> <20111113002830.GA13256@1984> Message-ID: > Hm, I think I found one weird scenario which is not handled fine with > your patch. > > Say you have two timers A and B. Assume both expire on the same time > (and they are inserted in the eviction list in this order, first A, > then B). Then, A re-schedules B in its callback. B is reinserted > in the tree, however, B is still in the eviction list. > > With aeeb7070f84437aa608a3d843346b1efa916d175, since we don't > touch the list head. B will be removed from the tree, but I think it > should remain there as it has been rescheduled. > > Yes, this scenario is strange, but I think we try to cover all possible > situations. So I think my patch should be applied instead. You're right. Even worse, with my patch during the scan of the eviction list, we'll call the new B callback with the new B data at the old time. > Thanks for collecting the patches that went into rbtree.c in the linux > kernel, btw. fyi, I skipped the few last ones that add a new "augmented rb tree" functionality that we don't need (yet?). Cheers, Sylvain From pablo at gnumonks.org Sun Nov 13 16:06:34 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 17:06:34 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: References: <20111111175031.GM4627@prithivi.gnumonks.org> <20111112215555.GA12856@1984> <20111113002830.GA13256@1984> Message-ID: <20111113160634.GB16578@1984> Hi Sylvain, On Sun, Nov 13, 2011 at 10:07:58AM +0100, Sylvain Munaut wrote: [...] > > Thanks for collecting the patches that went into rbtree.c in the linux > > kernel, btw. > > fyi, I skipped the few last ones that add a new "augmented rb tree" > functionality that we don't need (yet?). That skipping is fine to me, we can get it if we ever need it. From 246tnt at gmail.com Sun Nov 13 15:56:39 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 13 Nov 2011 16:56:39 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: <20111113104527.GX4627@prithivi.gnumonks.org> References: <20111111175031.GM4627@prithivi.gnumonks.org> <20111112215555.GA12856@1984> <20111113002830.GA13256@1984> <20111113104527.GX4627@prithivi.gnumonks.org> Message-ID: Hi, >> Yes, this scenario is strange, but I think we try to cover all possible >> situations. So I think my patch should be applied instead. > > Will the two of you please figure out what is the best option to > proceed? Revert one of Sylvains patches and apply Pablos patch? I applied Pablo's patch this morning after testing it worked as well. Cheers, Sylvain From pablo at gnumonks.org Sun Nov 13 16:05:16 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 17:05:16 +0100 Subject: new timer code: semantics of osmo_timer_schedule for already scheduled timer In-Reply-To: <20111113104527.GX4627@prithivi.gnumonks.org> References: <20111111175031.GM4627@prithivi.gnumonks.org> <20111112215555.GA12856@1984> <20111113002830.GA13256@1984> <20111113104527.GX4627@prithivi.gnumonks.org> Message-ID: <20111113160516.GA16578@1984> On Sun, Nov 13, 2011 at 11:45:28AM +0100, Harald Welte wrote: > Hi Pablo and Sylvain, > > On Sun, Nov 13, 2011 at 01:28:30AM +0100, Pablo Neira Ayuso wrote: > > > Hm, I think I found one weird scenario which is not handled fine with > > your patch. [...] > > > > Yes, this scenario is strange, but I think we try to cover all possible > > situations. So I think my patch should be applied instead. > > Will the two of you please figure out what is the best option to > proceed? Revert one of Sylvains patches and apply Pablos patch? I think so. I can make it myself if you want. From alexander.huemer at xx.vu Sat Nov 12 09:41:11 2011 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sat, 12 Nov 2011 10:41:11 +0100 Subject: commitlog ML improvements Message-ID: <20111112094111.GB19922@de.xx.vu> Hi all, I personally would like to keep track of the changes that happen in most of the osmocom git repositories. Generally there are currently two ways to do that. a) The atom feed that cgit offers, e.g. http://cgit.osmocom.org/cgit/osmocom-bb/atom/?h=jolly/testing cgit does not offer this feature in a way firefox would recognize, but it works. Atom feeds are quite convenient, but in the way this works ATM one has to opt-in explicitly to every branch one wants to "follow". Newly created branches are not advertised, ... b) The commitlog ML, which does not have any of the drawbacks of the cgit atom feed, but does not show the actual patch, in case there is one, only the revision hash. There are several thinkable ways to bring together the best of both systems, IMHO the easiest thing to do is modify the way the commitlog ML composes its emails. The example post-receive-email scripts of git (1.7.8rc1) contains the following comment: # hooks.showrev # The shell command used to format each revision in the email, with # "%s" replaced with the commit id. Defaults to "git rev-list -1 # --pretty %s", displaying the commit id, author, date and log # message. To list full patches separated by a blank line, you # could set this to "git show -C %s; echo". # To list a gitweb/cgit URL *and* a full patch for each change set, # use this: # "t=%s; printf 'http://.../?id=%%s' \$t; echo;echo; git show -C # \$t; echo" # Be careful if "..." contains things that will be expanded by shell # "eval" # or printf. The whole file is attached. As stated on IRC, I think pasting the patches in the emails would be most convenient, must takes up quite some space in mailboxes over time. Of course that problem would be addressable with rm and there is gmane/tin, ... In any case, an added cgit link does not harm and also provides an easy way to read the patches. Any comments and ideas how to do a similar RSS/atom feed welcome! Kind regards -Alex -------------- next part -------------- #!/bin/sh # # Copyright (c) 2007 Andy Parkins # # An example hook script to mail out commit update information. This hook # sends emails listing new revisions to the repository introduced by the # change being reported. The rule is that (for branch updates) each commit # will appear on one email and one email only. # # This hook is stored in the contrib/hooks directory. Your distribution # will have put this somewhere standard. You should make this script # executable then link to it in the repository you would like to use it in. # For example, on debian the hook is stored in # /usr/share/git-core/contrib/hooks/post-receive-email: # # chmod a+x post-receive-email # cd /path/to/your/repository.git # ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive # # This hook script assumes it is enabled on the central repository of a # project, with all users pushing only to it and not between each other. It # will still work if you don't operate in that style, but it would become # possible for the email to be from someone other than the person doing the # push. # # To help with debugging and use on pre-v1.5.1 git servers, this script will # also obey the interface of hooks/update, taking its arguments on the # command line. Unfortunately, hooks/update is called once for each ref. # To avoid firing one email per ref, this script just prints its output to # the screen when used in this mode. The output can then be redirected if # wanted. # # Config # ------ # hooks.mailinglist # This is the list that all pushes will go to; leave it blank to not send # emails for every ref update. # hooks.announcelist # This is the list that all pushes of annotated tags will go to. Leave it # blank to default to the mailinglist field. The announce emails lists # the short log summary of the changes since the last annotated tag. # hooks.envelopesender # If set then the -f option is passed to sendmail to allow the envelope # sender address to be set # hooks.emailprefix # All emails have their subjects prefixed with this prefix, or "[SCM]" # if emailprefix is unset, to aid filtering # hooks.showrev # The shell command used to format each revision in the email, with # "%s" replaced with the commit id. Defaults to "git rev-list -1 # --pretty %s", displaying the commit id, author, date and log # message. To list full patches separated by a blank line, you # could set this to "git show -C %s; echo". # To list a gitweb/cgit URL *and* a full patch for each change set, use this: # "t=%s; printf 'http://.../?id=%%s' \$t; echo;echo; git show -C \$t; echo" # Be careful if "..." contains things that will be expanded by shell "eval" # or printf. # hooks.emailmaxlines # The maximum number of lines that should be included in the generated # email body. If not specified, there is no limit. # Lines beyond the limit are suppressed and counted, and a final # line is added indicating the number of suppressed lines. # hooks.diffopts # Alternate options for the git diff-tree invocation that shows changes. # Default is "--stat --summary --find-copies-harder". Add -p to those # options to include a unified diff of changes in addition to the usual # summary output. # # Notes # ----- # All emails include the headers "X-Git-Refname", "X-Git-Oldrev", # "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and # give information for debugging. # # ---------------------------- Functions # # Function to prepare for email generation. This decides what type # of update this is and whether an email should even be generated. # prep_for_email() { # --- Arguments oldrev=$(git rev-parse $1) newrev=$(git rev-parse $2) refname="$3" maxlines=$4 # --- Interpret # 0000->1234 (create) # 1234->2345 (update) # 2345->0000 (delete) if expr "$oldrev" : '0*$' >/dev/null then change_type="create" else if expr "$newrev" : '0*$' >/dev/null then change_type="delete" else change_type="update" fi fi # --- Get the revision types newrev_type=$(git cat-file -t $newrev 2> /dev/null) oldrev_type=$(git cat-file -t "$oldrev" 2> /dev/null) case "$change_type" in create|update) rev="$newrev" rev_type="$newrev_type" ;; delete) rev="$oldrev" rev_type="$oldrev_type" ;; esac # The revision type tells us what type the commit is, combined with # the location of the ref we can decide between # - working branch # - tracking branch # - unannoted tag # - annotated tag case "$refname","$rev_type" in refs/tags/*,commit) # un-annotated tag refname_type="tag" short_refname=${refname##refs/tags/} ;; refs/tags/*,tag) # annotated tag refname_type="annotated tag" short_refname=${refname##refs/tags/} # change recipients if [ -n "$announcerecipients" ]; then recipients="$announcerecipients" fi ;; refs/heads/*,commit) # branch refname_type="branch" short_refname=${refname##refs/heads/} ;; refs/remotes/*,commit) # tracking branch refname_type="tracking branch" short_refname=${refname##refs/remotes/} echo >&2 "*** Push-update of tracking branch, $refname" echo >&2 "*** - no email generated." return 1 ;; *) # Anything else (is there anything else?) echo >&2 "*** Unknown type of update to $refname ($rev_type)" echo >&2 "*** - no email generated" return 1 ;; esac # Check if we've got anyone to send to if [ -z "$recipients" ]; then case "$refname_type" in "annotated tag") config_name="hooks.announcelist" ;; *) config_name="hooks.mailinglist" ;; esac echo >&2 "*** $config_name is not set so no email will be sent" echo >&2 "*** for $refname update $oldrev->$newrev" return 1 fi return 0 } # # Top level email generation function. This calls the appropriate # body-generation routine after outputting the common header. # # Note this function doesn't actually generate any email output, that is # taken care of by the functions it calls: # - generate_email_header # - generate_create_XXXX_email # - generate_update_XXXX_email # - generate_delete_XXXX_email # - generate_email_footer # # Note also that this function cannot 'exit' from the script; when this # function is running (in hook script mode), the send_mail() function # is already executing in another process, connected via a pipe, and # if this function exits without, whatever has been generated to that # point will be sent as an email... even if nothing has been generated. # generate_email() { # Email parameters # The email subject will contain the best description of the ref # that we can build from the parameters describe=$(git describe $rev 2>/dev/null) if [ -z "$describe" ]; then describe=$rev fi generate_email_header # Call the correct body generation function fn_name=general case "$refname_type" in "tracking branch"|branch) fn_name=branch ;; "annotated tag") fn_name=atag ;; esac if [ -z "$maxlines" ]; then generate_${change_type}_${fn_name}_email else generate_${change_type}_${fn_name}_email | limit_lines $maxlines fi generate_email_footer } generate_email_header() { # --- Email (all stdout will be the email) # Generate header cat <<-EOF To: $recipients Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe X-Git-Refname: $refname X-Git-Reftype: $refname_type X-Git-Oldrev: $oldrev X-Git-Newrev: $newrev This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "$projectdesc". The $refname_type, $short_refname has been ${change_type}d EOF } generate_email_footer() { SPACE=" " cat <<-EOF hooks/post-receive --${SPACE} $projectdesc EOF } # --------------- Branches # # Called for the creation of a branch # generate_create_branch_email() { # This is a new branch and so oldrev is not valid echo " at $newrev ($newrev_type)" echo "" echo $LOGBEGIN show_new_revisions echo $LOGEND } # # Called for the change of a pre-existing branch # generate_update_branch_email() { # Consider this: # 1 --- 2 --- O --- X --- 3 --- 4 --- N # # O is $oldrev for $refname # N is $newrev for $refname # X is a revision pointed to by some other ref, for which we may # assume that an email has already been generated. # In this case we want to issue an email containing only revisions # 3, 4, and N. Given (almost) by # # git rev-list N ^O --not --all # # The reason for the "almost", is that the "--not --all" will take # precedence over the "N", and effectively will translate to # # git rev-list N ^O ^X ^N # # So, we need to build up the list more carefully. git rev-parse # will generate a list of revs that may be fed into git rev-list. # We can get it to make the "--not --all" part and then filter out # the "^N" with: # # git rev-parse --not --all | grep -v N # # Then, using the --stdin switch to git rev-list we have effectively # manufactured # # git rev-list N ^O ^X # # This leaves a problem when someone else updates the repository # while this script is running. Their new value of the ref we're # working on would be included in the "--not --all" output; and as # our $newrev would be an ancestor of that commit, it would exclude # all of our commits. What we really want is to exclude the current # value of $refname from the --not list, rather than N itself. So: # # git rev-parse --not --all | grep -v $(git rev-parse $refname) # # Get's us to something pretty safe (apart from the small time # between refname being read, and git rev-parse running - for that, # I give up) # # # Next problem, consider this: # * --- B --- * --- O ($oldrev) # \ # * --- X --- * --- N ($newrev) # # That is to say, there is no guarantee that oldrev is a strict # subset of newrev (it would have required a --force, but that's # allowed). So, we can't simply say rev-list $oldrev..$newrev. # Instead we find the common base of the two revs and list from # there. # # As above, we need to take into account the presence of X; if # another branch is already in the repository and points at some of # the revisions that we are about to output - we don't want them. # The solution is as before: git rev-parse output filtered. # # Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N # # Tags pushed into the repository generate nice shortlog emails that # summarise the commits between them and the previous tag. However, # those emails don't include the full commit messages that we output # for a branch update. Therefore we still want to output revisions # that have been output on a tag email. # # Luckily, git rev-parse includes just the tool. Instead of using # "--all" we use "--branches"; this has the added benefit that # "remotes/" will be ignored as well. # List all of the revisions that were removed by this update, in a # fast-forward update, this list will be empty, because rev-list O # ^N is empty. For a non-fast-forward, O ^N is the list of removed # revisions fast_forward="" rev="" for rev in $(git rev-list $newrev..$oldrev) do revtype=$(git cat-file -t "$rev") echo " discards $rev ($revtype)" done if [ -z "$rev" ]; then fast_forward=1 fi # List all the revisions from baserev to newrev in a kind of # "table-of-contents"; note this list can include revisions that # have already had notification emails and is present to show the # full detail of the change from rolling back the old revision to # the base revision and then forward to the new revision for rev in $(git rev-list $oldrev..$newrev) do revtype=$(git cat-file -t "$rev") echo " via $rev ($revtype)" done if [ "$fast_forward" ]; then echo " from $oldrev ($oldrev_type)" else # 1. Existing revisions were removed. In this case newrev # is a subset of oldrev - this is the reverse of a # fast-forward, a rewind # 2. New revisions were added on top of an old revision, # this is a rewind and addition. # (1) certainly happened, (2) possibly. When (2) hasn't # happened, we set a flag to indicate that no log printout # is required. echo "" # Find the common ancestor of the old and new revisions and # compare it with newrev baserev=$(git merge-base $oldrev $newrev) rewind_only="" if [ "$baserev" = "$newrev" ]; then echo "This update discarded existing revisions and left the branch pointing at" echo "a previous point in the repository history." echo "" echo " * -- * -- N ($newrev)" echo " \\" echo " O -- O -- O ($oldrev)" echo "" echo "The removed revisions are not necessarilly gone - if another reference" echo "still refers to them they will stay in the repository." rewind_only=1 else echo "This update added new revisions after undoing existing revisions. That is" echo "to say, the old revision is not a strict subset of the new revision. This" echo "situation occurs when you --force push a change and generate a repository" echo "containing something like this:" echo "" echo " * -- * -- B -- O -- O -- O ($oldrev)" echo " \\" echo " N -- N -- N ($newrev)" echo "" echo "When this happens we assume that you've already had alert emails for all" echo "of the O revisions, and so we here report only the revisions in the N" echo "branch from the common base, B." fi fi echo "" if [ -z "$rewind_only" ]; then echo "Those revisions listed above that are new to this repository have" echo "not appeared on any other notification email; so we list those" echo "revisions in full, below." echo "" echo $LOGBEGIN show_new_revisions # XXX: Need a way of detecting whether git rev-list actually # outputted anything, so that we can issue a "no new # revisions added by this update" message echo $LOGEND else echo "No new revisions were added by this update." fi # The diffstat is shown from the old revision to the new revision. # This is to show the truth of what happened in this change. # There's no point showing the stat from the base to the new # revision because the base is effectively a random revision at this # point - the user will be interested in what this revision changed # - including the undoing of previous revisions in the case of # non-fast-forward updates. echo "" echo "Summary of changes:" git diff-tree $diffopts $oldrev..$newrev } # # Called for the deletion of a branch # generate_delete_branch_email() { echo " was $oldrev" echo "" echo $LOGEND git show -s --pretty=oneline $oldrev echo $LOGEND } # --------------- Annotated tags # # Called for the creation of an annotated tag # generate_create_atag_email() { echo " at $newrev ($newrev_type)" generate_atag_email } # # Called for the update of an annotated tag (this is probably a rare event # and may not even be allowed) # generate_update_atag_email() { echo " to $newrev ($newrev_type)" echo " from $oldrev (which is now obsolete)" generate_atag_email } # # Called when an annotated tag is created or changed # generate_atag_email() { # Use git for-each-ref to pull out the individual fields from the # tag eval $(git for-each-ref --shell --format=' tagobject=%(*objectname) tagtype=%(*objecttype) tagger=%(taggername) tagged=%(taggerdate)' $refname ) echo " tagging $tagobject ($tagtype)" case "$tagtype" in commit) # If the tagged object is a commit, then we assume this is a # release, and so we calculate which tag this tag is # replacing prevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null) if [ -n "$prevtag" ]; then echo " replaces $prevtag" fi ;; *) echo " length $(git cat-file -s $tagobject) bytes" ;; esac echo " tagged by $tagger" echo " on $tagged" echo "" echo $LOGBEGIN # Show the content of the tag message; this might contain a change # log or release notes so is worth displaying. git cat-file tag $newrev | sed -e '1,/^$/d' echo "" case "$tagtype" in commit) # Only commit tags make sense to have rev-list operations # performed on them if [ -n "$prevtag" ]; then # Show changes since the previous release git rev-list --pretty=short "$prevtag..$newrev" | git shortlog else # No previous tag, show all the changes since time # began git rev-list --pretty=short $newrev | git shortlog fi ;; *) # XXX: Is there anything useful we can do for non-commit # objects? ;; esac echo $LOGEND } # # Called for the deletion of an annotated tag # generate_delete_atag_email() { echo " was $oldrev" echo "" echo $LOGEND git show -s --pretty=oneline $oldrev echo $LOGEND } # --------------- General references # # Called when any other type of reference is created (most likely a # non-annotated tag) # generate_create_general_email() { echo " at $newrev ($newrev_type)" generate_general_email } # # Called when any other type of reference is updated (most likely a # non-annotated tag) # generate_update_general_email() { echo " to $newrev ($newrev_type)" echo " from $oldrev" generate_general_email } # # Called for creation or update of any other type of reference # generate_general_email() { # Unannotated tags are more about marking a point than releasing a # version; therefore we don't do the shortlog summary that we do for # annotated tags above - we simply show that the point has been # marked, and print the log message for the marked point for # reference purposes # # Note this section also catches any other reference type (although # there aren't any) and deals with them in the same way. echo "" if [ "$newrev_type" = "commit" ]; then echo $LOGBEGIN git show --no-color --root -s --pretty=medium $newrev echo $LOGEND else # What can we do here? The tag marks an object that is not # a commit, so there is no log for us to display. It's # probably not wise to output git cat-file as it could be a # binary blob. We'll just say how big it is echo "$newrev is a $newrev_type, and is $(git cat-file -s $newrev) bytes long." fi } # # Called for the deletion of any other type of reference # generate_delete_general_email() { echo " was $oldrev" echo "" echo $LOGEND git show -s --pretty=oneline $oldrev echo $LOGEND } # --------------- Miscellaneous utilities # # Show new revisions as the user would like to see them in the email. # show_new_revisions() { # This shows all log entries that are not already covered by # another ref - i.e. commits that are now accessible from this # ref that were previously not accessible # (see generate_update_branch_email for the explanation of this # command) # Revision range passed to rev-list differs for new vs. updated # branches. if [ "$change_type" = create ] then # Show all revisions exclusive to this (new) branch. revspec=$newrev else # Branch update; show revisions not part of $oldrev. revspec=$oldrev..$newrev fi other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ | grep -F -v $refname) git rev-parse --not $other_branches | if [ -z "$custom_showrev" ] then git rev-list --pretty --stdin $revspec else git rev-list --stdin $revspec | while read onerev do eval $(printf "$custom_showrev" $onerev) done fi } limit_lines() { lines=0 skipped=0 while IFS="" read -r line; do lines=$((lines + 1)) if [ $lines -gt $1 ]; then skipped=$((skipped + 1)) else printf "%s\n" "$line" fi done if [ $skipped -ne 0 ]; then echo "... $skipped lines suppressed ..." fi } send_mail() { if [ -n "$envelopesender" ]; then /usr/sbin/sendmail -t -f "$envelopesender" else /usr/sbin/sendmail -t fi } # ---------------------------- main() # --- Constants LOGBEGIN="- Log -----------------------------------------------------------------" LOGEND="-----------------------------------------------------------------------" # --- Config # Set GIT_DIR either from the working directory, or from the environment # variable. GIT_DIR=$(git rev-parse --git-dir 2>/dev/null) if [ -z "$GIT_DIR" ]; then echo >&2 "fatal: post-receive: GIT_DIR not set" exit 1 fi projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null) # Check if the description is unchanged from it's default, and shorten it to # a more manageable length if it is if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null then projectdesc="UNNAMED PROJECT" fi recipients=$(git config hooks.mailinglist) announcerecipients=$(git config hooks.announcelist) envelopesender=$(git config hooks.envelopesender) emailprefix=$(git config hooks.emailprefix || echo '[SCM] ') custom_showrev=$(git config hooks.showrev) maxlines=$(git config hooks.emailmaxlines) diffopts=$(git config hooks.diffopts) : ${diffopts:="--stat --summary --find-copies-harder"} # --- Main loop # Allow dual mode: run from the command line just like the update hook, or # if no arguments are given then run as a hook script if [ -n "$1" -a -n "$2" -a -n "$3" ]; then # Output to the terminal in command line mode - if someone wanted to # resend an email; they could redirect the output to sendmail # themselves prep_for_email $2 $3 $1 && PAGER= generate_email else while read oldrev newrev refname do prep_for_email $oldrev $newrev $refname || continue generate_email $maxlines | send_mail done fi From laforge at gnumonks.org Sat Nov 12 11:00:10 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 12 Nov 2011 12:00:10 +0100 Subject: commitlog ML improvements In-Reply-To: <20111112094111.GB19922@de.xx.vu> References: <20111112094111.GB19922@de.xx.vu> Message-ID: <20111112110010.GT4627@prithivi.gnumonks.org> On Sat, Nov 12, 2011 at 10:41:11AM +0100, Alexander Huemer wrote: > In any case, an added cgit link does not harm and also provides an easy > way to read the patches. I've now chosen that option, you can see the result at http://lists.osmocom.org/pipermail/osmocom-commitlog/2011-November/001755.html (I've already fixed the subject from projectdesc to projectname again..) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.huemer at xx.vu Sat Nov 12 22:32:19 2011 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sat, 12 Nov 2011 23:32:19 +0100 Subject: commitlog ML improvements In-Reply-To: <20111112110010.GT4627@prithivi.gnumonks.org> References: <20111112094111.GB19922@de.xx.vu> <20111112110010.GT4627@prithivi.gnumonks.org> Message-ID: <20111112223218.GC19922@de.xx.vu> On Sat, Nov 12, 2011 at 12:00:10PM +0100, Harald Welte wrote: > On Sat, Nov 12, 2011 at 10:41:11AM +0100, Alexander Huemer wrote: > > > In any case, an added cgit link does not harm and also provides an easy > > way to read the patches. > > I've now chosen that option, you can see the result at > http://lists.osmocom.org/pipermail/osmocom-commitlog/2011-November/001755.html > > (I've already fixed the subject from projectdesc to projectname again..) cool, thx. From alexander.huemer at xx.vu Mon Nov 14 10:39:36 2011 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 14 Nov 2011 11:39:36 +0100 Subject: commitlog ML improvements In-Reply-To: <20111112110010.GT4627@prithivi.gnumonks.org> References: <20111112094111.GB19922@de.xx.vu> <20111112110010.GT4627@prithivi.gnumonks.org> Message-ID: <20111114103935.GA5731@de.xx.vu> On Sat, Nov 12, 2011 at 12:00:10PM +0100, Harald Welte wrote: > (I've already fixed the subject from projectdesc to projectname again..) I am not sure whether I get you correctly. Before the twiddling, the email subject always started with xxx.git, e.g. libosmocore.git. Now the situation changed, commit emails for e.g. erlang/mgw_nat.git starts with "Erlang MediaGateWay (MGW) NAT/Masquerading" while the description cgit shows is "Erlang MGW NAT/MASQ implementation" in the cloned repository, .git/description contains "Unnamed repository; edit this file 'description' to name the repository." The non-erlang repos that caused an email since the twiddling have a subject that start with "branch xxx/yyy updated" or something, so the string that contain the description in the erlang case seems to be empty. Please look at the hook script again, there is something wrong. By the way, for me xxx.git in the subject was fine. Kind regards, -Alex From holger at freyther.de Sun Nov 13 00:30:16 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 13 Nov 2011 01:30:16 +0100 Subject: libosmocore and GNU autotest Message-ID: <4EBF0F98.5040600@freyther.de> Hi Pablo, all I have pushed GNU autotest[1] integration of libosmocore into the zecke/gnu-autotest branch and invoking make check will execute the testsuite. The output looks like this: ## ------------------------------------- ## ## libosmocore 0.4.0.10-c015 test suite. ## ## ------------------------------------- ## Regression tests. 1: bits ok 2: msgfile ok 3: sms ok 4: smscb ok 5: timer FAILED (testsuite.at:38) 6: ussd FAILED (testsuite.at:44) GNU autotest will execute an external application and then can check the exit code, compare the stdout/stderr to a file. In this case the timer test fails as the test itself is randomized and does not always provide the same output. Pablo if your time permits it would be nice if you could: - Provide a cli option to make the test have less iterations (to make make check run faster) - Provide a cli option to produce a repeatable output (e.g. by omitting the expired output). What do you think? In some ways I think that executing the timer test as part of our regression tests makes sense but maybe specially on a loaded machine the test might be flaky... holger [1] http://www.gnu.org/s/hello/manual/autoconf/Using-Autotest.html#Using-Autotest From pablo at gnumonks.org Sun Nov 13 01:25:33 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 02:25:33 +0100 Subject: libosmocore and GNU autotest In-Reply-To: <4EBF0F98.5040600@freyther.de> References: <4EBF0F98.5040600@freyther.de> Message-ID: <20111113012533.GA13551@1984> Hi Holger, On Sun, Nov 13, 2011 at 01:30:16AM +0100, Holger Hans Peter Freyther wrote: > Hi Pablo, all > > I have pushed GNU autotest[1] integration of libosmocore into the > zecke/gnu-autotest branch and invoking make check will execute the testsuite. > > The output looks like this: > ## ------------------------------------- ## > ## libosmocore 0.4.0.10-c015 test suite. ## > ## ------------------------------------- ## > > Regression tests. > > 1: bits ok > 2: msgfile ok > 3: sms ok > 4: smscb ok > 5: timer FAILED (testsuite.at:38) > 6: ussd FAILED (testsuite.at:44) > > > GNU autotest will execute an external application and then can check the exit > code, compare the stdout/stderr to a file. In this case the timer test fails > as the test itself is randomized and does not always provide the same output. Interesting, never played with this autotest stuff so far. > Pablo if your time permits it would be nice if you could: > - Provide a cli option to make the test have less iterations (to make > make check run faster) Patch attached for this. > - Provide a cli option to produce a repeatable output (e.g. by > omitting the expired output). Can we tell the tool to compare stdout but to ignore stderr? If so, we can display the repeatable output in stdout and the non-repeatable output in stderr. > What do you think? In some ways I think that executing the timer test as part > of our regression tests makes sense but maybe specially on a loaded machine > the test might be flaky... Yes, with lots of timers, the expiration may not be done in time on a loaded machine. If we can ignore the stderr output, we can put the information about timers not expiring in time to stderr. From pablo at gnumonks.org Sun Nov 13 01:02:12 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 02:02:12 +0100 Subject: [PATCH] tests: timer: add parameter to select the number of steps Message-ID: Holger likes having a parameter to set the number of steps in this test. Now you can set it via `-s' option. Signed-off-by: Pablo Neira Ayuso --- tests/timer/timer_test.c | 25 ++++++++++++++++++++++--- 1 files changed, 22 insertions(+), 3 deletions(-) diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c index bcaafdb..a01a9e5 100644 --- a/tests/timer/timer_test.c +++ b/tests/timer/timer_test.c @@ -24,6 +24,7 @@ #include #include +#include #include #include @@ -60,6 +61,7 @@ struct test_timer { #define TIMER_PRES_SECS 0 #define TIMER_PRES_USECS 10000 +static int timer_nsteps = MAIN_TIMER_NSTEPS; static unsigned int expired_timers = 0; static unsigned int total_timers = 0; static unsigned int too_late = 0; @@ -70,7 +72,7 @@ static void main_timer_fired(void *data) unsigned int add_in_this_step; int i; - if (*step == MAIN_TIMER_NSTEPS) { + if (*step == timer_nsteps) { printf("Main timer has finished, please, wait a bit for the " "final report.\n"); return; @@ -134,11 +136,28 @@ static void secondary_timer_fired(void *data) } } -int main(int argc, char** argv) +int main(int argc, char *argv[]) { + int c; + + while ((c = getopt_long(argc, argv, "s:", NULL, NULL)) != -1) { + switch(c) { + case 's': + timer_nsteps = atoi(optarg); + if (timer_nsteps <= 0) { + fprintf(stderr, "%s: steps must be > 0\n", + argv[0]); + exit(EXIT_FAILURE); + } + break; + default: + exit(EXIT_FAILURE); + } + } + printf("Running timer test for %u steps, accepting imprecision " "of %u.%.6u seconds\n", - MAIN_TIMER_NSTEPS, TIMER_PRES_SECS, TIMER_PRES_USECS); + timer_nsteps, TIMER_PRES_SECS, TIMER_PRES_USECS); osmo_timer_schedule(&main_timer, 1, 0); -- 1.7.2.5 --k1lZvvs/B4yU6o8G-- From holger at freyther.de Sun Nov 13 08:05:41 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 13 Nov 2011 09:05:41 +0100 Subject: libosmocore and GNU autotest In-Reply-To: <20111113012533.GA13551@1984> References: <4EBF0F98.5040600@freyther.de> <20111113012533.GA13551@1984> Message-ID: <4EBF7A55.2070204@freyther.de> On 11/13/2011 02:25 AM, Pablo Neira Ayuso wrote: > Interesting, never played with this autotest stuff so far. I saw it in GNU Smalltalk. Somehow the testsuite.at is too verbose and we would deserve an osmo.m4 macro but then we are in trouble in regard to installing this one. :} > Patch attached for this. thanks, picked into the branch. > Can we tell the tool to compare stdout but to ignore stderr? If so, we > can display the repeatable output in stdout and the non-repeatable output > in stderr. Good idea, I comitted a patch to do this, would be awesome if you play with sending things to stdout/stderr. > Yes, with lots of timers, the expiration may not be done in time on > a loaded machine. If we can ignore the stderr output, we can put the > information about timers not expiring in time to stderr. Not expiring at all should probably be counted as test failure? thanks for the fast response From pablo at gnumonks.org Sun Nov 13 16:54:13 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 17:54:13 +0100 Subject: libosmocore and GNU autotest In-Reply-To: <4EBF7A55.2070204@freyther.de> References: <4EBF0F98.5040600@freyther.de> <20111113012533.GA13551@1984> <4EBF7A55.2070204@freyther.de> Message-ID: <20111113165413.GC16578@1984> On Sun, Nov 13, 2011 at 09:05:41AM +0100, Holger Hans Peter Freyther wrote: > On 11/13/2011 02:25 AM, Pablo Neira Ayuso wrote: > > > Interesting, never played with this autotest stuff so far. > > I saw it in GNU Smalltalk. Somehow the testsuite.at is too verbose and we > would deserve an osmo.m4 macro but then we are in trouble in regard to > installing this one. :} Not sure I understood the problem. We can store the custom xyz.m4 file under the m4/ directory and distribute it with the tarball, if needed. > > Patch attached for this. > > thanks, picked into the branch. > > > Can we tell the tool to compare stdout but to ignore stderr? If so, we > > can display the repeatable output in stdout and the non-repeatable output > > in stderr. > > Good idea, I comitted a patch to do this, would be awesome if you play with > sending things to stdout/stderr. Thanks for applying the patch. I made one patch for this. > > Yes, with lots of timers, the expiration may not be done in time on > > a loaded machine. If we can ignore the stderr output, we can put the > > information about timers not expiring in time to stderr. > > Not expiring at all should probably be counted as test failure? You mean not expiring in time? I think so. If we use very few timers for the test (like it is the case for 5 steps), it seems to me very unlikely that we'll fail to make it in time. Well, if you launch some very CPU intensive tasks I might be wrong, but I don't think this will be the case for people running make check. After all, if we start getting reports of people that run the test that bogusly fail, we can relax the checkings. Mreover it's a good idea to set some maximum wait time for the test to finish via signals. Check the second patch attached to this email, apply it if you like it. Btw, please, don't remove me from the Cc, I check the list often but my mail client has a filter to put emails directed to me (To or Cc) in one specific folder, so I can prioritize emails that require some reply from me. From pablo at gnumonks.org Sun Nov 13 16:22:33 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 17:22:33 +0100 Subject: [PATCH 1/2] tests: timer: use stderr for non-repeatable output Message-ID: This makes happy gnu-autotest for the timer test. We may still may fail if we run the test on a very heavy loaded system, but given the amount of timers that we using for the automatic test (only 32), this seems very unlikely to me. --- tests/timer/timer_test.c | 17 +++++++++-------- tests/timer/timer_test.ok | 21 ++------------------- 2 files changed, 11 insertions(+), 27 deletions(-) diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c index a01a9e5..72c07a9 100644 --- a/tests/timer/timer_test.c +++ b/tests/timer/timer_test.c @@ -73,8 +73,8 @@ static void main_timer_fired(void *data) int i; if (*step == timer_nsteps) { - printf("Main timer has finished, please, wait a bit for the " - "final report.\n"); + fprintf(stderr, "Main timer has finished, please, " + "wait a bit for the final report.\n"); return; } /* add 2^step pair of timers per step. */ @@ -96,7 +96,7 @@ static void main_timer_fired(void *data) osmo_timer_schedule(&v->timer, seconds, 0); llist_add(&v->head, &timer_test_list); } - printf("added %d timers in step %u (expired=%u)\n", + fprintf(stderr, "added %d timers in step %u (expired=%u)\n", add_in_this_step, *step, expired_timers); total_timers += add_in_this_step; osmo_timer_schedule(&main_timer, TIME_BETWEEN_STEPS, 0); @@ -112,7 +112,8 @@ static void secondary_timer_fired(void *data) timersub(¤t, &v->stop, &res); if (timercmp(&res, &precision, >)) { - printf("ERROR: timer %p has expired too late!\n", v->timer); + fprintf(stderr, "ERROR: timer %p has expired too late!\n", + v->timer); too_late++; } @@ -120,7 +121,7 @@ static void secondary_timer_fired(void *data) talloc_free(data); expired_timers++; if (expired_timers == total_timers) { - printf("test over: added=%u expired=%u too_late=%u \n", + fprintf(stdout, "test over: added=%u expired=%u too_late=%u \n", total_timers, expired_timers, too_late); exit(EXIT_SUCCESS); } @@ -155,8 +156,8 @@ int main(int argc, char *argv[]) } } - printf("Running timer test for %u steps, accepting imprecision " - "of %u.%.6u seconds\n", + fprintf(stdout, "Running timer test for %u steps, accepting " + "imprecision of %u.%.6u seconds\n", timer_nsteps, TIMER_PRES_SECS, TIMER_PRES_USECS); osmo_timer_schedule(&main_timer, 1, 0); @@ -166,6 +167,6 @@ int main(int argc, char *argv[]) osmo_select_main(0); } #else - printf("Select not supported on this platform!\n"); + fprintf(stdout, "Select not supported on this platform!\n"); #endif } diff --git a/tests/timer/timer_test.ok b/tests/timer/timer_test.ok index b1792f1..b4e0e11 100644 --- a/tests/timer/timer_test.ok +++ b/tests/timer/timer_test.ok @@ -1,19 +1,2 @@ -Running timer test for 16 steps, accepting imprecision of 0.010000 seconds -added 1 timers in step 0 (expired=0) -added 2 timers in step 1 (expired=0) -added 4 timers in step 2 (expired=0) -added 8 timers in step 3 (expired=0) -added 16 timers in step 4 (expired=1) -added 32 timers in step 5 (expired=4) -added 64 timers in step 6 (expired=33) -added 128 timers in step 7 (expired=87) -added 256 timers in step 8 (expired=183) -added 512 timers in step 9 (expired=466) -added 1024 timers in step 10 (expired=970) -added 2048 timers in step 11 (expired=1968) -added 4096 timers in step 12 (expired=3994) -added 8192 timers in step 13 (expired=8035) -added 16384 timers in step 14 (expired=16324) -added 32768 timers in step 15 (expired=32641) -Main timer has finished, please, wait a bit for the final report. -test over: added=65535 expired=65535 too_late=0 +Running timer test for 5 steps, accepting imprecision of 0.010000 seconds +test over: added=31 expired=31 too_late=0 -- 1.7.2.5 --fdj2RfSjLxBAspz7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-tests-timer-set-maximum-wait-time-to-obtain-test-res.patch" From pablo at gnumonks.org Sun Nov 13 16:40:09 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 13 Nov 2011 17:40:09 +0100 Subject: [PATCH 2/2] tests: timer: set maximum wait time to obtain test results Message-ID: If the timer test takes more than 2 * (number of steps + 10), we abort the test. This calculation is based on the maximum timeout randomly set (10 seconds) plus the number of steps (some existing timers may be reset in each step). We double this to have some extra grace time to finish. --- tests/timer/timer_test.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c index 72c07a9..3775151 100644 --- a/tests/timer/timer_test.c +++ b/tests/timer/timer_test.c @@ -24,6 +24,7 @@ #include #include +#include #include #include @@ -137,10 +138,22 @@ static void secondary_timer_fired(void *data) } } +static void alarm_handler(int signum) +{ + fprintf(stderr, "ERROR: We took too long to run the timer test, " + "something seems broken, aborting.\n"); + exit(EXIT_FAILURE); +} + int main(int argc, char *argv[]) { int c; + if (signal(SIGALRM, alarm_handler) == SIG_ERR) { + perror("cannot register signal handler"); + exit(EXIT_FAILURE); + } + while ((c = getopt_long(argc, argv, "s:", NULL, NULL)) != -1) { switch(c) { case 's': @@ -162,6 +175,12 @@ int main(int argc, char *argv[]) osmo_timer_schedule(&main_timer, 1, 0); + /* if the test takes too long, we may consider that the timer scheduler + * has hung. We set some maximum wait time which is the double of the + * maximum timeout randomly set (10 seconds, worst case) plus the + * number of steps (since some of them are reset each step). */ + alarm(2 * (10 + timer_nsteps)); + #ifdef HAVE_SYS_SELECT_H while (1) { osmo_select_main(0); -- 1.7.2.5 --fdj2RfSjLxBAspz7-- From holger at freyther.de Sun Nov 13 17:45:32 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 13 Nov 2011 18:45:32 +0100 Subject: libosmocore and GNU autotest In-Reply-To: <20111113165413.GC16578@1984> References: <4EBF0F98.5040600@freyther.de> <20111113012533.GA13551@1984> <4EBF7A55.2070204@freyther.de> <20111113165413.GC16578@1984> Message-ID: <4EC0023C.6080403@freyther.de> On 11/13/2011 05:54 PM, Pablo Neira Ayuso wrote: > On Sun, Nov 13, 2011 at 09:05:41AM +0100, Holger Hans Peter Freyther wrote: > > Not sure I understood the problem. We can store the custom xyz.m4 file > under the m4/ directory and distribute it with the tarball, if needed. a) we copy the same file into every repository... b) we install it by libosmocore... but I tend to install my software with --prefix=$HOME/install/openbsc... so the normal autoreconf --install --force would not find osmo.m4 (without specifying more paths) will try the patch in a second. holger From daniel.brune.so at web.de Sun Nov 13 15:57:22 2011 From: daniel.brune.so at web.de (Daniel Brune privat) Date: Sun, 13 Nov 2011 16:57:22 +0100 Subject: AW: OpenBSC Digest, Vol 35, Issue 3 In-Reply-To: References: Message-ID: <002d01cca21d$0c674eb0$2535ec10$@web.de> Hi Harald, I can also provide 3 fully functioning GSM1800 nanoBTS units, I just do not have the extension cables for multiTRX use, but I have adapters for external antennas if required. I would be able to assist for configuring, maintenance and testing the whole setup starting at 25th in Berlin as well. Best, Daniel From laforge at gnumonks.org Mon Nov 14 07:45:27 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 14 Nov 2011 08:45:27 +0100 Subject: nanoBTS / 28C3 network In-Reply-To: <002d01cca21d$0c674eb0$2535ec10$@web.de> References: <002d01cca21d$0c674eb0$2535ec10$@web.de> Message-ID: <20111114074527.GH13265@prithivi.gnumonks.org> Hi Daniel, On Sun, Nov 13, 2011 at 04:57:22PM +0100, Daniel Brune privat wrote: > I can also provide 3 fully functioning GSM1800 nanoBTS units, I just do not > have the extension cables for multiTRX use, but I have adapters for external > antennas if required. thanks for your offer. I have sufficient (3) stacking cables which we already used in the two previous years. We will not use external antennas. I think the setup can remain unchanged from the previous years: Two stacked nanoBTS on each of the 3 floors, resulting in logically 1BTS (2 TRX) per floor. > I would be able to assist for configuring, maintenance and testing the > whole setup starting at 25th in Berlin as well. Thanks. I presume you have some experience with both the nanoBTS and OpenBSC? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From david at rangenetworks.com Mon Nov 14 01:53:58 2011 From: david at rangenetworks.com (David Burgess) Date: Sun, 13 Nov 2011 17:53:58 -0800 Subject: slightly OT - new list for UMTS discussions Message-ID: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> All - I realize this is slightly off topic, but I have just set up a mailing list for discussion of the UMTS specifications. This list is not about building a specific implementation of UMTS (although it might lead to that) but it is instead a forum for discussion of the interpretation of the specifications. It is my impression so far that the 3GPP documents are constructed so as to meet some minimum legal requirement for the specification of the technology while still avoiding the conveyance of critical information actually required to implement the system. The likely purpose of this approach is to deter the implementation of 3G technology by anyone outside of the set of companies that staffed the specification committee. The eventual product of this list could be an alternative, wikipedia-style spec that conveys all of the information needed to actually build some minimum-but-fuctional 3G system. Anyone who is interested breaking down the door to this club, please subscribe here: https://lists.sourceforge.net/lists/listinfo/openbts-umts-discuss Thanks. -- David David A. Burgess Range Networks, Inc. 560 Brannan St. San Francisco, CA 94107 USA cell +1 707 208 2622 From akibsayyed at gmail.com Mon Nov 14 02:29:07 2011 From: akibsayyed at gmail.com (Akib Sayyed) Date: Mon, 14 Nov 2011 07:59:07 +0530 Subject: [Openbts-discuss] slightly OT - new list for UMTS discussions In-Reply-To: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> References: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> Message-ID: hurrrey most awaited list On Mon, Nov 14, 2011 at 7:23 AM, David Burgess wrote: > All - > > I realize this is slightly off topic, but I have just set up a mailing > list for discussion of the UMTS specifications. This list is not about > building a specific implementation of UMTS (although it might lead to that) > but it is instead a forum for discussion of the interpretation of the > specifications. It is my impression so far that the 3GPP documents are > constructed so as to meet some minimum legal requirement for the > specification of the technology while still avoiding the conveyance of > critical information actually required to implement the system. The likely > purpose of this approach is to deter the implementation of 3G technology by > anyone outside of the set of companies that staffed the specification > committee. The eventual product of this list could be an alternative, > wikipedia-style spec that conveys all of the information needed to actually > build some minimum-but-fuctional 3G system. Anyone who is interested > breaking down the door to this club, please subscribe here: > > https://lists.sourceforge.net/lists/listinfo/openbts-umts-discuss > > Thanks. > > -- David > > David A. Burgess > Range Networks, Inc. > 560 Brannan St. > San Francisco, CA 94107 > USA > cell +1 707 208 2622 > > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Openbts-discuss mailing list > Openbts-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Mon Nov 14 06:59:33 2011 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 14 Nov 2011 10:59:33 +0400 Subject: [Openbts-discuss] slightly OT - new list for UMTS discussions In-Reply-To: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> References: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> Message-ID: Hi David, Looks like a good idea. I just want to say that it would be better to name the list just "umts-discuss" if you aim at general discussion. This should decrease confusion of newcomers. On Mon, Nov 14, 2011 at 05:53, David Burgess wrote: > All - > > I realize this is slightly off topic, but I have just set up a mailing list for discussion of the UMTS specifications. ?This list is not about building a specific implementation of UMTS (although it might lead to that) but it is instead a forum for discussion of the interpretation of the specifications. ?It is my impression so far that the 3GPP documents are constructed so as to meet some minimum legal requirement for the specification of the technology while still avoiding the conveyance of critical information actually required to implement the system. ?The likely purpose of this approach is to deter the implementation of 3G technology by anyone outside of the set of companies that staffed the specification committee. ?The eventual product of this list could be an alternative, wikipedia-style spec that conveys all of the information needed to actually build some minimum-but-fuctional 3G system. ?Anyone who is interested breaking down the door to this club, please subscribe here: > > https://lists.sourceforge.net/lists/listinfo/openbts-umts-discuss > > Thanks. > > -- David > > David A. Burgess > Range Networks, Inc. > 560 Brannan St. > San Francisco, CA 94107 > USA > cell +1 707 208 2622 > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Openbts-discuss mailing list > Openbts-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Regards, Alexander Chemeris. From laforge at gnumonks.org Mon Nov 14 07:47:11 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 14 Nov 2011 08:47:11 +0100 Subject: [Openbts-discuss] slightly OT - new list for UMTS discussions In-Reply-To: References: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> Message-ID: <20111114074711.GI13265@prithivi.gnumonks.org> On Mon, Nov 14, 2011 at 10:59:33AM +0400, Alexander Chemeris wrote: > I just want to say that it would be better to name the list just > "umts-discuss" if you aim at general discussion. This should decrease > confusion of newcomers. Alexander, sourceforge.net has a policy/rule/requirement that all lists start with the sf.net project name. This probably explains the name... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Nov 14 07:51:02 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 14 Nov 2011 08:51:02 +0100 Subject: slightly OT - new list for UMTS discussions In-Reply-To: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> References: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> Message-ID: <20111114075102.GJ13265@prithivi.gnumonks.org> Hi David, On Sun, Nov 13, 2011 at 05:53:58PM -0800, David Burgess wrote: > I realize this is slightly off topic, but I have just set up a mailing > list for discussion of the UMTS specifications. This list is not > about building a specific implementation of UMTS (although it might > lead to that) but it is instead a forum for discussion of the > interpretation of the specifications. I'm very happy about you taking initiative on this, and I've already subscribed on the list. My detailed knowledge about UMTS is mostly on the higher layers though (from RANAP up), but I'm happy to contribute whatever I can. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jwjohn0 at gmail.com Mon Nov 14 09:20:55 2011 From: jwjohn0 at gmail.com (John Wu) Date: Mon, 14 Nov 2011 17:20:55 +0800 Subject: [Openbts-discuss] slightly OT - new list for UMTS discussions In-Reply-To: <20111114075102.GJ13265@prithivi.gnumonks.org> References: <7BC2A3CC-9AAE-4C94-8935-277CA4ADDB23@rangenetworks.com> <20111114075102.GJ13265@prithivi.gnumonks.org> Message-ID: Hi Harald, That is great you participate to the new list. Your knowledge will be very helpful to this list. On Mon, Nov 14, 2011 at 3:51 PM, Harald Welte wrote: > Hi David, > > On Sun, Nov 13, 2011 at 05:53:58PM -0800, David Burgess wrote: > > > I realize this is slightly off topic, but I have just set up a mailing > > list for discussion of the UMTS specifications. This list is not > > about building a specific implementation of UMTS (although it might > > lead to that) but it is instead a forum for discussion of the > > interpretation of the specifications. > > I'm very happy about you taking initiative on this, and I've already > subscribed on the list. My detailed knowledge about UMTS is mostly on > the higher layers though (from RANAP up), but I'm happy to contribute > whatever I can. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Openbts-discuss mailing list > Openbts-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Nov 14 13:49:18 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 14 Nov 2011 14:49:18 +0100 Subject: Jenkins CI with GNU autotests is on Message-ID: <4EC11C5E.2070603@freyther.de> Hi all, as can be seen here[1] I have merged the GNU autotest setup to libosmocore and the tests are now being executed during the normal build. I encourage everyone to write new tests for bugfixes in libosmocore but in other projects as well. How to write a test: - Create a new test executable or add a new function to one of the existing tests. Make repeatable output go to stdout, errors and things that can change to stderr. - Capture the stdout into the app_name.ok, add this file to the EXTRA_DIST of the Makefile.am - Append your test to the tests/testsuite.at file (copy and pasting one of the previous test cases) - test locally with make check - If you access local files during the test, add them to the EXTRA_DIST as well - Use make distcheck to verify everything is okay. regard holger [1] http://jenkins.osmocom.org/jenkins/job/libosmocore/label=linux_i386_debian_squeeze/16/console (no permalink) From xkrkos04 at stud.feec.vutbr.cz Mon Nov 14 17:02:58 2011 From: xkrkos04 at stud.feec.vutbr.cz (Krkos Radko) Date: Mon, 14 Nov 2011 18:02:58 +0100 Subject: GPRS with OpenBSC Message-ID: <20111114180258.8977778iyizju66a@email.feec.vutbr.cz> Hello, I am trying to set up an OpenBSC based GSM network. The GSM part was easy and relatively quick to do, but I have a problem with GPRS. I have read the documentation for OpenSGSN (http://openbsc.osmocom.org/trac/wiki/) and OpenGGSN (man page). After a couple of days searching for more information and trying whatever came to my mind, GPRS still does not work. BTS is ip.access nanoBTS, using IP address 192.168.2.3 (was set up like that, I got it second hand). It is connected to eth1 (192.168.2.1). The PC is running osmo-nitb, osmo-sgsn and ggsn (started in reverse order). Interface eth0 is internet connection (behind NAT). ********** bash-4.1# ifconfig eth0 Link encap:Ethernet HWaddr 00:22:15:99:86:2E inet addr:192.168.110.34 Bcast:192.168.110.255 Mask:255.255.255.0 inet6 addr: fe80::222:15ff:fe99:862e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22233 errors:0 dropped:1314 overruns:0 frame:0 TX packets:4200 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4119511 (3.9 Mb) TX bytes:514598 (502.5 Kb) Interrupt:20 Memory:f9fc0000-f9fe0000 eth1 Link encap:Ethernet HWaddr 00:E0:7D:D6:7D:2D inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:7dff:fed6:7d2d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7311 errors:0 dropped:0 overruns:0 frame:0 TX packets:7211 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:630759 (615.9 Kb) TX bytes:445274 (434.8 Kb) Interrupt:17 Base address:0xe800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:480 (480.0 b) TX bytes:480 (480.0 b) lo:1 Link encap:Local Loopback inet addr:192.168.3.2 Mask:255.255.255.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 lo:2 Link encap:Local Loopback inet addr:192.168.3.3 Mask:255.255.255.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.254.1 P-t-P:192.168.254.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ********** bash-4.1# cat /proc/sys/net/ipv4/ip_forward 1 ********** I have also added a rule to iptables: iptables -A POSTROUTING -s 192.168.254.0/24 -t nat -o eth0 -j MASQUERADE ********** Here are my configuration files: ********** GPRS section of nitb.conf: ********** gprs mode gprs gprs routing area 0 gprs cell bvci 2 gprs nsei 101 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 192.168.2.1 ********** sgsn.conf: ********** ! ! Osmocom SGSN configuration ! line vty no login ! sgsn gtp local-ip 192.168.3.2 ggsn 0 remote-ip 192.168.3.3 ggsn 0 gtp-version 1 ! ns timer tns-block 3 timer tns-block-retries 3 timer tns-reset 3 timer tns-reset-retries 3 timer tns-test 30 timer tns-alive 3 timer tns-alive-retries 10 encapsulation udp local-ip 192.168.2.1 encapsulation udp local-port 23000 encapsulation framerelay-gre enabled 0 ! bssgp ! ********** ggsn.conf: ********** pidfile /var/run/ggsn.pid statedir /var/lib/ggsn/ listen 192.168.3.3 net 192.168.254.0/24 dynip 192.168.254.0/24 timelimit 0 I am using Wireshark with patches from openbsc git applied. GSM calls and SMS work fine. BTS is able to connect to SGSN, as can be seen from the output: ********** rado at openbsc:~$ osmo-sgsn -c sgsn.conf <0011> gprs_ns.c:151 NSVCI=65534 Creating NS-VC <0011> gprs_ns.c:151 NSVCI=65535 Creating NS-VC <0011> gprs_ns.c:738 Creating NS-VC for BSS at 192.168.2.3:23000 <0011> gprs_ns.c:620 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention) <0011> gprs_ns.c:488 NSEI=101 Tx NS RESET ACK (NSVCI=101) <0011> gprs_ns.c:797 NSEI=101 Rx NS UNBLOCK <0012> gprs_bssgp.c:246 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified <0012> gprs_bssgp.c:246 BSSGP BVCI=2 Rx RESET cause=O&M intervention <0012> gprs_bssgp.c:269 Cell 230-10-1209-0 CI 2984 on BVCI 2 <0012> gprs_bssgp.c:322 BSSGP BVCI=2 Rx BVC-UNBLOCK <0012> gprs_bssgp.c:462 BSSGP BVCI=2 Rx Flow Control BVC ********** When trying to use GPRS from mobile phone: ********** <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7ed21cb5 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x17cd30CMD=UI DATA <0013> gprs_llc.c:741 LLC RX: unknown TLLI 0x7ed21cb5, creating LLME on the fly <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7ed21cb5 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x17cd32CMD=UI DATA <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7ed21cb5 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x17cd4cCMD=UI DATA and so on until phone timeouts. The problem is in my opinion between SGSN and GGSN, as no data is transferred through the tunnel (or the lo interface). But I checked the settings multiple times and tried other configurations (alias for eth1). Openbsc, openggsn, libosmocore, libosmo-abis are all compiled from git repositories. I do not understand what I am doing wrong and I am out of options. So I am asking for help. Thank you for your time. Rado Krkos From krkos at phd.feec.vutbr.cz Mon Nov 14 17:07:06 2011 From: krkos at phd.feec.vutbr.cz (=?iso-8859-2?Q?Radko_Krko=B9?=) Date: Mon, 14 Nov 2011 18:07:06 +0100 Subject: GPRS with OpenBSC problem Message-ID: <002e01cca2ef$d65f6040$831e20c0$@phd.feec.vutbr.cz> Hello, I am trying to set up an OpenBSC based GSM network. The GSM part was easy and relatively quick to do, but I have a problem with GPRS. I have read the documentation for OpenSGSN (http://openbsc.osmocom.org/trac/wiki/) and OpenGGSN (man page). After a couple of days searching for more information and trying whatever came to my mind, GPRS still does not work. BTS is ip.access nanoBTS, using IP address 192.168.2.3 (was set up like that, I got it second hand). It is connected to eth1 (192.168.2.1). The PC is running osmo-nitb, osmo-sgsn and ggsn (started in reverse order). Interface eth0 is internet connection (behind NAT). ********** bash-4.1# ifconfig eth0 Link encap:Ethernet HWaddr 00:22:15:99:86:2E inet addr:192.168.110.34 Bcast:192.168.110.255 Mask:255.255.255.0 inet6 addr: fe80::222:15ff:fe99:862e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22233 errors:0 dropped:1314 overruns:0 frame:0 TX packets:4200 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4119511 (3.9 Mb) TX bytes:514598 (502.5 Kb) Interrupt:20 Memory:f9fc0000-f9fe0000 eth1 Link encap:Ethernet HWaddr 00:E0:7D:D6:7D:2D inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:7dff:fed6:7d2d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7311 errors:0 dropped:0 overruns:0 frame:0 TX packets:7211 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:630759 (615.9 Kb) TX bytes:445274 (434.8 Kb) Interrupt:17 Base address:0xe800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:480 (480.0 b) TX bytes:480 (480.0 b) lo:1 Link encap:Local Loopback inet addr:192.168.3.2 Mask:255.255.255.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 lo:2 Link encap:Local Loopback inet addr:192.168.3.3 Mask:255.255.255.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.254.1 P-t-P:192.168.254.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ********** bash-4.1# cat /proc/sys/net/ipv4/ip_forward 1 ********** I have also added a rule to iptables: iptables -A POSTROUTING -s 192.168.254.0/24 -t nat -o eth0 -j MASQUERADE ********** Here are my configuration files: ********** GPRS section of nitb.conf: ********** gprs mode gprs gprs routing area 0 gprs cell bvci 2 gprs nsei 101 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 192.168.2.1 ********** sgsn.conf: ********** ! ! Osmocom SGSN configuration ! line vty no login ! sgsn gtp local-ip 192.168.3.2 ggsn 0 remote-ip 192.168.3.3 ggsn 0 gtp-version 1 ! ns timer tns-block 3 timer tns-block-retries 3 timer tns-reset 3 timer tns-reset-retries 3 timer tns-test 30 timer tns-alive 3 timer tns-alive-retries 10 encapsulation udp local-ip 192.168.2.1 encapsulation udp local-port 23000 encapsulation framerelay-gre enabled 0 ! bssgp ! ********** ggsn.conf: ********** pidfile /var/run/ggsn.pid statedir /var/lib/ggsn/ listen 192.168.3.3 net 192.168.254.0/24 dynip 192.168.254.0/24 timelimit 0 I am using Wireshark with patches from openbsc git applied. GSM calls and SMS work fine. BTS is able to connect to SGSN, as can be seen from the output: ********** rado at openbsc:~$ osmo-sgsn -c sgsn.conf <0011> gprs_ns.c:151 NSVCI=65534 Creating NS-VC <0011> gprs_ns.c:151 NSVCI=65535 Creating NS-VC <0011> gprs_ns.c:738 Creating NS-VC for BSS at 192.168.2.3:23000 <0011> gprs_ns.c:620 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention) <0011> gprs_ns.c:488 NSEI=101 Tx NS RESET ACK (NSVCI=101) <0011> gprs_ns.c:797 NSEI=101 Rx NS UNBLOCK <0012> gprs_bssgp.c:246 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified <0012> gprs_bssgp.c:246 BSSGP BVCI=2 Rx RESET cause=O&M intervention <0012> gprs_bssgp.c:269 Cell 230-10-1209-0 CI 2984 on BVCI 2 <0012> gprs_bssgp.c:322 BSSGP BVCI=2 Rx BVC-UNBLOCK <0012> gprs_bssgp.c:462 BSSGP BVCI=2 Rx Flow Control BVC ********** When trying to use GPRS from mobile phone: ********** <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7ed21cb5 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x17cd30CMD=UI DATA <0013> gprs_llc.c:741 LLC RX: unknown TLLI 0x7ed21cb5, creating LLME on the fly <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7ed21cb5 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x17cd32CMD=UI DATA <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7ed21cb5 Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x17cd4cCMD=UI DATA and so on until phone timeouts. The problem is in my opinion between SGSN and GGSN, as no data is transferred through the tunnel (or the lo interface). But I checked the settings multiple times and tried other configurations (alias for eth1). Openbsc, openggsn, libosmocore, libosmo-abis are all compiled from git repositories. I do not understand what I am doing wrong and I am out of options. So I am asking for help. Thank you for your time. Rado Krkos From holger at freyther.de Mon Nov 14 17:24:29 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 14 Nov 2011 18:24:29 +0100 Subject: GPRS with OpenBSC problem In-Reply-To: <002e01cca2ef$d65f6040$831e20c0$@phd.feec.vutbr.cz> References: <002e01cca2ef$d65f6040$831e20c0$@phd.feec.vutbr.cz> Message-ID: <4EC14ECD.4070704@freyther.de> On 11/14/2011 06:07 PM, Radko Krko? wrote: > pidfile /var/run/ggsn.pid > statedir /var/lib/ggsn/ > listen 192.168.3.3 > net 192.168.254.0/24 > dynip 192.168.254.0/24 > timelimit 0 do you need a dns entry? From krkos at phd.feec.vutbr.cz Mon Nov 14 17:34:28 2011 From: krkos at phd.feec.vutbr.cz (=?iso-8859-2?Q?Radko_Krko=B9?=) Date: Mon, 14 Nov 2011 18:34:28 +0100 Subject: GPRS with OpenBSC problem In-Reply-To: <4EC14ECD.4070704@freyther.de> References: <002e01cca2ef$d65f6040$831e20c0$@phd.feec.vutbr.cz> <4EC14ECD.4070704@freyther.de> Message-ID: <003401cca2f3$a976ce70$fc646b50$@phd.feec.vutbr.cz> > -----Original Message----- > From: openbsc-bounces at lists.osmocom.org [mailto:openbsc- > bounces at lists.osmocom.org] On Behalf Of Holger Hans Peter Freyther > Sent: Monday, November 14, 2011 6:24 PM > To: openbsc at lists.osmocom.org > Subject: Re: GPRS with OpenBSC problem > > On 11/14/2011 06:07 PM, Radko Krko? wrote: > > > pidfile /var/run/ggsn.pid > > statedir /var/lib/ggsn/ > > listen 192.168.3.3 > > net 192.168.254.0/24 > > dynip 192.168.254.0/24 > > timelimit 0 > > do you need a dns entry? Possibly, I have set the machine as a DNS server also and used "spcodns1 localhost", but that did not help either. From laforge at gnumonks.org Mon Nov 14 20:57:25 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 14 Nov 2011 21:57:25 +0100 Subject: GPRS with OpenBSC problem In-Reply-To: <002e01cca2ef$d65f6040$831e20c0$@phd.feec.vutbr.cz> References: <002e01cca2ef$d65f6040$831e20c0$@phd.feec.vutbr.cz> Message-ID: <20111114205725.GW4298@prithivi.gnumonks.org> Hi Radko, On Mon, Nov 14, 2011 at 06:07:06PM +0100, Radko Krko? wrote: > Hello, > I am trying to set up an OpenBSC based GSM network. The GSM part was easy > and relatively quick to do, but I have a problem with GPRS. I have read the > documentation for OpenSGSN > (http://openbsc.osmocom.org/trac/wiki/) and OpenGGSN (man page). After a > couple of days searching for more information and trying whatever came to my > mind, GPRS still does not work. Your setup looks fine in termso of the IP addresses and other configuration that you have shown. What would be interesting is to actually look at the protocol traces of the Gb(NS/BSSGP) and GTP interfaces. Based on your SGSN output, there is not even any any GMM activity shown. Before you ever get any actual GPRS data (PDP context, etc.) up, there needs to be a GMM ATTACH / GMM RA UPDATE / etc. procedure. Those should be visible in the Gb interface protocol traces, and also show up on the sgsn vty if you do logging enable logging filter all 1 logging level mm debug Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.huemer at xx.vu Sun Nov 20 20:53:15 2011 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sun, 20 Nov 2011 21:53:15 +0100 Subject: [PATCH] fix two mistakes in AM_LDFLAGS Message-ID: <1321822395-31422-1-git-send-email-alexander.huemer@xx.vu> --- openbsc/src/libgb/Makefile.am | 2 +- openbsc/src/libmsc/Makefile.am | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/openbsc/src/libgb/Makefile.am b/openbsc/src/libgb/Makefile.am index 8ec1006..c98cad7 100644 --- a/openbsc/src/libgb/Makefile.am +++ b/openbsc/src/libgb/Makefile.am @@ -1,6 +1,6 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS=-Wall -fno-strict-aliasing $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(COVERAGE_CFLAGS) -AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOCORE_GSM) $(LIBOSMOVTY_LIBS) $(COVERAGE_LDFLAGS) +AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) $(COVERAGE_LDFLAGS) noinst_LIBRARIES = libgb.a diff --git a/openbsc/src/libmsc/Makefile.am b/openbsc/src/libmsc/Makefile.am index 8d5034c..5e64453 100644 --- a/openbsc/src/libmsc/Makefile.am +++ b/openbsc/src/libmsc/Makefile.am @@ -1,6 +1,6 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(COVERAGE_CFLAGS) -AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_CFLAGS) $(COVERAGE_LDFLAGS) +AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(COVERAGE_LDFLAGS) noinst_LIBRARIES = libmsc.a -- 1.7.8.rc1 From laforge at gnumonks.org Fri Nov 25 08:44:11 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 25 Nov 2011 09:44:11 +0100 Subject: [PATCH] fix two mistakes in AM_LDFLAGS In-Reply-To: <1321822395-31422-1-git-send-email-alexander.huemer@xx.vu> References: <1321822395-31422-1-git-send-email-alexander.huemer@xx.vu> Message-ID: <20111125084411.GR1730@prithivi.gnumonks.org> Hi Alexander, On Sun, Nov 20, 2011 at 09:53:15PM +0100, Alexander Huemer wrote: > --- > openbsc/src/libgb/Makefile.am | 2 +- > openbsc/src/libmsc/Makefile.am | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Thanks, applied! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From openbsc at wehrle.it Thu Nov 24 13:40:24 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Thu, 24 Nov 2011 14:40:24 +0100 Subject: paralell multipart sms not working Message-ID: <4ECE4948.3060807@wehrle.it> Hi Our plan is to offer an subscription to get our mensa menu via sms. If just one MS get the sms everything works fine. But if two MSs are online and OpenBSC sends the sms paralell (for each TS) something goes wrong. The first two parts for both SMS will be transmitted correctly. But than we receive a malformed packet from the BTS (see No. 103 from wrong-sms.xml). After that the MS seems to be "confused" or something else is wrong, because the following parts (and part 2) will be transmitted several times. This is because the MS don't ack the sms correctly. On a previous test we get 14 sms parts instead of just 5 parts: 1. part: 1 times 2. part: 2 times 3. part: 3 times 4. part: 4 times 5. part: 4 times Attached are two gammu-logfiles. right-sms.xml: Only one MS is online and the sms is transmitted correctly. wrong-sms.xml: Two MSs are online. In the logfile you can only see one MS. Until packet No. 102 everything seems to be OK. ATM i don't know were to search on the code. I don't think there is a sms bug. I think there is a memory bug, because the packet No 103 seems to be random (or contains previous data). Maybe someone can give me an advice. Thanks in advance Dennis Wehrle -------------- next part -------------- A non-text attachment was scrubbed... Name: right-sms.xml Type: text/xml Size: 45227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong-sms.xml Type: text/xml Size: 77202 bytes Desc: not available URL: From laforge at gnumonks.org Thu Nov 24 14:45:10 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Nov 2011 15:45:10 +0100 Subject: paralell multipart sms not working In-Reply-To: <4ECE4948.3060807@wehrle.it> References: <4ECE4948.3060807@wehrle.it> Message-ID: <20111124144510.GL23833@prithivi.gnumonks.org> Hi Dennis, thanks for your bug report, I'd be happy to investigate it - but the first question is of course: Do you have the pcap log files of the Abis interface? Also, regarding your suspicion of memory related issues: One idea might be to try the same test with openbsc under valgrind. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From openbsc at wehrle.it Fri Nov 25 18:20:42 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Fri, 25 Nov 2011 19:20:42 +0100 Subject: paralell multipart sms not working In-Reply-To: <20111124144510.GL23833@prithivi.gnumonks.org> References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> Message-ID: <4ECFDC7A.9000902@wehrle.it> Hi Harald Am 24.11.2011 15:45, schrieb Harald Welte: > Hi Dennis, > > thanks for your bug report, I'd be happy to investigate it - but the > first question is of course: Do you have the pcap log files of the Abis > interface? I've tested it once more and here are the abis log-files. I hope i have recorded everything (port 3002 and 3003). The wrong-sms.pcap and wrong-sms-gammu.xml are recorded at the same time. Another test was to send the same multipart sms from one MS to the other (and vice versa) on the same time. This also fails. Additionally the 3310 complains about transmission error. But the other MS (Siemens S55) received several parts of the sms, but not the whole sms. > > Also, regarding your suspicion of memory related issues: One idea might > be to try the same test with openbsc under valgrind. I will make the valgrind stuff next week. Best regards and have a nice weekend, Dennis Wehrle -------------- next part -------------- A non-text attachment was scrubbed... Name: right-sms.pcap Type: application/cap Size: 13486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong-sms.pcap Type: application/cap Size: 38832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wrong-sms-gammu.xml Type: text/xml Size: 68812 bytes Desc: not available URL: From openbsc at wehrle.it Mon Nov 28 15:11:47 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Mon, 28 Nov 2011 16:11:47 +0100 Subject: paralell multipart sms not working In-Reply-To: <20111124144510.GL23833@prithivi.gnumonks.org> References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> Message-ID: <4ED3A4B3.7070203@wehrle.it> Hi Today i had a closer look at the abis pcap file (which i sent on Friday). For me one thing is "strange" but i don't know if this is a normal behavior. Is it OK that sometimes a packet contains 2 sub-packets? For instance: 01. IPv4 02. TCP --------------- 03. IPA 04. RSL 05. CP-DATA 06. RP-DATA 07. SMS-DELIVER --------------- 08. IPA 09. RSL 10. CP-DATA 11. RP-DATA 12. SMS-DELIVER ---------------- As you can see No. 3-7 and 8-12 are both on the same frame. Each sub-packet contains a sms-part (but not for the same sms). Maybe this could be the problem, but i don't know. One (potentially) related issue is that the TIO (transaction identifier) is changing wrongly. The messages are sent as follows (from abis pcap): 01. SMS_1 part 1/5: TIO: 0 02. SMS_2 part 1/4: TIO: 0 03. SMS_1 part 2/5: TIO: 1 04. SMS_2 part 2/4: TIO: 2 (SMS_1) + TIO: 1 (SMS_2) 05. SMS_1 part 3/5: TIO: 2 (SMS_2) + TIO: 3 (SMS_1) 06. SMS_2 part 3/4: TIO: 4 (SMS_1) + TIO: 3 (SMS_2) 07. SMS_2 part 3/4: TIO: 4 (SMS_2) 08. SMS_1 part 4/5: TIO: 5 (SMS_2) + TIO: 5 (SMS_1) 09. SMS_2 part 4/4: TIO: 6 (SMS_1) + TIO: 6 (SMS_2) 10. SMS_2 part 4/4: TIO: 0 (SMS_2) 11. SMS_1 part 5/5: TIO: 1 (SMS_2) + TIO: 0 (SMS_1) 12. SMS_2 part 4/4: TIO: 2 (SMS_2) 13. SMS_1 part 5/5: TIO: 1 (SMS_1) After messages 06, 09 and 13 i get a CP-ERROR message with cause 98: "Message not compatible with short message protocol state" And after messages 07, 08, and 12 i get a CP-ERROR message with cause 81: "Invalid Transaction Identifier value" I hope i'm on the right path because the usage of valgrind was useless (for me). Best regards Dennis Wehrle Am 24.11.2011 15:45, schrieb Harald Welte: > Hi Dennis, > > thanks for your bug report, I'd be happy to investigate it - but the > first question is of course: Do you have the pcap log files of the Abis > interface? > > Also, regarding your suspicion of memory related issues: One idea might > be to try the same test with openbsc under valgrind. > > Regards, > Harald > From 246tnt at gmail.com Mon Nov 28 16:14:53 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 28 Nov 2011 17:14:53 +0100 Subject: paralell multipart sms not working In-Reply-To: <4ED3A4B3.7070203@wehrle.it> References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> <4ED3A4B3.7070203@wehrle.it> Message-ID: Hi, AFAIK It should just not send them in // at all ... it all should be sequential (on the same connection, but still one after the other). Cheers, Sylvain From openbsc at wehrle.it Tue Nov 29 18:42:32 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Tue, 29 Nov 2011 19:42:32 +0100 Subject: paralell multipart sms not working In-Reply-To: References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> <4ED3A4B3.7070203@wehrle.it> Message-ID: <4ED52798.8050007@wehrle.it> Hi Thx for the answer. If i'm right, than the packets will be processed on the __handle_ts1_write-function on ipaccess.c (libosmo-abis). Here the IPA header is added. Then the msg is sent via the send-function. Until here everything looks good. This assumption is made on basis of the debug output for DLMI. The degub output for the msg->l2h / msg-data contains only one complete packet-stack (IPA + RSL + CP-DATA + RP-DATA + SMS-DELIVER). Therefore i think until here everything is OK, except that the send-function should return the number of bytes which are sent, but the value is always too large for three. ATM i don't know whats happen on the send-function. Or maybe lcr is the problem, but i don't know either. Maybe someone can give me an advice where the tcp packets are build up. Best regards Dennis Wehrle Am 28.11.2011 17:14, schrieb Sylvain Munaut: > Hi, > > AFAIK It should just not send them in // at all ... it all should be > sequential (on the same connection, but still one after the other). > > > Cheers, > > Sylvain > From holger at freyther.de Tue Nov 29 20:49:16 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 29 Nov 2011 21:49:16 +0100 Subject: paralell multipart sms not working In-Reply-To: <4ED52798.8050007@wehrle.it> References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> <4ED3A4B3.7070203@wehrle.it> <4ED52798.8050007@wehrle.it> Message-ID: <4ED5454C.7000500@freyther.de> On 11/29/2011 07:42 PM, Dennis Wehrle wrote: > Hi > > until here everything is OK, except that the send-function should return the > number of bytes which are sent, but the value is always too large for three. so it returns less than what we wrote? You can set a delay timer to not things as fast as possible and probably get IPA packets into different IP packets. (thunderbird will wrap this, you can try to apply it by hand) diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c index 2621290..24e85e3 100644 --- a/src/input/ipaccess.c +++ b/src/input/ipaccess.c @@ -512,6 +512,9 @@ static int __handle_ts1_write(struct osmo_fd *bfd, struct e1inp_line *line) DEBUGP(DLMI, "TX %u: %s\n", ts_nr, osmo_hexdump(msg->l2h, msgb_l2len(msg))); ret = send(bfd->fd, msg->data, msg->len, 0); + if (ret != msg->len) + LOGP(DLINP, LOGL_ERROR, "Failed to write: %d/%d errno: %d\n", + ret, msgb_l2len(msg), errno); msgb_free(msg); /* set tx delay timer for next event */ @@ -558,7 +561,7 @@ struct e1inp_driver ipaccess_driver = { .want_write = ts_want_write, .line_update = ipaccess_line_update, .close = ipaccess_close, - .default_delay = 0, + .default_delay = 50000, }; /* callback of the OML listening filedescriptor */ > ATM i don't know whats happen on the send-function. Or maybe lcr is the > problem, but i don't know either. > Maybe someone can give me an advice where the tcp packets are build up. TCP packets are built in the kernel. with nagle the kernel waits a bit to fill the frame[1]. [1] http://lxr.linux.no/linux+v3.1.4/net/ipv4/tcp.c#L914 From holger at freyther.de Tue Nov 29 20:34:34 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 29 Nov 2011 21:34:34 +0100 Subject: paralell multipart sms not working In-Reply-To: <4ED3A4B3.7070203@wehrle.it> References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> <4ED3A4B3.7070203@wehrle.it> Message-ID: <4ED541DA.1080206@freyther.de> On 11/28/2011 04:11 PM, Dennis Wehrle wrote: > Hi > > Today i had a closer look at the abis pcap file (which i sent on Friday). For > me one thing is "strange" but i don't know if this is a normal behavior. Is it > OK that sometimes a packet contains 2 sub-packets? For instance: this is valid behavior (and you see it during RSL/OML bring up), one thing how this can break (and would break OpenBSC/libosmo-abis) is that we do: 1.) ipa_header = recv(3 bytes) 2.) data = recv(ipa_header->len) this would fail in case header and data do not appear on the same frame. So the esoteric question is do you have MTU changes in your network (this assumes that the ipaccess would have similar broken code we have)? holger From openbsc at wehrle.it Wed Nov 30 12:57:42 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Wed, 30 Nov 2011 13:57:42 +0100 Subject: paralell multipart sms not working In-Reply-To: <4ED541DA.1080206@freyther.de> References: <4ECE4948.3060807@wehrle.it> <20111124144510.GL23833@prithivi.gnumonks.org> <4ED3A4B3.7070203@wehrle.it> <4ED541DA.1080206@freyther.de> Message-ID: <4ED62846.1000802@wehrle.it> Hi > >> until here everything is OK, except that the send-function should return the >> number of bytes which are sent, but the value is always too large for three. > > so it returns less than what we wrote? > No msg->len and ret are equal. I think it was my fault. I had count the bytes manually. For example: <001b> ipaccess.c:512 TX 2: 03 01 01 28 02 03 0b 00 02 49 04 <001b> ipaccess.c:514 msg->len 14 <001b> ipaccess.c:520 bfd->fd: 12 <001b> ipaccess.c:521 ret: 14 On line 512 i count manually 15 bytes, but the msg->len and ret value is 18. I think this is OK, than the bytes on line 512 doesn't contain the IPA protocol bytes. I could verify this on wireshark. There are 3 bytes more for the IPA header (00 0b 00). So i would say that i've misinterpreted that. On line 510 the function ipaccess_prepend_header is called and therefore i thought that the bytes for the header is included at the output. I didn't concerned that only the msg->l2h is printed. > > You can set a delay timer to not things as fast as possible and probably get IPA packets into different IP packets. > Unfortunately this doesn't solve the problem. > > this is valid behavior (and you see it during RSL/OML bring up), one thing how > Ok. If this is a valid behavior, maybe i'm on the wrong track. Therefore i don't know how to investigate the problem further. > > this can break (and would break OpenBSC/libosmo-abis) is that we do: > > 1.) ipa_header = recv(3 bytes) > 2.) data = recv(ipa_header->len) > > this would fail in case header and data do not appear on the same frame. So > the esoteric question is do you have MTU changes in your network (this assumes > that the ipaccess would have similar broken code we have)? > No the standard MTU (1500 Bytes) is set. Even if i connect it directly on my pc via a switch the problem occurs. My abis pcap file was created this way. Best regards Dennis Wehrle From 246tnt at gmail.com Thu Nov 24 14:46:59 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 24 Nov 2011 15:46:59 +0100 Subject: paralell multipart sms not working In-Reply-To: <4ECE4948.3060807@wehrle.it> References: <4ECE4948.3060807@wehrle.it> Message-ID: Hi, I didn't look at the deug, but could you try the jolly/sms branch of openbsc ? The SMS part has been rewritten and maybe just trying the new experimental code will fix your issue. Cheers, Sylvain From openbsc at wehrle.it Thu Nov 24 15:49:56 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Thu, 24 Nov 2011 16:49:56 +0100 Subject: paralell multipart sms not working In-Reply-To: References: <4ECE4948.3060807@wehrle.it> Message-ID: <4ECE67A4.6040407@wehrle.it> Hi Thx for you answers. @Sylvain I have tried to use the jolly/sms branch. But with this code i can't send multipart sms from vty. @Harald I don't have the pcap log-file. I have never done this, but this is my next step. I will also test it with valgrind. Best Regards Dennis P.S.: Sorry for (possible) double posting .... Am 24.11.2011 15:46, schrieb Sylvain Munaut: > Hi, > > I didn't look at the deug, but could you try the jolly/sms branch of openbsc ? > > The SMS part has been rewritten and maybe just trying the new > experimental code will fix your issue. > > Cheers, > > Sylvain > From laforge at gnumonks.org Fri Nov 25 08:15:20 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 25 Nov 2011 09:15:20 +0100 Subject: RFC: Osmocom developer workshop 2012 Message-ID: <20111125081520.GL1730@prithivi.gnumonks.org> Please follow-up to openbsc at lists.osmocom.org Hi all, this idea has been around for quite some time, and for 2012 I really want to turn it into reality: I'd like to have a Osmocom developer workshop The idea here is to get all the active contributors of the project together for a couple of days (maybe 2-4 days), in order to exchange ideas, get to know each other better and last but not least work together on ironing out some of the more difficult issues. * City: Regarding the location: I think for me it is only possible to organize it if it is to be held in Berlin. I'mn happy if somebody else wants to host it at some other location, but then that person would also have to take care of local organization. Berlin also has good train and flight connections, which is definitely a plus. * Venue: If it is in Berlin, we might consider talking with c-base or Raumfahrtagentur as possible venues. * Date: Regarding a proposed date, I'm completely open for suggestions. Of course there shouldn't be any overlap with other major FOSS or Sescurity related conferences, and it should also not coincide with major public holidays, as that only makes travel + accomodation more expensive. * Funding: As we don't have that many commercial users of Osmocom projects, getting funding for e.g. travel / accomodation is probably going to be difficult. We can ask the "usual suspects" among those commercial users we know,, but I guess it will only be possible in exceptional cases to provide that kind of funding. Any ideas / comments / feedback is much appreciated. If somebody has a particular suggestion. Please follow-up to openbsc at lists.osmocom.org Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Fri Nov 25 09:43:27 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 25 Nov 2011 10:43:27 +0100 Subject: RFC: Osmocom developer workshop 2012 In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org> References: <20111125081520.GL1730@prithivi.gnumonks.org> Message-ID: Hi, > The idea here is to get all the active contributors of the project > together for a couple of days (maybe 2-4 days), in order to exchange > ideas, get to know each other better and last but not least work > together on ironing out some of the more difficult issues. This would definitely be awesome :) > * City: I think Berlin is a good place. If I'm not mistaken, there is already a fair number of active developers locally in Berlin. And others from Germany in general and I'd guess travel to/from the capital should be easy. I know that travel for me to/from Berlin is also relatively cheap as long as it's not booked too late. > * Venue: > > If it is in Berlin, we might consider talking with c-base or > Raumfahrtagentur as possible venues. Do you by anychance know if any of these location have walking distance cheap hotels ? (sorry don't know Berlin at all except for Alexanderplatz ...) > * Date: I know dealing with everyone requirements is a bit tricky, I can personally free myself pretty much any time given sufficient notice (except for conferences I'm already planning to attend see below) Maybe listing the dates to avoid would give a clearer picture. I don't attend a lot of conferences so I don't know all their dates. The one I'm planning to attend so far are Fosdem, Google IO2012, Deepsec 2012, 29c3. What others to consider ? > * Funding: > > As we don't have that many commercial users of Osmocom projects, getting > funding for e.g. travel / accomodation is probably going to be > difficult. ?We can ask the "usual suspects" among those commercial users > we know,, but I guess it will only be possible in exceptional cases to > provide that kind of funding. Doesn't sound like an issue for me. I can take care of my travel/accommodation costs and participate in any shared cost (venue/misc/...). And if someone can't support the cost, deal with that on a case by case basis ? Maybe starting a Wiki page with the data (people planning to attend / dates to avoid ) ... The openbsc wiki I guess ? Cheers, Sylvain From laforge at gnumonks.org Fri Nov 25 12:38:35 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 25 Nov 2011 13:38:35 +0100 Subject: RFC: Osmocom developer workshop 2012 In-Reply-To: References: <20111125081520.GL1730@prithivi.gnumonks.org> Message-ID: <20111125123835.GX1730@prithivi.gnumonks.org> Hi Sylvain, On Fri, Nov 25, 2011 at 10:43:27AM +0100, Sylvain Munaut wrote: > > * Venue: > > > > If it is in Berlin, we might consider talking with c-base or > > Raumfahrtagentur as possible venues. > > Do you by anychance know if any of these location have walking > distance cheap hotels ? (sorry don't know Berlin at all except for > Alexanderplatz ...) To be honest, I don't know without doing some kind of research. But I guess the point is to find a suitable, inexpensive location first, and as long as it is not at the outskirts of Berlin, there is pretty good public transportation to get around.. > > * Date: > > I know dealing with everyone requirements is a bit tricky, I can > personally free myself pretty much any time given sufficient notice > (except for conferences I'm already planning to attend see below) > > Maybe listing the dates to avoid would give a clearer picture. I don't > attend a lot of conferences so I don't know all their dates. The one > I'm planning to attend so far are Fosdem, Google IO2012, Deepsec 2012, > 29c3. What others to consider ? I have started a wiki page where I wuld like everyone to put in the dates at which they absolutely could not attend such a workshop: http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2012 If somebody has no wiki account: please apply for one or just e-mail me and I will add your details to that page. I would appreciate if people could enter their inavailability dates during the next two weeks, so we could actually try to finalize on a date for the event pretty soon. Thanks! > > * Funding: > > > I can take care of my travel/accommodation costs and participate in > any shared cost (venue/misc/...). My hope is that we can get the venue plus maybe some food sponsored/funded, so people really would only have to take care of their travel + accomodation. > Maybe starting a Wiki page with the data (people planning to attend / > dates to avoid ) ... The openbsc wiki I guess ? indeed, see above. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pablo at gnumonks.org Sat Nov 26 00:40:08 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sat, 26 Nov 2011 01:40:08 +0100 Subject: RFC: Osmocom developer workshop 2012 In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org> References: <20111125081520.GL1730@prithivi.gnumonks.org> Message-ID: <20111126004008.GA21629@1984> On Fri, Nov 25, 2011 at 09:15:20AM +0100, Harald Welte wrote: > * City: > > Regarding the location: I think for me it is only possible to organize > it if it is to be held in Berlin. I'mn happy if somebody else wants to > host it at some other location, but then that person would also have to > take care of local organization. Berlin also has good train and flight > connections, which is definitely a plus. I'm happy with Berlin :-). I can propose Sevilla as alternative, it can be for the next workshop of course. But if you want to make it here, it has to be after february 2012. From alexander.huemer at xx.vu Tue Nov 29 20:15:26 2011 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 29 Nov 2011 21:15:26 +0100 Subject: RFC: Osmocom developer workshop 2012 In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org> References: <20111125081520.GL1730@prithivi.gnumonks.org> Message-ID: <20111129201526.GD26205@de.xx.vu> On Fri, Nov 25, 2011 at 09:15:20AM +0100, Harald Welte wrote: > * City: > > Regarding the location: I think for me it is only possible to organize > it if it is to be held in Berlin. I'mn happy if somebody else wants to > host it at some other location, but then that person would also have to > take care of local organization. Berlin also has good train and flight > connections, which is definitely a plus. I don't consider myself an "active contributor", since I never provided additional features to the various osmo* projects, nevertheless I would like to join the event if that's okay and I find the time. Berlin is fine for me, ... but ... In case anybody wants to get to know a new place, I can offer Salzburg as location, precisely the subnet [1]. One possible + of Salzburg is that it's very close to the border of Germany and therefore the GSM/GSM-R/TETRA nets of 2 countries can be reached in the vicinity. Kind regards, -Alex [1] http://subnet.at/ From laforge at gnumonks.org Sat Nov 26 18:12:45 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Nov 2011 19:12:45 +0100 Subject: RFC: Generic (U)SIM software Message-ID: <20111126181245.GI3773@prithivi.gnumonks.org> Hi all, I'm thinking of starting a project that would allow us to * perform SIM and USIM card pre-personalization * read/dump and explore [U]SIM contents interactively * perform SIM card simulation The idea is to start with some generic data structure that can represent the filesystem tree (DFs, EFs) and their "external" properties, i.e. file type, size, permissions, FID, SFID, etc. This data structure could also have the actual file content associated with each EF. The second step would be some code that can take that data structure and program a freely-programmable card (like sysmoSIM-GR1) and create the files according to that structure. Another module would implement card-simulation (via BT SAP, SIMtrace or virtual PC/SC card). After all, only a few instructions have to be imilpemented if the filesystem and its content is already in a generic data structure that the program can access.. Next step would be to associate parser and generator routines for the content of each individual file as it is specified in TS 11.11. After that has been done, we could think of representing the FS tree and the parsed contents of each file in some kind of graphical / user friendly representation. The idea here is that the UI code would be generic and not know any of the actual ecnoding/decoding of the EF content. The biggest question is what language to use for this. Some kind of object orientation might very well resemble the idea of a 'file object' in a tree, with many different file types, each having it's own parser/encoder. On the other hand, Erlang's bit field syntax would probably come very handy in terms of encoding/decoding the various EF content. However, at least once we start to want some kidn of UI, Erlan really sucsk. Also, almost nobody here reads/writes Erlang [yet?]. Writing all this in C seems like a bit much of an effort, probably even more so on the UI side. However, we already have quite a bit of C code for parsing/generating things like LAI, etc. which are stored like 04.08 inside the sim card files. Python might be a good idea in terms of tons of available libraries/modules, object orientation and good UI bindings. The biggest problem here is that my python skills are really limited so far, so my productivity might not be as high as I expect. The individual components could even be written in different languages, but then we would have to have some common format for exchanging data back and forth - which might not be worth it, given the small scope of the project. any ideas / comments / feedback? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alberto at g-hc.org Sat Nov 26 19:30:36 2011 From: alberto at g-hc.org (Alberto Fabiano) Date: Sat, 26 Nov 2011 17:30:36 -0200 Subject: RFC: Generic (U)SIM software In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org> References: <20111126181245.GI3773@prithivi.gnumonks.org> Message-ID: Well, If you know Erlang, C and C++, python you will learn Python fast! And the advantage is that Python has some projects in which they can be leveraged, for example: http://pyscard.sourceforge.net/ http://michau.benoit.free.fr/codes/smartcard/card/ Recalling also that wrappers between Python and Erlang or C are relatively simple... []s ./alberto -fabiano -vvv On Sat, Nov 26, 2011 at 16:12, Harald Welte wrote: > Hi all, > > I'm thinking of starting a project that would allow us to > * perform SIM and USIM card pre-personalization > * read/dump and explore [U]SIM contents interactively > * perform SIM card simulation > > The idea is to start with some generic data structure that can represent > the filesystem tree (DFs, EFs) and their "external" properties, i.e. > file type, size, permissions, FID, SFID, etc. > > This data structure could also have the actual file content associated > with each EF. > > The second step would be some code that can take that data structure and > program a freely-programmable card (like sysmoSIM-GR1) and create the > files according to that structure. > > Another module would implement card-simulation (via BT SAP, SIMtrace or > virtual PC/SC card). After all, only a few instructions have to be > imilpemented if the filesystem and its content is already in a generic > data structure that the program can access.. > > Next step would be to associate parser and generator routines for the > content of each individual file as it is specified in TS 11.11. > > After that has been done, we could think of representing the FS tree and > the parsed contents of each file in some kind of graphical / user > friendly representation. The idea here is that the UI code would be > generic and not know any of the actual ecnoding/decoding of the EF > content. > > The biggest question is what language to use for this. Some kind of > object orientation might very well resemble the idea of a 'file object' > in a tree, with many different file types, each having it's own > parser/encoder. > > On the other hand, Erlang's bit field syntax would probably come very > handy in terms of encoding/decoding the various EF content. However, at > least once we start to want some kidn of UI, Erlan really sucsk. Also, > almost nobody here reads/writes Erlang [yet?]. > > Writing all this in C seems like a bit much of an effort, probably even > more so on the UI side. However, we already have quite a bit of C code > for parsing/generating things like LAI, etc. which are stored like 04.08 > inside the sim card files. > > Python might be a good idea in terms of tons of available > libraries/modules, object orientation and good UI bindings. The biggest > problem here is that my python skills are really limited so far, so my > productivity might not be as high as I expect. > > The individual components could even be written in different > languages, but then we would have to have some common format for > exchanging data back and forth - which might not be worth it, given the > small scope of the project. > > any ideas / comments / feedback? > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -- ~[&]s; HH /* Happy Hackings! */ AL. /* @AlbertoFabiano */ - .... . -... . ... - .-- .- -.-- - --- .--. .-. . -.. .. -.-. - - .... . ..-. ..- - ..- .-. . .. ... - --- .. -. ...- . -. - .. - .- .-.. .- -. -.- .- -.-- k'b?t Y> "The best way to predict the future is to invent it." --Alan Kay k'b?t X> "Chance favors the prepared mind." --Louis Pasteur k'b?t Z> "The world is full of fascinating problems waiting to be solved" --Eric S.Raymond /* 0x42 0x69 0x74 0x20 0x46 0x61 0x6e */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sat Nov 26 20:14:15 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 26 Nov 2011 21:14:15 +0100 Subject: RFC: Generic (U)SIM software In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org> References: <20111126181245.GI3773@prithivi.gnumonks.org> Message-ID: <4ED14897.7050508@freyther.de> On 11/26/2011 07:12 PM, Harald Welte wrote: > Hi all, > > I'm thinking of starting a project that would allow us to > * perform SIM and USIM card pre-personalization > * read/dump and explore [U]SIM contents interactively Hi, the GUI part is missing but are you aware of https://github.com/znuh/simdump? holger From laforge at gnumonks.org Sun Nov 27 07:06:30 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 27 Nov 2011 08:06:30 +0100 Subject: RFC: Generic (U)SIM software In-Reply-To: <4ED14897.7050508@freyther.de> References: <20111126181245.GI3773@prithivi.gnumonks.org> <4ED14897.7050508@freyther.de> Message-ID: <20111127070627.GR3773@prithivi.gnumonks.org> On Sat, Nov 26, 2011 at 09:14:15PM +0100, Holger Hans Peter Freyther wrote: > On 11/26/2011 07:12 PM, Harald Welte wrote: > > Hi all, > > > > I'm thinking of starting a project that would allow us to > > * perform SIM and USIM card pre-personalization > > * read/dump and explore [U]SIM contents interactively > > Hi, > > the GUI part is missing but are you aware of https://github.com/znuh/simdump? ah, yes, thanks for the reminder. After quickly reading through it, ther is _some_ overlap, though really only some. I've meanwhile wasted some time I don't have with prototyping some of the data structures and concepts in good old C. It's far from being complete, but I've attached it for your reference. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: smartcard_fs.h Type: text/x-chdr Size: 1692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: card_fs_sim.c Type: text/x-csrc Size: 3610 bytes Desc: not available URL: From kevredon at mail.tsaitgaist.info Sun Nov 27 13:52:18 2011 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Sun, 27 Nov 2011 14:52:18 +0100 Subject: RFC: Generic (U)SIM software In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org> References: <20111126181245.GI3773@prithivi.gnumonks.org> Message-ID: <1322399115-sup-9058@dennou> Hi all, I already made some SIM tools, which I call softSIM. It can already dump all the data (files) from the SIM (into an XML), sometimes even parse it, and this dump can be used to simulated a SIM (using BT SAP). More details are available in the wiki article. http://bb.osmocom.org/trac/wiki/softSIM It only handles SIM (I had no need to play with USIM), and is in ruby (not the best language if we want to use it in SIMtrace), but it works great and it can be used as inspiration for re-implementation. Writing a writer or UI based on this code would not take me long, if the existing tools are accepted as base. I'm quite interested in write a reader/writer/simulator in C, but I have not that much time (I use it for SIMtrace at the moment). But I'm happy to help, or do it later on. kevin Excerpts from Harald Welte's message of Sat Nov 26 19:12:45 +0100 2011: > Hi all, > > I'm thinking of starting a project that would allow us to > * perform SIM and USIM card pre-personalization > * read/dump and explore [U]SIM contents interactively > * perform SIM card simulation > > any ideas / comments / feedback? > From marcel at holtmann.org Mon Nov 28 17:00:34 2011 From: marcel at holtmann.org (Marcel Holtmann) Date: Mon, 28 Nov 2011 18:00:34 +0100 Subject: RFC: Generic (U)SIM software In-Reply-To: <20111126181245.GI3773@prithivi.gnumonks.org> References: <20111126181245.GI3773@prithivi.gnumonks.org> Message-ID: <1322499634.29909.49.camel@aeonflux> Hi Harald, > I'm thinking of starting a project that would allow us to > * perform SIM and USIM card pre-personalization > * read/dump and explore [U]SIM contents interactively > * perform SIM card simulation > > The idea is to start with some generic data structure that can represent > the filesystem tree (DFs, EFs) and their "external" properties, i.e. > file type, size, permissions, FID, SFID, etc. > > This data structure could also have the actual file content associated > with each EF. you might wanna have a look at oFono source code. At least for reading EF and parsing them we have extensive support. Check src/simutil.[ch] and src/simfs.[ch]. Same if you care about the SIM Toolkit support. It has support for parsing the majority of data structures you find there. Regards Marcel From laforge at gnumonks.org Mon Nov 28 17:26:16 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 28 Nov 2011 18:26:16 +0100 Subject: RFC: Generic (U)SIM software In-Reply-To: <1322499634.29909.49.camel@aeonflux> References: <20111126181245.GI3773@prithivi.gnumonks.org> <1322499634.29909.49.camel@aeonflux> Message-ID: <20111128172615.GA3241@prithivi.gnumonks.org> Hi Marcel, good to hear from you ! On Mon, Nov 28, 2011 at 06:00:34PM +0100, Marcel Holtmann wrote: > > This data structure could also have the actual file content associated > > with each EF. > > you might wanna have a look at oFono source code. At least for reading > EF and parsing them we have extensive support. Check src/simutil.[ch] > and src/simfs.[ch]. I will check, thanks for the hint. However, I believe you are mostly dealing with DFtelecom, i.e. things like SMS, contact data, etc. - not so much with issues like preferred operator list, Kc, TMSI, SIM service table, etc. But I will RTFS first, before making any more assumptions... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marcel at holtmann.org Tue Nov 29 12:11:51 2011 From: marcel at holtmann.org (Marcel Holtmann) Date: Tue, 29 Nov 2011 13:11:51 +0100 Subject: RFC: Generic (U)SIM software In-Reply-To: <20111128172615.GA3241@prithivi.gnumonks.org> References: <20111126181245.GI3773@prithivi.gnumonks.org> <1322499634.29909.49.camel@aeonflux> <20111128172615.GA3241@prithivi.gnumonks.org> Message-ID: <1322568711.29909.55.camel@aeonflux> Hi Harald, > > > This data structure could also have the actual file content associated > > > with each EF. > > > > you might wanna have a look at oFono source code. At least for reading > > EF and parsing them we have extensive support. Check src/simutil.[ch] > > and src/simfs.[ch]. > > I will check, thanks for the hint. However, I believe you are mostly > dealing with DFtelecom, i.e. things like SMS, contact data, etc. - not > so much with issues like preferred operator list, Kc, TMSI, SIM service > table, etc. actually we doing native EF handling as well. The whole directory structure and all fancy difference between 2G and 3G SIM cards. oFono does way more than any other open source telephony stack I have ever seen. And we do get these things right, I might add :) > But I will RTFS first, before making any more assumptions... Just have a look. You might be able to re-use some parts since the whole code is actually in C. Or at least get you started somehow. Depending on what your goal is this code might be useful or not. It is somewhat tight to our way of handling modems. Regards Marcel From gus at bourg.net Wed Nov 30 23:13:04 2011 From: gus at bourg.net (Gus Bourg) Date: Wed, 30 Nov 2011 15:13:04 -0800 Subject: Time in MM Info [patch] Message-ID: Attached is a patch to support sending time to the device. It adds two per-bts configuration elements: tzunits and tzdir. tzunits are the number of units from GMT. ?Each unit represents 15 minutes of time. tzdir is the direction of the units from GMT. ?tzdir 0 means GMT-tzunits and tzdir 1 means GMT+tzunits. So for example, if you're GMT+1 you want: bts 0 ?type nanobts ?band PCS1900 ?cell_identity 0 ?location_area_code 1 ?training_sequence_code 7 ?base_station_id_code 63 ?tzunits 4 ?tzdir 1 ?ms max power 15 ?cell reselection hysteresis 4 Thanks, Gus -------------- next part -------------- A non-text attachment was scrubbed... Name: MMInfoTime.diff Type: text/x-diff Size: 5640 bytes Desc: not available URL: