From ich at henrik-hansen.de Fri Jan 1 01:41:52 2010 From: ich at henrik-hansen.de (ich at henrik-hansen.de) Date: Fri, 01 Jan 2010 01:41:52 +0000 Subject: OpenBSC / GSM network at camp site In-Reply-To: <4B3CE61E.9050504@chaostreff.ch> References: <20091231101834.GO11704@prithivi.gnumonks.org> <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> <4B3CE61E.9050504@chaostreff.ch> Message-ID: <6f1f55cfc98822275a16f16556f1291f@85.25.59.155> Hi Miguel, maybe my english is too bad to understand :) The problem with the radios is not the usability or the range. The problem is that in germany the 2m Licence is for so called BOS (Police, Firefighters ect.) and that what we do, using the radios for a youthfirefighter event is a grey area in law. (Was ich meine ist das man die dinger eigentlich nur in einsatzfall oder zu ?bungszwecken verwenden soll.) Actual not every youth-advisor got one of these radios. Happy new year. :) On Thu, 31 Dec 2009 18:57:50 +0100, Miguel Elias wrote: > Hi Henrik, > > I think what you need is a local radio repeater. Which does allow you to > expand your reception area. Depending were the camp will be, a local ham > radio (funk amateure) club could be able to help you, at least to finde > the right equipment for your event. > > That would allow you to use the 2m commercial radios and save money in > the same time. > > regards > miguel From ich at henrik-hansen.de Fri Jan 1 04:39:00 2010 From: ich at henrik-hansen.de (ich at henrik-hansen.de) Date: Fri, 01 Jan 2010 04:39:00 +0000 Subject: OpenBSC / GSM network at camp site In-Reply-To: <4B3D6662.7010505@chaostreff.ch> References: <20091231101834.GO11704@prithivi.gnumonks.org> <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> <4B3CE61E.9050504@chaostreff.ch> <4B3D6662.7010505@chaostreff.ch> Message-ID: <7644e20e44f698443c3abb6b6cce2efd@85.25.59.155> On Fri, 01 Jan 2010 04:05:06 +0100, Miguel Elias wrote: > hi hi, nicht witzig ich arbeite momentan dran :) > 2m sind normalerweise f?r amateure verwendet, die bos sind normalerweise > auf 4m, aber dass heist nicht das auch auf den kommerziellen frequenzen > auch bos dienste m?glich sind. Stimmt schon nur sagt die PDV/DV 800 (hab sie momentan nicht hier, daher kann ich nicht zitieren) das der 2m W/U Funk auf den Betriebskan?len nur f?r ?bungs und einsatzzwecke zu verwenden ist. > ich sehe das nicht so eng und ich denke auch die bnetza nicht, da ihr > auf dem camp nicht den funkdienst mitsbraucht sondern auch da ?bungen > f?r eure feuerwehrarbeit. Die Interessiert das herzlich wenig, habe schon 4 auf 2m Relais gesehen um der knappheit an 4m Handfunkger?ten zu entgehen. Rechtlich gesehen absolutes no-go aber kratzt keinen. > es wird wird wohl einfacher sein, mehr dieser 2m funkger?te zubesorgen > und zus?tlich ein sog. relais zu besorgen, welches du dann an einem > hohen standort installieren m?sstes... damit w?rdest jenach gegenheiten > bis zu 30km und mehr abdecken. Da kommen wir schonwieder zu diversen Problemen, BOS 2m Ger?te sind eher unerschwinglich (minimum 300eu). Akkus sind relativ teuer. Und sie werden mei?tens (99%) daf?r angeschafft um auf Fahrzeugen verlastet zu sein. Um im Ernstfalle (Einsatzfall) halt Griffbereit zu sein. Das wir derzeit f?rs Zeltlager diese Menge an 2m aus dem Tagesgesch?ft rausziehen ist vielen aktiven Kammeraden ein riesiges Dorn im Auge. Und ehrlich gesagt will ich das auch nicht mehr, weil Funk nur dann funktioniert wenn alle richtig Mitspielen. Dar?berhinaus habe ich selbst schon oft die erfahrung gemacht das man oft im Feld bei den Kids, es nicht mitbekommt wenn man selber gerufen wird. Und was passiert? 30sek. sp?ter klingelt das Handy. 30km h?rt sich zwar verdammt lecker an, ist aber nicht das was ich will. Fl?che von ca 90.000 qm = quadrat von 300m :) (im idealfall) > eine BTS f?r ein soches netz aufzubauen ist zu einem gewissen grad ein > overkill... Finde ich nicht. Derzeit habe ich zwar noch nicht wirklich Informationen dar?ber welches Einzugsgebiet ich mit ner nanoBTS abdecken kann, aber wenns was werden sollte denke ich das wir minimum 2 eher 3 BTS'n aufbauen werden. Derzeit habe ich noch keine offiziellen Preise gefunden, aber bereits den Hinweis bekommen das die Kisten f?r rund 2.5keu ?ber den Ladentisch gehen. Endger?te finden sich in den mei?ten Haushalten. Ob man jetzt beigeht und sein prim?r Handy verwendet, oder das vor-24Monats Modell welches in der Schublade oxidiert, ist jetzt erstmal egal. Aber defakto ist doch das Endger?te vorhanden sind. Weiterhin ist f?r mich entscheidend das niemand von mir eine Einweisung in ein Handy braucht. Im regelfall wei? jeder wie sein Handy funktioniert und wenn nicht... ich hab 2000 potentielle 1-Level-Supporter rumlaufen :D Letztlich denke ich das in vielen K?pfren vorhanden ist, das GSM bzw. Mobile Kommunikation immer was mit teurer Technik verbunden ist. Was defakto durch die Arbeit des openBTS Projekts einfach nicht mehr der fall ist. (An dieser Stelle nochmal vielen Dank f?r die tolle Arbeit) Ausserdem warum nicht? Was spricht dagegen GSM zu verwenden (und Geld ist f?r mich kein Grund)? Gru? Henrik From peter.hasse at fokus.fraunhofer.de Fri Jan 1 23:18:24 2010 From: peter.hasse at fokus.fraunhofer.de (Peter Hasse) Date: Sat, 02 Jan 2010 00:18:24 +0100 Subject: OpenBSC / GSM network at camp site In-Reply-To: <7644e20e44f698443c3abb6b6cce2efd@85.25.59.155> References: <20091231101834.GO11704@prithivi.gnumonks.org> <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> <4B3CE61E.9050504@chaostreff.ch> <4B3D6662.7010505@chaostreff.ch> <7644e20e44f698443c3abb6b6cce2efd@85.25.59.155> Message-ID: <4B3E82C0.6020108@fokus.fraunhofer.de> Hi Henrik Maybe it will be much easy to ask the guys from eventphone (eventphone.de) or some companys who work with DECT stuff (The OpenRheinRuhr conference was sponsored by such an company). To operate a DECT network you don't need a special license and it will be much more easy to explain the people whats going on. mfg Peter From till.lober at gmail.com Fri Jan 1 23:41:41 2010 From: till.lober at gmail.com (Lober, Till F) Date: Sat, 2 Jan 2010 00:41:41 +0100 Subject: OpenBSC / GSM network at camp site In-Reply-To: <7644e20e44f698443c3abb6b6cce2efd@85.25.59.155> References: <20091231101834.GO11704@prithivi.gnumonks.org> <5191f22fd38e6bbe47f1d6e587e02487@85.25.59.155> <4B3CE61E.9050504@chaostreff.ch> <4B3D6662.7010505@chaostreff.ch> <7644e20e44f698443c3abb6b6cce2efd@85.25.59.155> Message-ID: <3aa69e41001011541o76c52a6fha358b209f62cdc9e@mail.gmail.com> 2010/1/1 > > Das wir derzeit f?rs Zeltlager diese Menge an 2m aus dem Tagesgesch?ft > rausziehen ist vielen aktiven Kammeraden ein riesiges Dorn im Auge. Und > ehrlich gesagt will ich das auch nicht mehr, weil Funk nur dann > funktioniert wenn alle richtig Mitspielen. Dar?berhinaus habe ich selbst > schon oft die erfahrung gemacht das man oft im Feld bei den Kids, es nicht > mitbekommt wenn man selber gerufen wird. Und was passiert? 30sek. sp?ter > klingelt das Handy. > schaue Dich mal bei den "no-frills-Betreibern" um und du wirst dort sehr interessante Angebote finden. Damit ist interne Kommunikation f?r sehr schmales Geld m?glich. (Teilweise Flatrates oder nur wenige ct/Min. Einfach mal die Abdeckung an der Camp-Site checken und dann ein passendes Angebot raussuchen. Ich empfehle hier die PrePaid-Wiki http://prepaid-wiki.de/index.php5?title=Tariftabelle_Prepaid Gruss TL -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Jan 6 06:59:21 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 6 Jan 2010 07:59:21 +0100 Subject: Stack corruption from set_system_infos In-Reply-To: <20091231102300.GP11704@prithivi.gnumonks.org> References: <200912310612.32158.zecke@selfish.org> <20091231102300.GP11704@prithivi.gnumonks.org> Message-ID: <201001060759.22270.zecke@selfish.org> On Thursday 31 December 2009 11:23:00 Harald Welte wrote: > Hi Zecke, > > Now what happens is: > > 1.) some system information types structs are already bigger > > than the 23 bytes... > > why are they? How can that be? How can a SI message be larger than the > physical limitation of the MAC-Block? This sounds like the root cause > of the problem to me. This was bullshit... Here is the root cause: For SI5 and SI6 we have to deal with the BS11 of having left the length field out... What we are doing is: char output[23]; if (is_nano_bts) { *output = len; ++output; } si6 = (struct si6*) output; memset(si6, padding, 23); And one thing I have found as well, but it seems more like I'm wrong. All data_len of the bitvector are one too big? Is that done on purpose? Patch 0001 and 0003 are of cosmetic nature, 0002 and 0004 seem to fix the stack corruption my system is seeing. regards holger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-system_information-Initialize-the-buffer-before-movi.patch Type: text/x-patch Size: 1943 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-rest_octets-Change-data_len-to-the-sizes-of-the-spec.patch Type: text/x-patch Size: 1729 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-system_information-Return-how-much-byte-were-written.patch Type: text/x-patch Size: 2796 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-rest_octets-Return-bv.data_len-to-indicate-how-was-w.patch Type: text/x-patch Size: 1650 bytes Desc: not available URL: From laforge at gnumonks.org Thu Jan 7 09:19:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Jan 2010 10:19:30 +0100 Subject: Stack corruption from set_system_infos In-Reply-To: <201001060759.22270.zecke@selfish.org> References: <200912310612.32158.zecke@selfish.org> <20091231102300.GP11704@prithivi.gnumonks.org> <201001060759.22270.zecke@selfish.org> Message-ID: <20100107091930.GX1235@prithivi.gnumonks.org> hi Zecke, On Wed, Jan 06, 2010 at 07:59:21AM +0100, Holger Freyther wrote: > On Thursday 31 December 2009 11:23:00 Harald Welte wrote: > > Hi Zecke, > > > > Now what happens is: > > > 1.) some system information types structs are already bigger > > > than the 23 bytes... > > > > why are they? How can that be? How can a SI message be larger than the > > physical limitation of the MAC-Block? This sounds like the root cause > > of the problem to me. > > This was bullshit... > > Here is the root cause: > > For SI5 and SI6 we have to deal with the BS11 of having left the length field > out... What we are doing is: > > char output[23]; > if (is_nano_bts) { > *output = len; > ++output; > } > > si6 = (struct si6*) output; > memset(si6, padding, 23); > > And one thing I have found as well, but it seems more like I'm wrong. All > data_len of the bitvector are one too big? Is that done on purpose? no, that is an artefact from the 04.08 spec always claiming that an IE has a certain length, but then icnluding the TAG, despite never sending the TAG in front of the IE on the actual air interface. > Patch 0001 and 0003 are of cosmetic nature, 0002 and 0004 seem to fix the stack > corruption my system is seeing. Please apply them, they're fine. In addition, we should probably remove the ++output from the generate_si, and have the RSL layer deal with it. Specifically: * include the system_information_type_header in SI5 and SI6 data structures * make sure the buffers passed to generate_si are large enough to include the l2_plen, maybe even check at runtime to be sure * in the RSL layer (rsl_sacch_filling()), check the trx->bts->type and either drop the length (BS11) or keep it (all other BTS) Thanks in advance, 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 Sat Jan 2 23:27:04 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 3 Jan 2010 00:27:04 +0100 Subject: Branches update & things to consider for merging Message-ID: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> Hi, I've just tested code I started at 26c3 but didn't get a chance to test and I updated my various branches. Here's a little status : sylvain/rrlp : This contains only changes to rrlp-ephemeris. Mostly fixes and more support to provide assistance data. Also asn1c patches to fix bugs and a script for people to generate their own test data.ubx from their receiver (to get up-to-date / local data). sylvain/pending: Various things / fixes I made that I consider ready to be reviewed / merged. I tested it all on both my nanoBTS 139. sylvain/encryption: The current state of my encryption support work. I rebased it and used the db structure you pushed for encryption. Everything but the last 3 patches are pre-work / preparation / fixes and are imho OK. The last 3 patches are the real implementation and I also think they're in pretty good shape. Tested and working here :) Limitations includes : No Kc re-use & No MT encryption yet. sylvain/encryption_testing: More encryption work, based on sylvain/encryption but not done/ready. Only pushed so that people can have a peek ... Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jan 3 09:57:56 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Jan 2010 10:57:56 +0100 Subject: Branches update & things to consider for merging In-Reply-To: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> References: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> Message-ID: <20100103095756.GC19642@prithivi.gnumonks.org> Hi Sylvain, thanks again for all your work. On Sun, Jan 03, 2010 at 12:27:04AM +0100, Sylvain Munaut wrote: > sylvain/rrlp : This contains only changes to rrlp-ephemeris. Mostly fixes > and more support to provide assistance data. Also asn1c patches to fix bugs > and a script for people to generate their own test data.ubx from their > receiver (to get up-to-date / local data). > > sylvain/pending: Various things / fixes I made that I consider ready to be > reviewed / merged. I tested it all on both my nanoBTS 139. Thanks, I've cherry-picked all I could right now. I'll have to test the software activation related changes with my nanoBTS's and with the BS-11. I expect to do this later today. As for the ebab9a9e (Differentiate paging success), I think this code needs to update 04_11.c and silent_call.c as well, i.e. all locations where PAGING_SUCCEEDED is is currently used. > sylvain/encryption: The current state of my encryption support work. I > rebased it and used the db structure you pushed for encryption. Everything > but the last 3 patches are pre-work / preparation / fixes and are imho OK. > The last 3 patches are the real implementation and I also think they're in > pretty good shape. Tested and working here :) Limitations includes : No Kc > re-use & No MT encryption yet. I disagree with removing the 'id' primary key for AuthTuples and AuthKeys. Without that id we have it very hard to remove a single authtuple from the database manually, since we would have to provide the subscriber_id and some BLOB to select only a single entry. This is why I did not merge this particular commit. All the others (minus the last three) inside the encryption branch should have been merged now. It would be great if you can rebase those last three commits and your encryption_testing branch on current master and continue testing. Regards, -- - 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 Sun Jan 3 10:22:25 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 3 Jan 2010 11:22:25 +0100 Subject: Branches update & things to consider for merging In-Reply-To: <20100103095756.GC19642@prithivi.gnumonks.org> References: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> <20100103095756.GC19642@prithivi.gnumonks.org> Message-ID: <866320f71001030222l3e2bc8e2l87f4366823715d73@mail.gmail.com> Hi, Thanks, I've cherry-picked all I could right now. > > I'll have to test the software activation related changes with my nanoBTS's > and > with the BS-11. I expect to do this later today. > Great ! What about the rrlp branch ? They are only changes to rrlp-ephemeris and the .gitignore patch is especially useful to ignore the output of asn1c (without that git detects thousands of new files if you have built it :) > As for the ebab9a9e (Differentiate paging success), I think this code > needs to update 04_11.c and silent_call.c as well, i.e. all locations > where PAGING_SUCCEEDED is is currently used. > Mmm, I don't understand what you mean here. in 04_11 & silent call, it's not the signal dispatch that's used but the call back specified when making the paging request. The advantage of the call back is that you can give contextual information and it's only called for that specific It's true that for sms, we could just check every time a paging succeed if there are pending SMS ... But for silent_call & 04_08 MT calls I think the call back need to stay. > > sylvain/encryption: The current state of my encryption support work. I > > rebased it and used the db structure you pushed for encryption. > Everything > > but the last 3 patches are pre-work / preparation / fixes and are imho > OK. > > The last 3 patches are the real implementation and I also think they're > in > > pretty good shape. Tested and working here :) Limitations includes : No > Kc > > re-use & No MT encryption yet. > > I disagree with removing the 'id' primary key for AuthTuples and AuthKeys. > > Without that id we have it very hard to remove a single authtuple from the > database manually, since we would have to provide the subscriber_id and > some > BLOB to select only a single entry. This is why I did not merge this > particular > commit. > ? In both table, you have : subscriber_id NUMERIC UNIQUE NOT NULL, since there is a UNIQUE, there can't be two entries for the same subscriber and so you can just delete by specifying the subscriber_id. > All the others (minus the last three) inside the encryption branch should > have been merged now. > > It would be great if you can rebase those last three commits and your > encryption_testing branch on current master and continue testing. > Sure. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jan 7 09:38:47 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Jan 2010 10:38:47 +0100 Subject: Branches update & things to consider for merging In-Reply-To: <866320f71001030222l3e2bc8e2l87f4366823715d73@mail.gmail.com> References: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> <20100103095756.GC19642@prithivi.gnumonks.org> <866320f71001030222l3e2bc8e2l87f4366823715d73@mail.gmail.com> Message-ID: <20100107093847.GY1235@prithivi.gnumonks.org> Hi Sylvain, On Sun, Jan 03, 2010 at 11:22:25AM +0100, Sylvain Munaut wrote: > > I'll have to test the software activation related changes with my nanoBTS's > > and with the BS-11. I expect to do this later today. this still hasn't happened, I suppose I'll get around doing it today. > What about the rrlp branch ? They are only changes to rrlp-ephemeris and the > .gitignore patch is especially useful to ignore the output of asn1c (without > that git detects thousands of new files if you have built it :) I have merged it right now. Feel free to commit directly to the master branch as long as you only touch rrlp-ephemeris code. After all, it's your code! I just didn't want direct commit's to openbsc in the master branch. Thanks. > > As for the ebab9a9e (Differentiate paging success), I think this code > > needs to update 04_11.c and silent_call.c as well, i.e. all locations > > where PAGING_SUCCEEDED is is currently used. > > > > Mmm, I don't understand what you mean here. It was my misunderstanding, sorry. I've applied it now. > > I disagree with removing the 'id' primary key for AuthTuples and AuthKeys. > > > > Without that id we have it very hard to remove a single authtuple from the > > database manually, since we would have to provide the subscriber_id and > > some BLOB to select only a single entry. This is why I did not merge this > > particular commit. > > ? > In both table, you have : > > subscriber_id NUMERIC UNIQUE NOT NULL, > > since there is a UNIQUE, there can't be two entries for the same subscriber > and so you can just delete by specifying the subscriber_id. That's wrong then. subscriber_id should be unique for AuthInfo, but not for AuthTuples. We can (and should!) have multiple auth tuples for a subscriber and also think of a way how we can cycle through them (or randomly select one of them each time we need one) Also, if subscriber_id is UNIQUE in AuthInfo, then we can remove the id there, like you proposed. -- - 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: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From 246tnt at gmail.com Thu Jan 7 13:22:58 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 7 Jan 2010 14:22:58 +0100 Subject: Branches update & things to consider for merging In-Reply-To: <20100107093847.GY1235@prithivi.gnumonks.org> References: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> <20100103095756.GC19642@prithivi.gnumonks.org> <866320f71001030222l3e2bc8e2l87f4366823715d73@mail.gmail.com> <20100107093847.GY1235@prithivi.gnumonks.org> Message-ID: <866320f71001070522wb5d380fhd75e8d01d8ed5ea6@mail.gmail.com> Hi, That's wrong then. subscriber_id should be unique for AuthInfo, but not for > AuthTuples. We can (and should!) have multiple auth tuples for a > subscriber > and also think of a way how we can cycle through them (or randomly select > one > of them each time we need one) > AFAIK, the phone only keeps the data from last authentication ( Kc & key_seq ). When you send a CIPHER MODE COMMAND, it will use the last negotiated one, no choice there. The "key sequence" parameter which is given by the network during the authentication is just there so that on the next channel opening, the MS can send it (in LOC UPD REQ / PAGING RESP / CM SERV REQ) and the network can compare it to the last key_seq it emitted for this subscriber. * If they match, the network 'knows' that the last negotiated Kc is still ok (with a 1/16 chance of being wrong ...) and doesn't need a new authentication. * If they don't match, it's probably that the GSM has roamed somewhere else at some point and the Kc in the phone and in the Network don't match, so they need to renegotiate a new one. Keeping multiple AuthTuple for a subscriber would be useless since only the last one has usable data. And it's even easier if we only keep one because this way, to find the next "key sequence", we can just take the old stored one and increment it ... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jan 7 16:55:12 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Jan 2010 17:55:12 +0100 Subject: Branches update & things to consider for merging In-Reply-To: <866320f71001070522wb5d380fhd75e8d01d8ed5ea6@mail.gmail.com> References: <866320f71001021527h58c9af5cu386032fbdb227e49@mail.gmail.com> <20100103095756.GC19642@prithivi.gnumonks.org> <866320f71001030222l3e2bc8e2l87f4366823715d73@mail.gmail.com> <20100107093847.GY1235@prithivi.gnumonks.org> <866320f71001070522wb5d380fhd75e8d01d8ed5ea6@mail.gmail.com> Message-ID: <20100107165512.GE1235@prithivi.gnumonks.org> Hi Sylvain, On Thu, Jan 07, 2010 at 02:22:58PM +0100, Sylvain Munaut wrote: > AFAIK, the phone only keeps the data from last authentication ( Kc & key_seq > ). > When you send a CIPHER MODE COMMAND, it will use the last negotiated one, no > choice there. of course. I meant you can keep multiple of them so you can select one of them before doing an AUTH COMMAND > Keeping multiple AuthTuple for a subscriber would be useless since only the > last one has usable data. And it's even easier if we only keep one because > this way, to find the next "key sequence", we can just take the old stored > one and increment it ... The idea of the AuthTuple is as follows: * you don't know the Ki of a SIM card * you still want to use authentication/encryption * so you send a couple of challenges to the SIM, remember the RAND and record the SRES + Kc that you get now every time you want to authenticate that sim, you randomly select one of your known AuthTuples and send the recorded RAND, compare the SRES. -- - 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 Wed Jan 6 07:58:42 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 6 Jan 2010 08:58:42 +0100 Subject: Question about the "Move db usage out of the libbsc (fork dumping of subscr)" commit Message-ID: <866320f71001052358l3743907ci6aad1f473ec685ac@mail.gmail.com> Hi, I don't see how this commits helps ? The function code is exactly the same in both files and the db.c dependency in vty_interface.c hasn't been removed. Am I missing something here ? [ See commit 424c4f0e2927d5a7538b31c69113c6e4f861d2c9 on the git for context ] Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Jan 6 08:20:23 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 6 Jan 2010 09:20:23 +0100 Subject: Question about the "Move db usage out of the libbsc (fork dumping of subscr)" commit In-Reply-To: <866320f71001052358l3743907ci6aad1f473ec685ac@mail.gmail.com> References: <866320f71001052358l3743907ci6aad1f473ec685ac@mail.gmail.com> Message-ID: <201001060920.23554.zecke@selfish.org> On Wednesday 06 January 2010 08:58:42 Sylvain Munaut wrote: > Hi, > > I don't see how this commits helps ? The function code is exactly the same > in both files and the db.c dependency in vty_interface.c hasn't been > removed. > Am I missing something here ? Well... this is all not set to stone but the idea is the following: libbsc.a contains all functionality that is in the domain of the BSC. This includes the vty_interface.c. libmsc.a contains all the handling of GSM04.08. In our case even the HLR/VLR (db.c). In our case this is everything that is not in the BSC. bsc_hack links to the libbsc and libmsc and adds vty_interface_layer3. Now the dependencies don't really matter as the link will just resolve them. For the on-waves/bsc-master branch I'm only using libbsc.a. This means your commit added a dependency on db.c again. On top of that it will really help us keeping the BSC/MSC separation in place which is beneficial to stuff like channel handling.. does this clear things up? From 246tnt at gmail.com Wed Jan 6 08:35:10 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 6 Jan 2010 09:35:10 +0100 Subject: Question about the "Move db usage out of the libbsc (fork dumping of subscr)" commit In-Reply-To: <201001060920.23554.zecke@selfish.org> References: <866320f71001052358l3743907ci6aad1f473ec685ac@mail.gmail.com> <201001060920.23554.zecke@selfish.org> Message-ID: <866320f71001060035y67829d0atfd7a0a9d4c4e2e65@mail.gmail.com> Hi, libbsc.a contains all functionality that is in the domain of the BSC. This > includes the vty_interface.c. > > libmsc.a contains all the handling of GSM04.08. In our case even the > HLR/VLR > (db.c). In our case this is everything that is not in the BSC. > > bsc_hack links to the libbsc and libmsc and adds vty_interface_layer3. Now > the > dependencies don't really matter as the link will just resolve them. > > For the on-waves/bsc-master branch I'm only using libbsc.a. This means your > commit added a dependency on db.c again. On top of that it will really help > us > keeping the BSC/MSC separation in place which is beneficial to stuff like > channel handling.. > > does this clear things up? > I understand the idea of separation (the naming scheme _layer3 could be better :). But what I don't see is how that commits restores it. Because it doesn't remove the db.c dependency: from vty_interface.c you still access the DB. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Jan 6 08:42:22 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 6 Jan 2010 09:42:22 +0100 Subject: Question about the "Move db usage out of the libbsc (fork dumping of subscr)" commit In-Reply-To: <866320f71001060035y67829d0atfd7a0a9d4c4e2e65@mail.gmail.com> References: <866320f71001052358l3743907ci6aad1f473ec685ac@mail.gmail.com> <201001060920.23554.zecke@selfish.org> <866320f71001060035y67829d0atfd7a0a9d4c4e2e65@mail.gmail.com> Message-ID: <201001060942.22497.zecke@selfish.org> On Wednesday 06 January 2010 09:35:10 Sylvain Munaut wrote: > Hi, > I understand the idea of separation (the naming scheme _layer3 could be > better :). > But what I don't see is how that commits restores it. Because it doesn't > remove the > db.c dependency: from vty_interface.c you still access the DB. hehe, that is just a human error... :) z. From dkarampa at gmail.com Wed Jan 6 12:49:39 2010 From: dkarampa at gmail.com (Dimitris Karampatsis) Date: Wed, 6 Jan 2010 14:49:39 +0200 Subject: OpenBSC code questions Message-ID: Hello, I ?ve tried to use the latest OpenBSC code with a nanoBTS at 850 MHz. I have been able to compile the code in Debian Linux and run it successfully. Mobiles were able to register successfully to the network. In addition the IMSI and TMSI numbers were collected successfully. However, I have encountered a few issues that are summarised below: - Segmentation faults (software crashes) occur in situations where I try to send an SMS message through the telnet interface or when I try to make a phone call from one mobile to another - When sending SMSs from one mobile to another, the SMS are collected successfully to the database but are not sent to the other mobile. In the telnet interface I use the command ?SMS SEND PENDING? but nothing happens. The SMSs are sent to the terminating mobile when either restarting the OpenBSC software or when the terminating mobile re-registers to the OpenBSC network - IMEI numbers are sometimes not collected (especially on Nokia phones) or the wrong IMEI number is displayed Have anyone else noticed these issues? I am trying to install a debugger to check why the segmentation faults occurs. The only debugger that works is from Netbeans that uses the GDB debugger. However the debugger hangs when trying to initialise the database (it stucks in command dbi_initialize(NULL) on db.c file) Can anyone help why the debugger hangs or recommend a debugger that will work with this code? Many thanks Regards, Dimitris -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Wed Jan 6 13:40:01 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 6 Jan 2010 14:40:01 +0100 Subject: OpenBSC code questions In-Reply-To: References: Message-ID: <201001061440.01709.zecke@selfish.org> On Wednesday 06 January 2010 13:49:39 Dimitris Karampatsis wrote: > Hello, > > I ?ve tried to use the latest OpenBSC code with a nanoBTS at 850 MHz. > > Can anyone help why the debugger hangs or recommend a debugger that will > work with this code? Bugs... Bugs... Bugs... libdbi is doing something weird with threads that freak out gdb... I did not have a the time to look into GDB to understand this. Your options are: 1.) Use coredumps # enabling core dumps ulimit -c unlimited ./bsc_hack... after crashing you have a "core" file... (or use ulimit -c 9999999, for another set of Bash bugs) # using a core dump gdb ./bsc_hack core bt 2.) Attach to the app after it has been started. z. From laforge at gnumonks.org Thu Jan 7 08:58:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Jan 2010 09:58:30 +0100 Subject: OpenBSC code questions In-Reply-To: References: Message-ID: <20100107085830.GV1235@prithivi.gnumonks.org> Hi Dimitris, On Wed, Jan 06, 2010 at 02:49:39PM +0200, Dimitris Karampatsis wrote: > I ?ve tried to use the latest OpenBSC code with a nanoBTS at 850 MHz. great news. I think you might be the first one. > I have been able to compile the code in Debian Linux and run it > successfully. Mobiles were able to register successfully to the network. In > addition the IMSI and TMSI numbers were collected successfully. However, I > have encountered a few issues that are summarised below: > > - Segmentation faults (software crashes) occur in situations where I try > to send an SMS message through the telnet interface or when I try to make a > phone call from one mobile to another gdb backtraces would be helpful in those cases. I have not seen any of those, at least not in configurations with a single BTS. The only case I remember seeing this is when you have multiple BTS in the same location area, which is currently not supported. > - When sending SMSs from one mobile to another, the SMS are collected > successfully to the database but are not sent to the other mobile. In the > telnet interface I use the command ?SMS SEND PENDING? but nothing happens. > The SMSs are sent to the terminating mobile when either restarting the > OpenBSC software or when the terminating mobile re-registers to the OpenBSC > network that is strange, and definitely works here. > - IMEI numbers are sometimes not collected (especially on Nokia phones) > or the wrong IMEI number is displayed I have also noticed the missing collection of IMEI numbers, but have not yet debugged it. Regarding apparent "wrong" numbers: We are inquiring the IMEI, whereas what you see on *#06# is the IMEISV. It might be that this is the vcase. > I am trying to install a debugger to check why the segmentation faults > occurs. The only debugger that works is from Netbeans that uses the GDB > debugger. However the debugger hangs when trying to initialise the database > (it stucks in command dbi_initialize(NULL) on db.c file) > > Can anyone help why the debugger hangs or recommend a debugger that will > work with this code? we all work with gdb. What we usually do is to do something like 'ulimit -c unlimited', then start bsc_hack. When it crashes, it leaves a 'core' file. You can then start the debugger using 'gdb ./bsc_hack ./core' and see the backtrace, navigate through the call stack, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From daniel at totalueberwachung.de Thu Jan 7 02:20:50 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 7 Jan 2010 03:20:50 +0100 Subject: [PATCH 0/5] Change PLL set/work value Message-ID: Hello, this list of patches includes support to change the PLL set and work value with bs11_config. Many thanks go to Dieter Spaar who figured out how to change the work value. Harald, if these patches are okay for you I'll go ahead and commit them. Regards, Daniel Willmann (5): [abis_nm] Add generic abis_nm_bs11_logon function [abis_nm] Add abis_nm_bs11_infield_logon to logon as user field [abis_nm] Add abis_nm_bs11_set_pll function to change the set/work value [bs11_config] Whitespace changes so the help text looks nice [bs11_config] Add pll-setvalue and pll-workvalue commands openbsc/include/openbsc/abis_nm.h | 3 ++ openbsc/src/abis_nm.c | 39 +++++++++++++++++++++++++--- openbsc/src/bs11_config.c | 50 +++++++++++++++++++++++++----------- 3 files changed, 72 insertions(+), 20 deletions(-) From daniel at totalueberwachung.de Thu Jan 7 02:20:51 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 7 Jan 2010 03:20:51 +0100 Subject: [PATCH 1/5] [abis_nm] Add generic abis_nm_bs11_logon function In-Reply-To: References: Message-ID: Factoring out common logon functionality will allow us to logon as different user. abis_nm_bs11_factory_logon now uses this function. --- openbsc/include/openbsc/abis_nm.h | 1 + openbsc/src/abis_nm.c | 13 ++++++++----- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/openbsc/include/openbsc/abis_nm.h b/openbsc/include/openbsc/abis_nm.h index 6876435..8fe4b0c 100644 --- a/openbsc/include/openbsc/abis_nm.h +++ b/openbsc/include/openbsc/abis_nm.h @@ -787,6 +787,7 @@ int abis_nm_bs11_get_oml_tei_ts(struct gsm_bts *bts); int abis_nm_bs11_get_serno(struct gsm_bts *bts); int abis_nm_bs11_set_trx_power(struct gsm_bts_trx *trx, u_int8_t level); int abis_nm_bs11_get_trx_power(struct gsm_bts_trx *trx); +int abis_nm_bs11_logon(struct gsm_bts *bts, u_int8_t level, const char *name, int on); int abis_nm_bs11_factory_logon(struct gsm_bts *bts, int on); int abis_nm_bs11_set_trx1_pw(struct gsm_bts *bts, const char *password); int abis_nm_bs11_set_pll_locked(struct gsm_bts *bts, int locked); diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 7a67fdf..3d337e2 100644 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -2416,11 +2416,14 @@ int abis_nm_bs11_get_cclk(struct gsm_bts *bts) } //static const u_int8_t bs11_logon_c7[] = { 0x07, 0xd9, 0x01, 0x11, 0x0d, 0x10, 0x20 }; -static const u_int8_t bs11_logon_c8[] = { 0x02 }; -static const u_int8_t bs11_logon_c9[] = "FACTORY"; int abis_nm_bs11_factory_logon(struct gsm_bts *bts, int on) { + return abis_nm_bs11_logon(bts, 0x02, "FACTORY", on); +} + +int abis_nm_bs11_logon(struct gsm_bts *bts, u_int8_t level, const char *name, int on) +{ struct abis_om_hdr *oh; struct msgb *msg = nm_msgb_alloc(); struct bs11_date_time bdt; @@ -2430,15 +2433,15 @@ int abis_nm_bs11_factory_logon(struct gsm_bts *bts, int on) oh = (struct abis_om_hdr *) msgb_put(msg, ABIS_OM_FOM_HDR_SIZE); if (on) { u_int8_t len = 3*2 + sizeof(bdt) - + sizeof(bs11_logon_c8) + sizeof(bs11_logon_c9); + + 1 + strlen(name); fill_om_fom_hdr(oh, len, NM_MT_BS11_LMT_LOGON, NM_OC_BS11_BTSE, 0xff, 0xff, 0xff); msgb_tlv_put(msg, NM_ATT_BS11_LMT_LOGIN_TIME, sizeof(bdt), (u_int8_t *) &bdt); msgb_tlv_put(msg, NM_ATT_BS11_LMT_USER_ACC_LEV, - sizeof(bs11_logon_c8), bs11_logon_c8); + 1, &level); msgb_tlv_put(msg, NM_ATT_BS11_LMT_USER_NAME, - sizeof(bs11_logon_c9), bs11_logon_c9); + strlen(name), (u_int8_t *)name); } else { fill_om_fom_hdr(oh, 0, NM_MT_BS11_LMT_LOGOFF, NM_OC_BS11_BTSE, 0xff, 0xff, 0xff); -- 1.6.6 From daniel at totalueberwachung.de Thu Jan 7 02:20:52 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 7 Jan 2010 03:20:52 +0100 Subject: [PATCH 2/5] [abis_nm] Add abis_nm_bs11_infield_logon to logon as user field In-Reply-To: References: Message-ID: <97d821b4097b63f16ed84d73db77434fac64a8fb.1262829786.git.daniel@totalueberwachung.de> As this user you are able to set the PLL work value which is especially useful if your BS11 got detuned by an inaccurate oscillator in your E1 card. --- openbsc/include/openbsc/abis_nm.h | 1 + openbsc/src/abis_nm.c | 5 +++++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/openbsc/include/openbsc/abis_nm.h b/openbsc/include/openbsc/abis_nm.h index 8fe4b0c..9d9b8c1 100644 --- a/openbsc/include/openbsc/abis_nm.h +++ b/openbsc/include/openbsc/abis_nm.h @@ -789,6 +789,7 @@ int abis_nm_bs11_set_trx_power(struct gsm_bts_trx *trx, u_int8_t level); int abis_nm_bs11_get_trx_power(struct gsm_bts_trx *trx); int abis_nm_bs11_logon(struct gsm_bts *bts, u_int8_t level, const char *name, int on); int abis_nm_bs11_factory_logon(struct gsm_bts *bts, int on); +int abis_nm_bs11_infield_logon(struct gsm_bts *bts, int on); int abis_nm_bs11_set_trx1_pw(struct gsm_bts *bts, const char *password); int abis_nm_bs11_set_pll_locked(struct gsm_bts *bts, int locked); int abis_nm_bs11_get_pll_mode(struct gsm_bts *bts); diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 3d337e2..138a134 100644 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -2422,6 +2422,11 @@ int abis_nm_bs11_factory_logon(struct gsm_bts *bts, int on) return abis_nm_bs11_logon(bts, 0x02, "FACTORY", on); } +int abis_nm_bs11_infield_logon(struct gsm_bts *bts, int on) +{ + return abis_nm_bs11_logon(bts, 0x03, "FIELD ", on); +} + int abis_nm_bs11_logon(struct gsm_bts *bts, u_int8_t level, const char *name, int on) { struct abis_om_hdr *oh; -- 1.6.6 From daniel at totalueberwachung.de Thu Jan 7 02:20:53 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 7 Jan 2010 03:20:53 +0100 Subject: [PATCH 3/5] [abis_nm] Add abis_nm_bs11_set_pll function to change the set/work value In-Reply-To: References: Message-ID: <20de3d29051b74ef05d47435780ddd92e1d95111.1262829786.git.daniel@totalueberwachung.de> Whether this function changes the set or the work value depends on your type of login. In FACTORY login it changes the set value, in FIELD login it changes the work value (which is what is used by the BS11 to tune the frequency). --- openbsc/include/openbsc/abis_nm.h | 1 + openbsc/src/abis_nm.c | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/openbsc/include/openbsc/abis_nm.h b/openbsc/include/openbsc/abis_nm.h index 9d9b8c1..d5c7a13 100644 --- a/openbsc/include/openbsc/abis_nm.h +++ b/openbsc/include/openbsc/abis_nm.h @@ -793,6 +793,7 @@ int abis_nm_bs11_infield_logon(struct gsm_bts *bts, int on); int abis_nm_bs11_set_trx1_pw(struct gsm_bts *bts, const char *password); int abis_nm_bs11_set_pll_locked(struct gsm_bts *bts, int locked); int abis_nm_bs11_get_pll_mode(struct gsm_bts *bts); +int abis_nm_bs11_set_pll(struct gsm_bts *bts, int value); int abis_nm_bs11_get_cclk(struct gsm_bts *bts); int abis_nm_bs11_get_state(struct gsm_bts *bts); int abis_nm_bs11_load_swl(struct gsm_bts *bts, const char *fname, diff --git a/openbsc/src/abis_nm.c b/openbsc/src/abis_nm.c index 138a134..311bb3e 100644 --- a/openbsc/src/abis_nm.c +++ b/openbsc/src/abis_nm.c @@ -2494,6 +2494,27 @@ int abis_nm_bs11_set_pll_locked(struct gsm_bts *bts, int locked) return abis_nm_sendmsg(bts, msg); } +/* Set the calibration value of the PLL (work value/set value) + * It depends on the login which one is changed */ +int abis_nm_bs11_set_pll(struct gsm_bts *bts, int value) +{ + struct abis_om_hdr *oh; + struct msgb *msg; + u_int8_t tlv_value[2]; + + msg = nm_msgb_alloc(); + oh = (struct abis_om_hdr *) msgb_put(msg, ABIS_OM_FOM_HDR_SIZE); + fill_om_fom_hdr(oh, 3, NM_MT_BS11_SET_ATTR, NM_OC_BS11, + BS11_OBJ_TRX1, 0x00, 0x00); + + tlv_value[0] = value>>8; + tlv_value[1] = value&0xff; + + msgb_tlv_put(msg, NM_ATT_BS11_PLL, 2, tlv_value); + + return abis_nm_sendmsg(bts, msg); +} + int abis_nm_bs11_get_state(struct gsm_bts *bts) { return __simple_cmd(bts, NM_MT_BS11_GET_STATE); -- 1.6.6 From daniel at totalueberwachung.de Thu Jan 7 02:20:54 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 7 Jan 2010 03:20:54 +0100 Subject: [PATCH 4/5] [bs11_config] Whitespace changes so the help text looks nice In-Reply-To: References: Message-ID: --- openbsc/src/bs11_config.c | 28 ++++++++++++++-------------- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/openbsc/src/bs11_config.c b/openbsc/src/bs11_config.c index b2470a9..3d719bb 100644 --- a/openbsc/src/bs11_config.c +++ b/openbsc/src/bs11_config.c @@ -706,25 +706,25 @@ static void print_help(void) printf("\t-p --port \t\tSpecify serial port\n"); printf("\t-s --software \t\tSpecify Software file\n"); printf("\t-S --safety \t\tSpecify Safety Load file\n"); - printf("\t-d --delay \t\tSpecify delay in milliseconds\n"); + printf("\t-d --delay \t\t\tSpecify delay in milliseconds\n"); printf("\t-D --disconnect\t\t\tDisconnect BTS from BSC\n"); printf("\t-w --win-size \t\tSpecify Window Size\n"); printf("\t-f --forced\t\t\tForce Software Load\n"); printf("\nSupported commands:\n"); - printf("\tquery\t\tQuery the BS-11 about serial number and configuration\n"); - printf("\tdisconnect\tDisconnect A-bis link (go into administrative state)\n"); - printf("\tresconnect\tReconnect A-bis link (go into normal state)\n"); - printf("\trestart\t\tRestart the BTS\n"); - printf("\tsoftware\tDownload Software (only in administrative state)\n"); - printf("\tcreate-trx1\tCreate objects for TRX1 (Danger: Your BS-11 might overheat)\n"); - printf("\tdelete-trx1\tDelete objects for TRX1\n"); - printf("\tpll-e1-locked\tSet the PLL to be locked to E1 clock\n"); - printf("\tpll-standalone\tSet the PLL to be in standalone mode\n"); - printf("\toml-tei\tSet OML E1 TS and TEI\n"); - printf("\tbport0-star\tSet BPORT0 line config to star\n"); + printf("\tquery\t\t\tQuery the BS-11 about serial number and configuration\n"); + printf("\tdisconnect\t\tDisconnect A-bis link (go into administrative state)\n"); + printf("\tresconnect\t\tReconnect A-bis link (go into normal state)\n"); + printf("\trestart\t\t\tRestart the BTS\n"); + printf("\tsoftware\t\tDownload Software (only in administrative state)\n"); + printf("\tcreate-trx1\t\tCreate objects for TRX1 (Danger: Your BS-11 might overheat)\n"); + printf("\tdelete-trx1\t\tDelete objects for TRX1\n"); + printf("\tpll-e1-locked\t\tSet the PLL to be locked to E1 clock\n"); + printf("\tpll-standalone\t\tSet the PLL to be in standalone mode\n"); + printf("\toml-tei\t\t\tSet OML E1 TS and TEI\n"); + printf("\tbport0-star\t\tSet BPORT0 line config to star\n"); printf("\tbport0-multiport\tSet BPORT0 line config to multiport\n"); - printf("\tcreate-bport1\tCreate BPORT1 object\n"); - printf("\tdelete-bport1\tDelete BPORT1 object\n"); + printf("\tcreate-bport1\t\tCreate BPORT1 object\n"); + printf("\tdelete-bport1\t\tDelete BPORT1 object\n"); } static void handle_options(int argc, char **argv) -- 1.6.6 From daniel at totalueberwachung.de Thu Jan 7 02:20:55 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 7 Jan 2010 03:20:55 +0100 Subject: [PATCH 5/5] [bs11_config] Add pll-setvalue and pll-workvalue commands In-Reply-To: References: Message-ID: <600f5cec8413ae5c157a835c5a9cfad57159deb1.1262829786.git.daniel@totalueberwachung.de> These commands let you change the PLL set and work values. Many thanks to Dieter Spaar for figuring out how to do this! Now you can just reset your PLL work value if it drifts away due to your E1 card. Use it like this: bs11_config pll-workvalue 1000 --- openbsc/src/bs11_config.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/openbsc/src/bs11_config.c b/openbsc/src/bs11_config.c index 3d719bb..6a76b96 100644 --- a/openbsc/src/bs11_config.c +++ b/openbsc/src/bs11_config.c @@ -51,7 +51,7 @@ enum bs11cfg_state { STATE_QUERY, }; static enum bs11cfg_state bs11cfg_state = STATE_NONE; -static char *command; +static char *command, *value; struct timer_list status_timer; static const u_int8_t obj_li_attr[] = { @@ -540,6 +540,21 @@ static int handle_state_resp(enum abis_bs11_phase state) sleep(1); abis_nm_bs11_factory_logon(g_bts, 0); command = NULL; + } else if (!strcmp(command, "pll-setvalue")) { + abis_nm_bs11_set_pll(g_bts, atoi(value)); + sleep(1); + abis_nm_bs11_factory_logon(g_bts, 0); + command = NULL; + } else if (!strcmp(command, "pll-workvalue")) { + /* To set the work value we need to login as FIELD */ + abis_nm_bs11_factory_logon(g_bts, 0); + sleep(1); + abis_nm_bs11_infield_logon(g_bts, 1); + sleep(1); + abis_nm_bs11_set_pll(g_bts, atoi(value)); + sleep(1); + abis_nm_bs11_infield_logon(g_bts, 0); + command = NULL; } else if (!strcmp(command, "oml-tei")) { abis_nm_bs11_conn_oml_tei(g_bts, 0, 1, 0xff, TEI_OML); command = NULL; @@ -720,6 +735,8 @@ static void print_help(void) printf("\tdelete-trx1\t\tDelete objects for TRX1\n"); printf("\tpll-e1-locked\t\tSet the PLL to be locked to E1 clock\n"); printf("\tpll-standalone\t\tSet the PLL to be in standalone mode\n"); + printf("\tpll-setvalue \tSet the PLL set value\n"); + printf("\tpll-workvalue \tSet the PLL work value\n"); printf("\toml-tei\t\t\tSet OML E1 TS and TEI\n"); printf("\tbport0-star\t\tSet BPORT0 line config to star\n"); printf("\tbport0-multiport\tSet BPORT0 line config to multiport\n"); @@ -791,6 +808,9 @@ static void handle_options(int argc, char **argv) } if (optind < argc) command = argv[optind]; + if (optind+1 < argc) + value = argv[optind+1]; + } static int num_sigint; -- 1.6.6 From laforge at gnumonks.org Thu Jan 7 09:02:50 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 7 Jan 2010 10:02:50 +0100 Subject: [PATCH 0/5] Change PLL set/work value In-Reply-To: References: Message-ID: <20100107090250.GW1235@prithivi.gnumonks.org> Hi Daniel, On Thu, Jan 07, 2010 at 03:20:50AM +0100, Daniel Willmann wrote: > this list of patches includes support to change the PLL set and work > value with bs11_config. > Many thanks go to Dieter Spaar who figured out how to change the work > value. Yes, indeed! Especially since it's such a subtle difference, i.e. the same command changes its meaning depending on the logon type! > Harald, if these patches are okay for you I'll go ahead and commit them. yes, they're fine, go ahead. You could have also put them in a origin/alphaone/pllvalue branch and I could have merged from there. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From daniel at totalueberwachung.de Thu Jan 7 02:56:36 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Thu, 07 Jan 2010 03:56:36 +0100 Subject: bs11_config showing less info Message-ID: <4B454D64.10203@totalueberwachung.de> Hello, I've noticed that recent versions of bs11_config don't show all the infos they used to. commit eb429b7b44f1c39548a1995cb93484b9cbe2996e Author: Sylvain Munaut Date: Mon Oct 26 20:19:59 2009 +0100 [TLV] Split the parser into 'parse loop' and 'parse single value' seems to be the problem. If I revert it bs11_config query shows more information again. I've looked at the patch, but so far couldn't find out what it does differently. I'll keep looking, but maybe someone else has an idea. Regards, Daniel Willmann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From 246tnt at gmail.com Thu Jan 7 06:39:54 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 7 Jan 2010 07:39:54 +0100 Subject: bs11_config showing less info In-Reply-To: <4B454D64.10203@totalueberwachung.de> References: <4B454D64.10203@totalueberwachung.de> Message-ID: <866320f71001062239m52c4084eg9a2cb9dad164b194@mail.gmail.com> Hi, I've noticed that recent versions of bs11_config don't show all the > infos they used to. > > commit eb429b7b44f1c39548a1995cb93484b9cbe2996e > Author: Sylvain Munaut > Date: Mon Oct 26 20:19:59 2009 +0100 > > [TLV] Split the parser into 'parse loop' and 'parse single value' > > seems to be the problem. If I revert it bs11_config query shows more > information again. I've looked at the patch, but so far couldn't find > out what it does differently. I'll keep looking, but maybe someone else > has an idea. > The way they react to unknown tag is different. (when def->def[tag].typedef->def[tag].type doesn't contain anything valid). Could you post a hex dump of the TLV block where their decoding differs ? Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jan 10 17:05:13 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 10 Jan 2010 18:05:13 +0100 Subject: bs11_config showing less info In-Reply-To: <866320f71001062239m52c4084eg9a2cb9dad164b194@mail.gmail.com> References: <4B454D64.10203@totalueberwachung.de> <866320f71001062239m52c4084eg9a2cb9dad164b194@mail.gmail.com> Message-ID: <20100110170513.GT1235@prithivi.gnumonks.org> Hi Sylvain and Daniel, On Thu, Jan 07, 2010 at 07:39:54AM +0100, Sylvain Munaut wrote: > I've noticed that recent versions of bs11_config don't show all the > > infos they used to. > > > > commit eb429b7b44f1c39548a1995cb93484b9cbe2996e > > Author: Sylvain Munaut > > Date: Mon Oct 26 20:19:59 2009 +0100 > > > > [TLV] Split the parser into 'parse loop' and 'parse single value' > > > > seems to be the problem. If I revert it bs11_config query shows more > > information again. I've looked at the patch, but so far couldn't find > > out what it does differently. I'll keep looking, but maybe someone else > > has an idea. > > The way they react to unknown tag is different. (when > def->def[tag].typedef->def[tag].type doesn't contain anything valid). > > Could you post a hex dump of the TLV block where their decoding differs ? No, it actually is related to the different TLV type of some NM attributes depending on ip.access and BS-11 (such as AVAIL_STATUS). I've fixed this in 39315c47989326275823d1589425ee62d15bc823 and bs11_config query now shows all the data again. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From daniel at totalueberwachung.de Mon Jan 11 10:44:50 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Mon, 11 Jan 2010 11:44:50 +0100 Subject: bs11_config showing less info In-Reply-To: <866320f71001062239m52c4084eg9a2cb9dad164b194@mail.gmail.com> References: <4B454D64.10203@totalueberwachung.de> <866320f71001062239m52c4084eg9a2cb9dad164b194@mail.gmail.com> Message-ID: <4B4B0122.2000501@totalueberwachung.de> Hello, On 01/07/2010 07:39 AM, Sylvain Munaut wrote: > I've noticed that recent versions of bs11_config don't show all the >> infos they used to. > > Could you post a hex dump of the TLV block where their decoding differs ? Harald seems to have fixed it already with commit [39315c4]. Regards, Daniel Willmann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From daniel at totalueberwachung.de Mon Jan 11 13:09:14 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Mon, 11 Jan 2010 14:09:14 +0100 Subject: Commit [39315c4] breaks BTS configuration Message-ID: <4B4B22FA.1060402@totalueberwachung.de> Hello, the commit "[OML] parse attributes depending on BTS type" seems to break bsc_hack completely since it's no longer possible to add a new BTS. This happens because the VTY config sytem first tries to allocate a BTS of type UNKNOWN and later changes that type when the type statement is encountered. I have commited a patch in daniel/fixes that registers a BTS of type unknown so the code should work as before (tested with a BS11). Maybe it is smarter to change the way the gsm_bts_alloc function works instead (so you don't need to provide a type there), I'm not sure about that. Regards, Daniel Willmann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Tue Jan 12 09:45:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 12 Jan 2010 10:45:30 +0100 Subject: Commit [39315c4] breaks BTS configuration In-Reply-To: <4B4B22FA.1060402@totalueberwachung.de> References: <4B4B22FA.1060402@totalueberwachung.de> Message-ID: <20100112094530.GH3781@prithivi.gnumonks.org> On Mon, Jan 11, 2010 at 02:09:14PM +0100, Daniel Willmann wrote: > Hello, > > the commit "[OML] parse attributes depending on BTS type" seems to break > bsc_hack completely since it's no longer possible to add a new BTS. I noticed it and fixed it, but apparently forgot to commit that. Thanks. pushing the fix now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andaluz.coder at gmail.com Wed Jan 13 13:06:02 2010 From: andaluz.coder at gmail.com (Nordin CrazyHacker) Date: Wed, 13 Jan 2010 14:06:02 +0100 Subject: parsing config file problem Message-ID: <1862364f1001130506u326bfe47i1a5ce0cf09b3842a@mail.gmail.com> Hello list, I have a nanobts1800 and installed openbsc on Debian yesterday (from git). After building the project and configured the bts on the network, I executed bsc_hack with -c openbsc.cfg.nanobts. But it failed to execute with the following error: <0005> bsc_init.c:860 Failed to parse the config file: 'openbsc.cfg.nanobts' I haven't modified the config file, I haven't modified anything at all in openbsc. Any idea? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Thu Jan 14 22:33:51 2010 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 15 Jan 2010 01:33:51 +0300 Subject: USSD traces from live networks needed Message-ID: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> Hi all, I'm cross-posting this to both OpenBTS and OpenBSC mailing lists in a hope to get wider audience. Sorry if you get this message twice. Ivan and I are working on USSD support for OpenBTS now. We've got all our test phones working except old Siemens A52 (newer A65 is ok). When we request more information from the phone in order to create menu-like experience, this phone deny processing any further USSD with "NOT EXECUTED" error, while still keeping L3 channel open. This looks quite much like a bug in the phone, but also seems we have a problem in our code too - I tested it with my working SIM card and my normal operator USSD menu and it works. So I kindly ask everyone who have Nokia 3310 with MBUS cable or any other GSM sniffer and have access to live network with working USSD to help us with gathering some real-network data. Please: 1) Call some simple USSD request, which just return a single piece of data. Like "Show my balance" 2) Call some menu-like USSD request and go through several levels of it. On our network we have a kind of "Self-care service" through USSD which works that way. 3) If you know how to summon network-originated USSD request or notification - we will appreciate if you include this too. I have never seen this on my home network, though. 4) Send me your trace. Thanks! -- Regards, Alexander Chemeris. From alexander.chemeris at gmail.com Fri Jan 22 18:37:46 2010 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 22 Jan 2010 21:37:46 +0300 Subject: USSD traces from live networks needed In-Reply-To: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> Message-ID: <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> Hi all, Since no one replied and I'm tired of waiting, we've made our own debug Nokia phone. I gave up searching for a cable and we just soldered cable to the M-BUS pins. We used old data cable for Siemens as a USB-Serial converter, they were PL2303 based. This works like a charm and is a very cheap solution. If you lack special cable for your Nokia - take this way into consideration. To my surprise, latest Wireshark is able to decode everything I need - all USSD messages. I didn't expect this. Many thanks to those who contributed all that code to Wireshark. -- Regards, Alexander Chemeris. From laforge at gnumonks.org Wed Jan 27 11:42:04 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 27 Jan 2010 12:42:04 +0100 Subject: USSD traces from live networks needed In-Reply-To: <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> Message-ID: <20100127114204.GF31353@prithivi.gnumonks.org> On Fri, Jan 22, 2010 at 09:37:46PM +0300, Alexander Chemeris wrote: > Hi all, > > Since no one replied and I'm tired of waiting, we've made our own > debug Nokia phone. I gave up searching for a cable and we just > soldered cable to the M-BUS pins. We used old data cable for > Siemens as a USB-Serial converter, they were PL2303 based. > This works like a charm and is a very cheap solution. If you lack > special cable for your Nokia - take this way into consideration. great to see you're making progress. I would have loved to generate/provide USSD traces, but to be honest I've never seen USSD in use here in Germany... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zecke at selfish.org Wed Jan 27 11:48:12 2010 From: zecke at selfish.org (Holger Freyther) Date: Wed, 27 Jan 2010 12:48:12 +0100 Subject: USSD traces from live networks needed In-Reply-To: <20100127114204.GF31353@prithivi.gnumonks.org> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> Message-ID: <201001271248.13087.zecke@selfish.org> On Wednesday 27 January 2010 12:42:04 Harald Welte wrote: > great to see you're making progress. > > I would have loved to generate/provide USSD traces, but to be honest > I've never seen USSD in use here in Germany... > I think services like balance of Simyo and other prepaid cards are realized with it. From alexander.chemeris at gmail.com Wed Jan 27 16:21:38 2010 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 27 Jan 2010 19:21:38 +0300 Subject: USSD traces from live networks needed In-Reply-To: <201001271248.13087.zecke@selfish.org> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> <201001271248.13087.zecke@selfish.org> Message-ID: <3d032e5d1001270821w47cd50b8u1c250806d4f86f16@mail.gmail.com> Holger, On Wed, Jan 27, 2010 at 14:48, Holger Freyther wrote: > On Wednesday 27 January 2010 12:42:04 Harald Welte wrote: > >> great to see you're making progress. >> >> I would have loved to generate/provide USSD traces, but to be honest >> I've never seen USSD in use here in Germany... >> > > I think services like balance of Simyo and other prepaid cards are realized > with it. Very probably. Balance check is by far the most popular USSD request here too, usually looking like *100#. USSD menu here can be invoked by *111# for all three operators. -- Regards, Alexander Chemeris. From dburgess at jcis.net Wed Jan 27 17:50:51 2010 From: dburgess at jcis.net (David A. Burgess) Date: Wed, 27 Jan 2010 09:50:51 -0800 Subject: USSD traces from live networks needed In-Reply-To: <3d032e5d1001270821w47cd50b8u1c250806d4f86f16@mail.gmail.com> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> <201001271248.13087.zecke@selfish.org> <3d032e5d1001270821w47cd50b8u1c250806d4f86f16@mail.gmail.com> Message-ID: <6997DED9-12AD-4F3E-A98E-914BFF6A5B1C@jcis.net> This is how balance checking works on Blau, also. I'd try *111# but I'm out of credits and can't buy e-Plus cards in the US. Remember also that USSD applications live in the SIM's home network, not in the local carrier's network. If a carrier uses USSD for account management, the USSD features should work the same way anywhere in the world. On Jan 27, 2010, at 8:21 AM, Alexander Chemeris wrote: > > Very probably. > Balance check is by far the most popular USSD request here too, > usually > looking like *100#. USSD menu here can be invoked by *111# for all > three > operators. > > -- > Regards, > Alexander Chemeris. David A. Burgess Kestrel Signal Processing, Inc. From alexander.chemeris at gmail.com Wed Jan 27 17:58:18 2010 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 27 Jan 2010 20:58:18 +0300 Subject: USSD traces from live networks needed In-Reply-To: <6997DED9-12AD-4F3E-A98E-914BFF6A5B1C@jcis.net> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> <201001271248.13087.zecke@selfish.org> <3d032e5d1001270821w47cd50b8u1c250806d4f86f16@mail.gmail.com> <6997DED9-12AD-4F3E-A98E-914BFF6A5B1C@jcis.net> Message-ID: <3d032e5d1001270958r5d562ec4q972ba717f3cb0822@mail.gmail.com> David, On Wed, Jan 27, 2010 at 20:50, David A. Burgess wrote: > Remember also that USSD applications live in the SIM's home network, not in > the local carrier's network. ?If a carrier uses USSD for account management, > the USSD features should work the same way anywhere in the world. Not exactly. There is a range of numbers which should be forwarded to your HPLMN, while others are to be processed by your roaming operator. IIRC, all 1xx should be forwarded to HPLMN. That's why it is used for balance checking, etc. -- Regards, Alexander Chemeris. From js-openbsc at webkeks.org Wed Jan 27 20:33:40 2010 From: js-openbsc at webkeks.org (Jonathan Schleifer) Date: Wed, 27 Jan 2010 21:33:40 +0100 Subject: USSD traces from live networks needed In-Reply-To: <6997DED9-12AD-4F3E-A98E-914BFF6A5B1C@jcis.net> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> <201001271248.13087.zecke@selfish.org> <3d032e5d1001270821w47cd50b8u1c250806d4f86f16@mail.gmail.com> <6997DED9-12AD-4F3E-A98E-914BFF6A5B1C@jcis.net> Message-ID: <7E8C565A-9B89-405B-81E9-8618A6E70526@webkeks.org> Am 27.01.2010 um 18:50 schrieb David A. Burgess: > This is how balance checking works on Blau, also. I'd try *111# but > I'm out of credits and can't buy e-Plus cards in the US. O2 even offers a full menu with response-possibility if you use *100#. Balance is *101#, but you can also use *100# and choose 1 then. It also allows you do send full texts etc back where necessary. -- Jonathan From alexander.chemeris at gmail.com Wed Jan 27 21:18:07 2010 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 28 Jan 2010 00:18:07 +0300 Subject: USSD traces from live networks needed In-Reply-To: <7E8C565A-9B89-405B-81E9-8618A6E70526@webkeks.org> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> <201001271248.13087.zecke@selfish.org> <3d032e5d1001270821w47cd50b8u1c250806d4f86f16@mail.gmail.com> <6997DED9-12AD-4F3E-A98E-914BFF6A5B1C@jcis.net> <7E8C565A-9B89-405B-81E9-8618A6E70526@webkeks.org> Message-ID: <3d032e5d1001271318te6c638i7d807b2fcea441c6@mail.gmail.com> Hi, On Wed, Jan 27, 2010 at 23:33, Jonathan Schleifer wrote: > Am 27.01.2010 um 18:50 schrieb David A. Burgess: > >> This is how balance checking works on Blau, also. ?I'd try *111# but I'm >> out of credits and can't buy e-Plus cards in the US. > > O2 even offers a full menu with response-possibility if you use *100#. > Balance is *101#, but you can also use *100# and choose 1 then. It also > allows you do send full texts etc back where necessary. Aha, Harald, I know you should have o2 SIM ;) Could you, please, generate some traces with *101# and then with walking through *100# menu, with normal finish (like after you receive balance info) and with MO release (press C on 3310 to break connection manually). Jonathan, thank you for information! -- Regards, Alexander Chemeris. From alexander.chemeris at gmail.com Wed Jan 27 16:19:37 2010 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 27 Jan 2010 19:19:37 +0300 Subject: USSD traces from live networks needed In-Reply-To: <20100127114204.GF31353@prithivi.gnumonks.org> References: <3d032e5d1001141433n7d1bf94dgb25a9522ba2b5392@mail.gmail.com> <3d032e5d1001221037s5c75bda8uc203013b712f8e00@mail.gmail.com> <20100127114204.GF31353@prithivi.gnumonks.org> Message-ID: <3d032e5d1001270819u127bf55id71ff5279c56f5bb@mail.gmail.com> Harald, On Wed, Jan 27, 2010 at 14:42, Harald Welte wrote: > On Fri, Jan 22, 2010 at 09:37:46PM +0300, Alexander Chemeris wrote: >> Hi all, >> >> Since no one ?replied and I'm tired of waiting, we've made our own >> debug Nokia phone. I gave up searching for a cable and we just >> soldered cable to the M-BUS pins. We used old data cable for >> Siemens as a USB-Serial converter, they were PL2303 based. >> This works like a charm and is a very cheap solution. If you lack >> special cable for your Nokia - take this way into consideration. > > great to see you're making progress. > > I would have loved to generate/provide USSD traces, but to be honest > I've never seen USSD in use here in Germany... Interesting why - USSD is a convenient technology for self-care and VAS. All three Russian mobile operators engage it. Web-site based self-care has more features, but USSD is very convenient when you don't have internet access or need to switch some feature on/off quickly. Btw I found that all three operators implement USSD menu as MT-USSD, while we where trying to implement it vice versa. Probably this is to circumvent buggy MO-USSD in old phones like Siemens A52 I have. But from the Standard point of view this is surprisingly non-obvious way. I think I can upload captured traces somewhere if someone wants to look at them. -- Regards, Alexander Chemeris. From Andreas.Eversberg at versatel.de Sat Jan 16 11:08:23 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Sat, 16 Jan 2010 12:08:23 +0100 Subject: maybe there is an select problem Message-ID: hi, while porting the select.c to LCR, i found the problem: the unix select function returns a set of file descriptors to be handled. the result-loop (the loop after the select()) is called again, if more than one descriptor is removed by the callback funtion. this may lead to a another call to the callback function, because the bits of the FD_SETs do not change and still set. i think we must clear these bits, if they are handled, so the handler will not be called twice in case of a "restart" of that loop. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: select_question.patch Type: application/octet-stream Size: 702 bytes Desc: select_question.patch URL: From laforge at gnumonks.org Sat Jan 23 09:51:26 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 23 Jan 2010 10:51:26 +0100 Subject: maybe there is an select problem In-Reply-To: References: Message-ID: <20100123095126.GP19781@prithivi.gnumonks.org> Hi Andreas, sorry for the late response, I'm mostly busy with hacking phones right now ;) > the unix select function returns a set of file descriptors to be > handled. the result-loop (the loop after the select()) is called again, > if more than one descriptor is removed by the callback funtion. this may > lead to a another call to the callback function, because the bits of the > FD_SETs do not change and still set. > > i think we must clear these bits, if they are handled, so the handler > will not be called twice in case of a "restart" of that loop. You are absolutely right. Thanks for spotting this! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Wed Jan 20 08:30:17 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 20 Jan 2010 09:30:17 +0100 Subject: phone without encryption Message-ID: hi, some stupid question: if a phone does not support any encryption, is it possible to use it on an official GSM network? (authentication works, of course) if so, what phone might it be? regards andreas Mit freundlichen Gr??en, .-. /'v'\ (/ \) ------------------------------------------------------------------"-"- |_| i.A. Andreas Eversberg Network Operations / 2nd Level Data - KC Internet Versatel Nord GmbH Nordstr. 2 D-24937 Flensburg Fon: +49-461-9099749 | Fax: +49-461-909960749 andreas.eversberg at versatel.de@versatel.de | www.versatel.de Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL Gesch?ftsf?hrer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjoshi.big at gmail.com Wed Jan 20 08:49:54 2010 From: rjoshi.big at gmail.com (Rohit Joshi) Date: Wed, 20 Jan 2010 14:19:54 +0530 Subject: phone without encryption In-Reply-To: References: Message-ID: As far as I know it depends upon the network settings enforcing if unciphered calls or data transfers are allowed or not. I think few countries (including India) used to mandate the operators to negotiate null ciphering algorithm that is no ciphering - I verified this about 2 to 3 years back where my local network in bangalore was not turning on ciphering, however I am not aware of the current status. Regards --Rohit On Wed, Jan 20, 2010 at 2:00 PM, Andreas.Eversberg < Andreas.Eversberg at versatel.de> wrote: > > hi, > > some stupid question: if a phone does not support any encryption, is it > possible to use it on an official GSM network? (authentication works, of > course) if so, what phone might it be? > > regards > > andreas > > > > > Mit freundlichen Gr??en, > > .-. > /'v'\ > (/ \) > ------------------------------------------------------------------"-"? > |_| > i.A. Andreas Eversberg > Network Operations / 2nd Level Data - KC Internet > > Versatel Nord GmbH > > Nordstr. 2 > D-24937 Flensburg > > Fon: +49-461-9099749 | Fax: +49-461-909960749 > andreas.eversberg at versatel.de@versatel.de | www.versatel.de > > Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL > Gesch?ftsf?hrer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven > > -- Coding Universe! -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Thu Jan 21 12:12:38 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 21 Jan 2010 12:12:38 Subject: phone without encryption Message-ID: <4b5844b6.mirider@mirider.augusta.de> Hello Andreas, On Wed, 20 Jan 2010 09:30:17 +0100, "Andreas.Eversberg" wrote: > > some stupid question: if a phone does not support any encryption, is it > possible to use it on an official GSM network? (authentication works, of > course) if so, what phone might it be? I did a quick check, at least Vodafone and T-Mobile here in Germany reject the Location Update Request with "Network Failure" (0x11) if they get a classmark without any encryption available. The registration works with the same phone if the classmark indicates that encryption support is available. The test was done with a phone where I can modify the classmark data. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From keytwo at gmail.com Mon Jan 25 21:14:02 2010 From: keytwo at gmail.com (K2) Date: Mon, 25 Jan 2010 22:14:02 +0100 Subject: adding an input to openbsc Message-ID: <6caff53e1001251314p55cd0b24o3819b26597d242a@mail.gmail.com> Hi What needs to be changed in openbsc in order to add a new input ? I'm currently developing a GAN protocol stack, and would like to add it to openbsc so it could deal with the DTAP msg coming from GAN regards, -- k2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Tue Jan 26 01:36:06 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 26 Jan 2010 02:36:06 +0100 Subject: adding an input to openbsc In-Reply-To: <6caff53e1001251314p55cd0b24o3819b26597d242a@mail.gmail.com> References: <6caff53e1001251314p55cd0b24o3819b26597d242a@mail.gmail.com> Message-ID: <201001260236.07184.zecke@selfish.org> On Monday 25 January 2010 22:14:02 K2 wrote: > Hi > What needs to be changed in openbsc in order to add a new input ? > I'm currently developing a GAN protocol stack, and would like to add it to > openbsc so it could deal with the DTAP msg coming from GAN. Until now I have not heard about GAN. You will find a src/bssap.c in the on- waves/bsc-master branch. This class is capable of decoding a couple of GSM 08.08 messages (including DTAP). Currently it might be a bit too tied to the On Waves bsc_master_ip.c file but that can be changed. z. From philippe.mailinglist at gmail.com Tue Jan 26 02:53:57 2010 From: philippe.mailinglist at gmail.com (Philippe Mailinglist) Date: Tue, 26 Jan 2010 09:53:57 +0700 Subject: adding an input to openbsc In-Reply-To: <201001260236.07184.zecke@selfish.org> References: <6caff53e1001251314p55cd0b24o3819b26597d242a@mail.gmail.com> <201001260236.07184.zecke@selfish.org> Message-ID: GAN = Generic Access Network = UMA http://en.wikipedia.org/wiki/Generic_Access_Network On 26 Jan 2010, at 08:36, Holger Freyther wrote: > On Monday 25 January 2010 22:14:02 K2 wrote: >> Hi >> What needs to be changed in openbsc in order to add a new input ? >> I'm currently developing a GAN protocol stack, and would like to >> add it to >> openbsc so it could deal with the DTAP msg coming from GAN. > > Until now I have not heard about GAN. You will find a src/bssap.c > in the on- > waves/bsc-master branch. This class is capable of decoding a couple > of GSM > 08.08 messages (including DTAP). Currently it might be a bit too > tied to the > On Waves bsc_master_ip.c file but that can be changed. > > z. > > > -- Philippe Langlois Email: Philippe.Langlois at Gmail.com PGP Key: 8DAEE244 From keytwo at gmail.com Tue Jan 26 09:13:14 2010 From: keytwo at gmail.com (K2) Date: Tue, 26 Jan 2010 10:13:14 +0100 Subject: adding an input to openbsc In-Reply-To: References: <6caff53e1001251314p55cd0b24o3819b26597d242a@mail.gmail.com> <201001260236.07184.zecke@selfish.org> Message-ID: <6caff53e1001260113r5f9b1f86kf0ffab1f395957f4@mail.gmail.com> Yep, GAN = UMA. I saw that some femto uses it. it mainly encapsulate the L3 messages. So I wanted to be able to decapsulate them, and send them to openbsc in order to get them handled... any clue on how to do that ? I could provide some pcap if that helps On Tue, Jan 26, 2010 at 3:53 AM, Philippe Mailinglist < philippe.mailinglist at gmail.com> wrote: > GAN = Generic Access Network = UMA > > http://en.wikipedia.org/wiki/Generic_Access_Network > > > > On 26 Jan 2010, at 08:36, Holger Freyther wrote: > >> On Monday 25 January 2010 22:14:02 K2 wrote: >> >>> Hi >>> What needs to be changed in openbsc in order to add a new input ? >>> I'm currently developing a GAN protocol stack, and would like to add it >>> to >>> openbsc so it could deal with the DTAP msg coming from GAN. >>> >> >> Until now I have not heard about GAN. You will find a src/bssap.c in the >> on- >> waves/bsc-master branch. This class is capable of decoding a couple of GSM >> 08.08 messages (including DTAP). Currently it might be a bit too tied to >> the >> On Waves bsc_master_ip.c file but that can be changed. >> >> z. >> >> >> >> > -- > Philippe Langlois > Email: Philippe.Langlois at Gmail.com > PGP Key: 8DAEE244 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carcellelist at free.fr Wed Jan 27 09:08:23 2010 From: carcellelist at free.fr (Carcellelist) Date: Wed, 27 Jan 2010 10:08:23 +0100 Subject: Patch/Driver for Sangoma E1 interface ? Message-ID: <201001271008.23648.carcellelist@free.fr> Hi there, Has anyone been working on using OpenBSC with a Sangoma E1 card connected to the BTS ? I guess they would be some patches to add to the generic driver to have it fully working and recognized within the OpenBSC framework ? The last thread I saw related to Sangoma was from Oystein : http://lists.gnumonks.org/pipermail/openbsc/2009-August/000821.html Cheers, Xavier. From zecke at selfish.org Thu Jan 28 09:34:11 2010 From: zecke at selfish.org (Holger Freyther) Date: Thu, 28 Jan 2010 10:34:11 +0100 Subject: RSL "Channel Release" Sequence Message-ID: <201001281034.12115.zecke@selfish.org> Hi, I'm currently implementing Early Assignment in the On Waves branch and as part of this I will have to take care of RSL channel releases as well. Someone else was pointing this out as well but I could not find the email. Our channel release is a bit sloppy and I will fix it and start using T3111 and T3109 in the rsl code for doing so. In the "normal" case (bsc on the left, bts on the right): RSL Channel Release --> <- RSL Channel Release Ack <- Release Indication SAPI=0 RSL Channel Release -> <- RSL Channel Release Ack In the "abnormal" case: <- Error Indication RSL Channel Release -> <- RSL Channel Release Ack <- Release Indication SAPI=0 RSL Channel Release -> <- RSL Channel Release Ack I'm going to change that into the following way. "normal" case: 1.) Release the established SAPIs 2.) After their ACKs release the Channel Have all this guarded by T3109 (or whatever is more appropriate) "abnormal" case: 1.) Start T3109 2.) Then do the normal case. During the shutdown sequence I need to make sure that we are not allocating the channel again. I'm thinking of either using the chan mode Harald was introducing while doing the hand over work, or just a "locked" flag to not assign the channel. I hope to be done with this by tomorrow or the day after, anyone has comments or ideas on how to approach this? z.