From openbsc at wehrle.it Fri Apr 1 12:35:07 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Fri, 01 Apr 2011 14:35:07 +0200 Subject: sms bugfix In-Reply-To: <4D945FB3.5090905@freyther.de> References: <4D83D64B.30500@wehrle.it> <4D83FEE2.3070703@freyther.de> <4D873E8B.5050905@wehrle.it> <4D8886F4.1070600@gnumonks.org> <4D88E074.7090501@wehrle.it> <4D945FB3.5090905@freyther.de> Message-ID: <4D95C67B.2030905@wehrle.it> On 31.03.2011 13:04, Holger Hans Peter Freyther wrote: > Hi Dennis, > > sorry for the delay and thanks a lot for your patch. Do you feel like adding a > test case to the libosmocore/tests/sms/sms_test.c? > > thanks a lot > holger > Hi Holger No Problem. See attach for the new sms_lib.patch Best regards Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: sms_lib.patch Type: text/x-patch Size: 10116 bytes Desc: not available URL: From pablo at gnumonks.org Fri Apr 1 12:53:22 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 01 Apr 2011 14:53:22 +0200 Subject: sms bugfix In-Reply-To: <4D95C67B.2030905@wehrle.it> References: <4D83D64B.30500@wehrle.it> <4D83FEE2.3070703@freyther.de> <4D873E8B.5050905@wehrle.it> <4D8886F4.1070600@gnumonks.org> <4D88E074.7090501@wehrle.it> <4D945FB3.5090905@freyther.de> <4D95C67B.2030905@wehrle.it> Message-ID: <4D95CAC2.70005@gnumonks.org> On 01/04/11 14:35, Dennis Wehrle wrote: > On 31.03.2011 13:04, Holger Hans Peter Freyther wrote: >> Hi Dennis, >> >> sorry for the delay and thanks a lot for your patch. Do you feel like >> adding a >> test case to the libosmocore/tests/sms/sms_test.c? >> >> thanks a lot >> holger >> > Hi Holger > > No Problem. See attach for the new sms_lib.patch > > diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h > index 0aadd2e..a47ce7b 100644 > --- a/include/osmocore/gsm_utils.h > +++ b/include/osmocore/gsm_utils.h I'm sorry, but this won't apply to current libosmocore git tree (we have applied several patches to rework the header files directories). would you rework it upon current git libosmocore tree? Thanks! From openbsc at wehrle.it Fri Apr 1 16:27:57 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Fri, 01 Apr 2011 18:27:57 +0200 Subject: sms bugfix In-Reply-To: <4D95CAC2.70005@gnumonks.org> References: <4D83D64B.30500@wehrle.it> <4D83FEE2.3070703@freyther.de> <4D873E8B.5050905@wehrle.it> <4D8886F4.1070600@gnumonks.org> <4D88E074.7090501@wehrle.it> <4D945FB3.5090905@freyther.de> <4D95C67B.2030905@wehrle.it> <4D95CAC2.70005@gnumonks.org> Message-ID: <4D95FD0D.3020305@wehrle.it> Hi Pablo Thx for your answer. I have updated to the newest version, created the patch and tested it. But i have found another bug. Therefore i want to wait until i have fix this bug (next week). It is really strange....: working: Sent a SMS with 167 chars from Nokia 3310 to iPhone. not working: Sent the same message from iPhone to Nokia 3310. The differences are: Nokia: message identifier = 199, user-data-length part1 = 160, part2 = 31 iPhone: message identifier = 11, user-data-length part1 = 161, part2 = 33; part1 is retransmitted 5 times.... Best Regards and a nice weekend Dennis Wehrle On 01.04.2011 14:53, Pablo Neira Ayuso wrote: > On 01/04/11 14:35, Dennis Wehrle wrote: >> On 31.03.2011 13:04, Holger Hans Peter Freyther wrote: >>> Hi Dennis, >>> >>> sorry for the delay and thanks a lot for your patch. Do you feel like >>> adding a >>> test case to the libosmocore/tests/sms/sms_test.c? >>> >>> thanks a lot >>> holger >>> >> Hi Holger >> >> No Problem. See attach for the new sms_lib.patch >> >> diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h >> index 0aadd2e..a47ce7b 100644 >> --- a/include/osmocore/gsm_utils.h >> +++ b/include/osmocore/gsm_utils.h > I'm sorry, but this won't apply to current libosmocore git tree (we have > applied several patches to rework the header files directories). > > would you rework it upon current git libosmocore tree? > > Thanks! > From openbsc at wehrle.it Mon Apr 4 15:27:57 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Mon, 04 Apr 2011 17:27:57 +0200 Subject: sms bugfix In-Reply-To: <4D83D64B.30500@wehrle.it> References: <4D83D64B.30500@wehrle.it> Message-ID: <4D99E37D.8070006@wehrle.it> Hello As said last Friday i have inspected the following bug: SMS with more than 160 chars from Nokia 3310 to iPhone works, but not the other way around. It turns out, that once more the user_data_len is the problem. The problem is, that if we sent more than 160 chars a header with some information (user data header length, information element identifier, length, message identifier, message parts, message part number, fill bits) will be transmitted within the user_data. This is a problem because in my gsm_get_septet_len function i take the text-field from the database and count every extension character twice. In this special case it is possible that parts of the header data will be interpretet (decoded) as a extension character (in my case a pipe |). Therefore my function returns the wrong number of septets. The best solution for that is to store the number of septets at the database (on the decoding process). Therefore i want to discuss if this is a suitable solution. If we don't want to change the structure of the database i could possible make a dirty hack (look if the "ud_hdr_ind" is set, get the "user data header length" (udhl) from the user_data, count the number of septets from "text - 1 - udhl - fill bits"). But i strongly recommend to change the database (i could do it). Best Regards Dennis Wehrle From holger at freyther.de Sun Apr 17 08:53:03 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 17 Apr 2011 10:53:03 +0200 Subject: sms bugfix In-Reply-To: <4D99E37D.8070006@wehrle.it> References: <4D83D64B.30500@wehrle.it> <4D99E37D.8070006@wehrle.it> Message-ID: <4DAAAA6F.4050601@freyther.de> On 04/04/2011 05:27 PM, Dennis Wehrle wrote: > Hello Hi Dennis, sorry for the delay. I had hoped someone with more SMS knowledge pops up and takes a look. I have mostly fixed issues with the code itself (timesouts, leaks, etc) but not really used it. > The best solution for that is to store the number of septets at the database > (on the decoding process). Therefore i want to discuss if this is a suitable > solution. If we don't want to change the structure of the database i could > possible make a dirty hack (look if the "ud_hdr_ind" is set, get the "user > data header length" (udhl) from the user_data, count the number of septets > from "text - 1 - udhl - fill bits"). > But i strongly recommend to change the database (i could do it). Yes, please change the database. I think you want to increase the version of the database schema but I would not worry about having a migration inside the db.c code itself (we can have a script to update the schema and drop the SMS table..). From openbsc at ngolde.de Sun Apr 17 18:06:54 2011 From: openbsc at ngolde.de (Nico Golde) Date: Sun, 17 Apr 2011 20:06:54 +0200 Subject: sms bugfix In-Reply-To: <4DAAAA6F.4050601@freyther.de> References: <4D83D64B.30500@wehrle.it> <4D99E37D.8070006@wehrle.it> <4DAAAA6F.4050601@freyther.de> Message-ID: <20110417180654.GB17891@segfault.binarybase.org> Hi, * Holger Hans Peter Freyther [2011-04-17 19:00]: > On 04/04/2011 05:27 PM, Dennis Wehrle wrote: [...] FWIW, your original patch and motivation also looks very reasonable to me! > > The best solution for that is to store the number of septets at the database > > (on the decoding process). Therefore i want to discuss if this is a suitable > > solution. If we don't want to change the structure of the database i could > > possible make a dirty hack (look if the "ud_hdr_ind" is set, get the "user > > data header length" (udhl) from the user_data, count the number of septets > > from "text - 1 - udhl - fill bits"). > > But i strongly recommend to change the database (i could do it). > > Yes, please change the database. I think you want to increase the version of > the database schema but I would not worry about having a migration inside the > db.c code itself (we can have a script to update the schema and drop the SMS > table..). Imho the current database scheme for SMS is rather suboptimal in general because it attempts to mix incomplete sms encoding values with decoded user data. As we have to properly encode the message anyway when sending from the vty it seems only reasonable to me to store UDL in the db as well. This way it is very easy to do the decoding/encoding step with the already present data_coding_scheme value. But thinking more about this... does it really make sense to store anything but control data and the actual PDU in the database? When sending a message from the vty the message is encoded anyway, so just inserting the PDU + control data should be sufficient. I'm not sure if OpenBSC has to be aware of things like UDHI, UDH, PID and thelike. The only place where this is useful so far is for the debugging output. But what about moving this decoding for mere visual purposes to libosmocore completely and not store this information in the database at all? Cheers Nico P.S. attached is a submit decoder I used in the past one could use as a basis for the proposed libosmocore function. -------------- next part -------------- A non-text attachment was scrubbed... Name: decode_submit.c Type: text/x-csrc Size: 6104 bytes Desc: not available URL: From laforge at gnumonks.org Sun Apr 17 18:43:25 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 17 Apr 2011 20:43:25 +0200 Subject: sms bugfix In-Reply-To: <20110417180654.GB17891@segfault.binarybase.org> References: <4D83D64B.30500@wehrle.it> <4D99E37D.8070006@wehrle.it> <4DAAAA6F.4050601@freyther.de> <20110417180654.GB17891@segfault.binarybase.org> Message-ID: <20110417184325.GK9379@prithivi.gnumonks.org> Hi Nico, On Sun, Apr 17, 2011 at 08:06:54PM +0200, Nico Golde wrote: > But thinking more about this... does it really make sense to store > anything but control data and the actual PDU in the database? When sending > a message from the vty the message is encoded anyway, so just inserting > the PDU + control data should be sufficient. I'm not sure if OpenBSC has > to be aware of things like UDHI, UDH, PID and thelike. well, what you definitely want aside from the PDU is 'valid_until', which is a result of PDU parsing... But yes, generally, * there should be no decoded SMS in the database (and if it is, only for debugging, i.e. no code should ever use the human-readable decode * there should be no direct references to the subscriber table (sender_id/receiver_id). Rather, the actual phone number (MSISDN) should be used. -- - 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 Tue Apr 19 10:24:17 2011 From: openbsc at wehrle.it (Dennis Wehrle) Date: Tue, 19 Apr 2011 12:24:17 +0200 Subject: sms bugfix In-Reply-To: <4DAAAA6F.4050601@freyther.de> References: <4D83D64B.30500@wehrle.it> <4D99E37D.8070006@wehrle.it> <4DAAAA6F.4050601@freyther.de> Message-ID: <4DAD62D1.10201@wehrle.it> Hi Holger wrote: > Yes, please change the database. I think you want to increase the version of > the database schema but I would not worry about having a migration inside the > db.c code itself (we can have a script to update the schema and drop the SMS > table..). Ok, sounds good. But unfortunally i have no time for the next 2 weeks. Nico wrote: > Imho the current database scheme for SMS is rather suboptimal in general > because it attempts to mix incomplete sms encoding values with decoded > user data. As we have to properly encode the message anyway when sending > from the vty it seems only reasonable to me to store UDL in the db as well. > This way it is very easy to do the decoding/encoding step with the already > present data_coding_scheme value. > > But thinking more about this... does it really make sense to store > anything but control data and the actual PDU in the database? When sending > a message from the vty the message is encoded anyway, so just inserting > the PDU + control data should be sufficient. I'm not sure if OpenBSC has > to be aware of things like UDHI, UDH, PID and thelike. > > The only place where this is useful so far is for the debugging output. > But what about moving this decoding for mere visual purposes to > libosmocore completely and not store this information in the database at > all? > > Cheers > Nico > P.S. attached is a submit decoder I used in the past one > could use as a basis for the proposed libosmocore function. Thx for your explanatory notes. And thx for your code. I will see how i can use it. Harald wrote: > well, what you definitely want aside from the PDU is 'valid_until', which is a > result of PDU parsing... > > But yes, generally, > * there should be no decoded SMS in the database (and if it is, only for > debugging, i.e. no code should ever use the human-readable decode > * there should be no direct references to the subscriber table > (sender_id/receiver_id). Rather, the actual phone number (MSISDN) should > be used. I will keep this in mind. Best Regards Dennis From laforge at gnumonks.org Fri Apr 8 12:06:41 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 8 Apr 2011 14:06:41 +0200 Subject: [PATCH] wireshark: update extension of RSL dissector with ip.access nanoBTS support In-Reply-To: <1301573108-9518-2-git-send-email-pablo@gnumonks.org> References: <1301573108-9518-1-git-send-email-pablo@gnumonks.org> <1301573108-9518-2-git-send-email-pablo@gnumonks.org> Message-ID: <20110408120641.GK790@prithivi.gnumonks.org> Hi Pablo, On Thu, Mar 31, 2011 at 02:05:08PM +0200, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > This patch removes the C99 structure initialization which is not allowed > by the wireshark project (since it has to compile with non-C99 compliant > compilers). Thanks, I've applied it to the tree, it's not on the public git yet, as I'm currently offline at a legal conference. 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 Sun Apr 10 11:50:27 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 10 Apr 2011 13:50:27 +0200 Subject: [PATCH] wireshark: update extension of RSL dissector with ip.access nanoBTS support In-Reply-To: <20110408120641.GK790@prithivi.gnumonks.org> References: <1301573108-9518-1-git-send-email-pablo@gnumonks.org> <1301573108-9518-2-git-send-email-pablo@gnumonks.org> <20110408120641.GK790@prithivi.gnumonks.org> Message-ID: <4DA19983.1050202@gnumonks.org> On 08/04/11 14:06, Harald Welte wrote: > Hi Pablo, > > On Thu, Mar 31, 2011 at 02:05:08PM +0200, pablo at gnumonks.org wrote: >> From: Pablo Neira Ayuso >> >> This patch removes the C99 structure initialization which is not allowed >> by the wireshark project (since it has to compile with non-C99 compliant >> compilers). > > Thanks, I've applied it to the tree, it's not on the public git yet, as > I'm currently offline at a legal conference. Should I submit it to wireshark? From laforge at gnumonks.org Sun Apr 10 14:51:20 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 10 Apr 2011 16:51:20 +0200 Subject: [PATCH] wireshark: update extension of RSL dissector with ip.access nanoBTS support In-Reply-To: <4DA19983.1050202@gnumonks.org> References: <1301573108-9518-1-git-send-email-pablo@gnumonks.org> <1301573108-9518-2-git-send-email-pablo@gnumonks.org> <20110408120641.GK790@prithivi.gnumonks.org> <4DA19983.1050202@gnumonks.org> Message-ID: <20110410145120.GE9690@prithivi.gnumonks.org> On Sun, Apr 10, 2011 at 01:50:27PM +0200, Pablo Neira Ayuso wrote: > On 08/04/11 14:06, Harald Welte wrote: > > Hi Pablo, > > > > On Thu, Mar 31, 2011 at 02:05:08PM +0200, pablo at gnumonks.org wrote: > >> From: Pablo Neira Ayuso > >> > >> This patch removes the C99 structure initialization which is not allowed > >> by the wireshark project (since it has to compile with non-C99 compliant > >> compilers). > > > > Thanks, I've applied it to the tree, it's not on the public git yet, as > > I'm currently offline at a legal conference. > > Should I submit it to wireshark? sure, go ahead! also, it might be good to check regarding the tetra dissector status, I have the feeling nobody has reviewed it so far... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Mon Apr 11 11:45:36 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 11 Apr 2011 13:45:36 +0200 Subject: [PATCH] wireshark: update extension of RSL dissector with ip.access nanoBTS support In-Reply-To: <20110410145120.GE9690@prithivi.gnumonks.org> References: <1301573108-9518-1-git-send-email-pablo@gnumonks.org> <1301573108-9518-2-git-send-email-pablo@gnumonks.org> <20110408120641.GK790@prithivi.gnumonks.org> <4DA19983.1050202@gnumonks.org> <20110410145120.GE9690@prithivi.gnumonks.org> Message-ID: <4DA2E9E0.1060003@freyther.de> On 04/10/2011 04:51 PM, Harald Welte wrote: > sure, go ahead! also, it might be good to check regarding the tetra dissector > status, I have the feeling nobody has reviewed it so far... > tetra is fully merged or are there some other patches pending? From kobayashi_maru at onlinehome.de Mon Apr 4 06:49:40 2011 From: kobayashi_maru at onlinehome.de (Thomas Ansorg) Date: Mon, 4 Apr 2011 08:49:40 +0200 Subject: rectangular signals on rx-ports Message-ID: hello what are the rectangular signals on the bs11 rx-ports? and what if the signal has ripples on unconnected bs11? T. From kobayashi_maru at onlinehome.de Mon Apr 4 08:09:18 2011 From: kobayashi_maru at onlinehome.de (Thomas Ansorg) Date: Mon, 4 Apr 2011 10:09:18 +0200 Subject: instruction manual for bs11 Message-ID: <5C20AA4070604EB5A7A8D49E2EA975BD@fa0nw29vid23km> hello is any instruction manual available? I need one. you may also send me a rs-link, if you think e-mail is too insecure T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertoncello at netzing.de Mon Apr 4 12:03:45 2011 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 4 Apr 2011 14:03:45 +0200 Subject: Help understanding used power Message-ID: <20110404140345.2fd53a51@Luca> Hi, list! I'm trying to understand how the options "nominal power" and "max_power_red" work... Last Friday I tried to place 4 BTS in a rectangle of about 100x20 meter and then I examined the measurement reports of a mobile. They are very very bad, and oft it cannot see a cell. Then I tried to change the value of "nominal power" (max_power_red did not changed) and retry to check the measurement reports. No changes... :( Now I'm here in my office with a spectrum analyzer and try to change these values, but what I see in the spectrum analyzer is always the same... I restart OpenBSC after any change, of course! Could you please help me to understand what these values mean and how can I boost the signal? Thanks a lot in advance for your help! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fr?belstr. 57, 01159 Dresden Fax: 0351/41381 - 12 _______________________________________________________________________ Impressum: NETZING Solutions AG - Fr?belstra?e 57 - 01159 Dresden Sitz der Gesellschaft Amtsgericht Dresden HRB 18926 Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz USt.Id DE211326547 Mail: netzing.ag at netzing.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Mon Apr 4 12:28:52 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Mon, 04 Apr 2011 12:28:52 +0000 Subject: Help understanding used power In-Reply-To: <20110404140345.2fd53a51@Luca> Message-ID: <002215974c6e0739b404a016e768@google.com> Hi, > I'm trying to understand how the options "nominal power" and > "max_power_red" work... nominal power is the _specified_ max power of the BTS, it's used _only_ for display in openbts and is never transmitted and doesn't actually change anything. Basically it just tells OpenBSC how strong your BTS is so it can display it in the "show ..." commands. That's because without this, openbsc has no way to know it. max_power_red is the maximum power reduction compared to the nominal power applied by the BTS during power control. So 0 for max power. Cheers, Sylvain PS: Apparently nominal power _is_ sent to the BTS in the abis_om2000.c (for the Ericsson BTS) ... Some custom configuration stuff I guess. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertoncello at netzing.de Mon Apr 4 12:43:16 2011 From: bertoncello at netzing.de (Luca Bertoncello) Date: Mon, 4 Apr 2011 14:43:16 +0200 Subject: Help understanding used power In-Reply-To: <002215974c6e0739b404a016e768@google.com> References: <20110404140345.2fd53a51@Luca> <002215974c6e0739b404a016e768@google.com> Message-ID: <20110404144316.4e68e019@Luca> Am Mon, 04 Apr 2011 12:28:52 +0000 schrieb 246tnt at gmail.com: > nominal power is the _specified_ max power of the BTS, it's used > _only_ for display in openbts and is never transmitted and doesn't > actually change anything. > Basically it just tells OpenBSC how strong your BTS is so it can > display it in the "show ..." commands. That's because without this, > openbsc has no way to know it. > > max_power_red is the maximum power reduction compared to the nominal > power applied by the BTS during power control. So 0 for max power. Hi, Sylvain, Thanks for your answer! Nevertheless I can't understand how these parameters work... I just set nominal power to 100, and then tried to change max_power_red. With my spectrum analyzer I can't see any difference in the capacity. I always receive signal with a capacity of about -13.30 dBm, regardless of which max_power_red I wrote... Could you please explain me this? Thanks a lot again! Luca -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fr?belstr. 57, 01159 Dresden Fax: 0351/41381 - 12 _______________________________________________________________________ Impressum: NETZING Solutions AG - Fr?belstra?e 57 - 01159 Dresden Sitz der Gesellschaft Amtsgericht Dresden HRB 18926 Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz USt.Id DE211326547 Mail: netzing.ag at netzing.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hwit at a-domani.nl Mon Apr 4 20:43:12 2011 From: hwit at a-domani.nl (Hans Witvliet) Date: Mon, 04 Apr 2011 22:43:12 +0200 Subject: alternative bts Message-ID: <1301949792.27984.20.camel@t43.lan0.a-domani.nl> Hi all, A thread on the asterisk mailing list re-triggerd my memory. Last november or so i asked if it might be possible to use a gsm/umts-dongle as a bts. afaicr the general consensus was that it was not possible because the proximity of TX and RX hardware. I have been discussing it with my colleges today and wonder where we were making the obvious thinking-mistake... 1) i know, that certainly at higher powers, the receiver becomes deaf in the vincinity of a (high powered) transmitter, due to cirtuit overload, but in our case we only needs a single miliwatt or even less.... 2) scanning for multiple devices/frequencies is not needed. [the idea is to connect to a single hand-held-device, that is only one meter away, and feed voice through an existing IP-connection] 3) if a dongle is not usable for above reasons as a BTS, why is that same dongle (more-or-less) capable as working as a handheld? Same problems should occur as such, not? http://wiki.e1550.mobi/doku.php If they can tap in the device for audio/sms-client, it should also be possible to do it the other way round, as a single-thread bts.... still puzzled, Hans From 246tnt at gmail.com Tue Apr 5 07:48:28 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 5 Apr 2011 09:48:28 +0200 Subject: alternative bts In-Reply-To: <1301949792.27984.20.camel@t43.lan0.a-domani.nl> References: <1301949792.27984.20.camel@t43.lan0.a-domani.nl> Message-ID: > 3) if a dongle is not usable for above reasons as a BTS, why is that > same dongle (more-or-less) capable as working as a handheld? Same > problems should occur as such, not? a BTS _needs_ to TX and RX at the same time. A MS doesn't. So the hw can't do it. Sylvain From pablo at gnumonks.org Tue Apr 5 10:16:29 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 05 Apr 2011 12:16:29 +0200 Subject: problems with pysim-prog Message-ID: <4D9AEBFD.30108@gnumonks.org> Hi! I'm experiencing problems with pysim-prog. Using the example available in the README file. # ./pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z lila -j 0 Insert card now (or CTRL-C to cancel) I get stuck here forever. The same message shows if I remove the supersim card from the reader. Running pysim inside strace shows: write(1, "Insert card now (or CTRL-C to cancel)\n", 38) = 38 ioctl(3, TIOCMBIS, [TIOCM_RTS]) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) ioctl(3, TCFLSH, 0) = 0 ioctl(3, TIOCMBIC, [TIOCM_RTS]) = 0 select(4, [3], [], [], {1, 0}) = 0 (Timeout) select(0, NULL, NULL, NULL, {0, 500000}) = 0 (Timeout) ioctl(3, TIOCMBIS, [TIOCM_RTS]) = 0 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) ioctl(3, TCFLSH, 0) = 0 ioctl(3, TIOCMBIC, [TIOCM_RTS]) = 0 ... [and so on] The pl2303 module is loaded correctly, and I have used it before to access some embedded devices via serial line: pl2303 2-2:1.0: pl2303 converter detected usb 2-2: pl2303 converter now attached to ttyUSB0 usb 2-2: USB disconnect, device number 11 pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 Any clue on what's wrong? Thanks! From pablo at gnumonks.org Fri Apr 29 18:05:08 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 29 Apr 2011 20:05:08 +0200 Subject: problems with pysim-prog In-Reply-To: <4D9AEBFD.30108@gnumonks.org> References: <4D9AEBFD.30108@gnumonks.org> Message-ID: <4DBAFDD4.5090004@gnumonks.org> On 05/04/11 12:16, Pablo Neira Ayuso wrote: > Hi! > > I'm experiencing problems with pysim-prog. Using the example available > in the README file. > > # ./pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z lila -j 0 > Insert card now (or CTRL-C to cancel) > > I get stuck here forever. The same message shows if I remove the > supersim card from the reader. > > Running pysim inside strace shows: > > write(1, "Insert card now (or CTRL-C to cancel)\n", 38) = 38 > ioctl(3, TIOCMBIS, [TIOCM_RTS]) = 0 > select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) > ioctl(3, TCFLSH, 0) = 0 > ioctl(3, TIOCMBIC, [TIOCM_RTS]) = 0 > select(4, [3], [], [], {1, 0}) = 0 (Timeout) > select(0, NULL, NULL, NULL, {0, 500000}) = 0 (Timeout) > ioctl(3, TIOCMBIS, [TIOCM_RTS]) = 0 > select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) > ioctl(3, TCFLSH, 0) = 0 > ioctl(3, TIOCMBIC, [TIOCM_RTS]) = 0 > ... [and so on] > > The pl2303 module is loaded correctly, and I have used it before to > access some embedded devices via serial line: > > pl2303 2-2:1.0: pl2303 converter detected > usb 2-2: pl2303 converter now attached to ttyUSB0 > usb 2-2: USB disconnect, device number 11 > pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 > > Any clue on what's wrong? Just for the record: I bought a brand new reader that works fine. It seems that the reader that I was using was broken. From pablo at gnumonks.org Tue Apr 5 16:45:16 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 5 Apr 2011 18:45:16 +0200 Subject: [PATCH 0/3] openbsc: cleanups for ipaccess tools (1/*) Message-ID: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patchset is the first in the series to cleanup redundant code in ipaccess tools. They are available in the pablo/cleanups branch in openbsc git tree. Please, merge it! Thanks. Pablo Neira Ayuso (3): ipaccess-config: exit if no network interface is specified libcommon: socket: extend make_sock() prototype ipaccess-proxy: get rid of internal make_sock() implementation openbsc/include/openbsc/socket.h | 5 ++- openbsc/src/ipaccess/ipaccess-find.c | 1 + openbsc/src/ipaccess/ipaccess-proxy.c | 42 ++------------------------------ openbsc/src/libabis/input/hsl.c | 4 +- openbsc/src/libabis/input/ipaccess.c | 8 +++--- openbsc/src/libcommon/socket.c | 10 ++++--- openbsc/src/libgb/gprs_ns.c | 2 +- openbsc/src/libgb/gprs_ns_frgre.c | 2 +- openbsc/src/osmo-bsc_nat/bsc_ussd.c | 2 +- 9 files changed, 22 insertions(+), 54 deletions(-) -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 5 16:45:17 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 5 Apr 2011 18:45:17 +0200 Subject: [PATCH 1/3] ipaccess-config: exit if no network interface is specified In-Reply-To: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> References: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302021919-5716-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso ipaccess-config has to exit if no network interface is specified, otherwise it uses argv[1] which has a uninitialized value. --- openbsc/src/ipaccess/ipaccess-find.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-find.c b/openbsc/src/ipaccess/ipaccess-find.c index 6dc2f06..a273609 100644 --- a/openbsc/src/ipaccess/ipaccess-find.c +++ b/openbsc/src/ipaccess/ipaccess-find.c @@ -196,6 +196,7 @@ int main(int argc, char **argv) if (argc < 2) { fprintf(stdout, "you might need to specify the outgoing\n" " network interface, e.g. ``%s eth0''\n", argv[0]); + exit(EXIT_FAILURE); } ifname = argv[1]; -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 5 16:45:18 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 5 Apr 2011 18:45:18 +0200 Subject: [PATCH 2/3] libcommon: socket: extend make_sock() prototype In-Reply-To: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> References: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302021919-5716-3-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch extends the make_sock() prototype so you can fully set the fields priv_nr and data of the bsc_fd structure. This is the first step to get rid of the internal make_sock() implementation that ipaccess-proxy uses. This patch includes a minor cleanup to pass INADDR_ANY instead of zero, if you do not want to bind the socket to one specific address. --- openbsc/include/openbsc/socket.h | 5 +++-- openbsc/src/libabis/input/hsl.c | 4 ++-- openbsc/src/libabis/input/ipaccess.c | 8 ++++---- openbsc/src/libcommon/socket.c | 10 ++++++---- openbsc/src/libgb/gprs_ns.c | 2 +- openbsc/src/libgb/gprs_ns_frgre.c | 2 +- openbsc/src/osmo-bsc_nat/bsc_ussd.c | 2 +- 7 files changed, 18 insertions(+), 15 deletions(-) diff --git a/openbsc/include/openbsc/socket.h b/openbsc/include/openbsc/socket.h index faca764..dac4ca7 100644 --- a/openbsc/include/openbsc/socket.h +++ b/openbsc/include/openbsc/socket.h @@ -8,7 +8,8 @@ #define IPPROTO_GRE 47 #endif -int make_sock(struct bsc_fd *bfd, int proto, u_int32_t ip, u_int16_t port, - int (*cb)(struct bsc_fd *fd, unsigned int what)); +int make_sock(struct bsc_fd *bfd, int proto, + u_int32_t ip, u_int16_t port, int priv_nr, + int (*cb)(struct bsc_fd *fd, unsigned int what), void *data); #endif /* _BSC_SOCKET_H */ diff --git a/openbsc/src/libabis/input/hsl.c b/openbsc/src/libabis/input/hsl.c index d8f284e..2b9ab1d 100644 --- a/openbsc/src/libabis/input/hsl.c +++ b/openbsc/src/libabis/input/hsl.c @@ -451,8 +451,8 @@ int hsl_setup(struct gsm_network *gsmnet) e1h->gsmnet = gsmnet; /* Listen for connections */ - ret = make_sock(&e1h->listen_fd, IPPROTO_TCP, 0, HSL_TCP_PORT, - listen_fd_cb); + ret = make_sock(&e1h->listen_fd, IPPROTO_TCP, INADDR_ANY, HSL_TCP_PORT, + 0, listen_fd_cb, NULL); if (ret < 0) return ret; diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index f074616..ab1d41d 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -782,14 +782,14 @@ int ipaccess_setup(struct gsm_network *gsmnet) e1h->gsmnet = gsmnet; /* Listen for OML connections */ - ret = make_sock(&e1h->listen_fd, IPPROTO_TCP, 0, IPA_TCP_PORT_OML, - listen_fd_cb); + ret = make_sock(&e1h->listen_fd, IPPROTO_TCP, INADDR_ANY, + IPA_TCP_PORT_OML, 0, listen_fd_cb, NULL); if (ret < 0) return ret; /* Listen for RSL connections */ - ret = make_sock(&e1h->rsl_listen_fd, IPPROTO_TCP, 0, - IPA_TCP_PORT_RSL, rsl_listen_fd_cb); + ret = make_sock(&e1h->rsl_listen_fd, IPPROTO_TCP, INADDR_ANY, + IPA_TCP_PORT_RSL, 0, rsl_listen_fd_cb, NULL); if (ret < 0) return ret; diff --git a/openbsc/src/libcommon/socket.c b/openbsc/src/libcommon/socket.c index 42d7b48..5ca7ec9 100644 --- a/openbsc/src/libcommon/socket.c +++ b/openbsc/src/libcommon/socket.c @@ -40,8 +40,9 @@ #include #include -int make_sock(struct bsc_fd *bfd, int proto, u_int32_t ip, u_int16_t port, - int (*cb)(struct bsc_fd *fd, unsigned int what)) +int make_sock(struct bsc_fd *bfd, int proto, + u_int32_t ip, u_int16_t port, int priv_nr, + int (*cb)(struct bsc_fd *fd, unsigned int what), void *data) { struct sockaddr_in addr; int ret, on = 1; @@ -64,7 +65,8 @@ int make_sock(struct bsc_fd *bfd, int proto, u_int32_t ip, u_int16_t port, bfd->fd = socket(AF_INET, type, proto); bfd->cb = cb; bfd->when = BSC_FD_READ; - //bfd->data = line; + bfd->data = data; + bfd->priv_nr = priv_nr; if (bfd->fd < 0) { LOGP(DINP, LOGL_ERROR, "could not create socket.\n"); @@ -74,7 +76,7 @@ int make_sock(struct bsc_fd *bfd, int proto, u_int32_t ip, u_int16_t port, memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(port); - if (ip) + if (ip != INADDR_ANY) addr.sin_addr.s_addr = htonl(ip); else addr.sin_addr.s_addr = INADDR_ANY; diff --git a/openbsc/src/libgb/gprs_ns.c b/openbsc/src/libgb/gprs_ns.c index 877a065..95e5a55 100644 --- a/openbsc/src/libgb/gprs_ns.c +++ b/openbsc/src/libgb/gprs_ns.c @@ -946,7 +946,7 @@ int gprs_ns_nsip_listen(struct gprs_ns_inst *nsi) int ret; ret = make_sock(&nsi->nsip.fd, IPPROTO_UDP, nsi->nsip.local_ip, - nsi->nsip.local_port, nsip_fd_cb); + nsi->nsip.local_port, 0, nsip_fd_cb, NULL); if (ret < 0) return ret; diff --git a/openbsc/src/libgb/gprs_ns_frgre.c b/openbsc/src/libgb/gprs_ns_frgre.c index 98b1ad6..85019e1 100644 --- a/openbsc/src/libgb/gprs_ns_frgre.c +++ b/openbsc/src/libgb/gprs_ns_frgre.c @@ -292,7 +292,7 @@ int gprs_ns_frgre_listen(struct gprs_ns_inst *nsi) return 0; rc = make_sock(&nsi->frgre.fd, IPPROTO_GRE, nsi->frgre.local_ip, - 0, nsfrgre_fd_cb); + 0, 0, nsfrgre_fd_cb, NULL); if (rc < 0) { LOGP(DNS, LOGL_ERROR, "Error creating GRE socket (%s)\n", strerror(errno)); diff --git a/openbsc/src/osmo-bsc_nat/bsc_ussd.c b/openbsc/src/osmo-bsc_nat/bsc_ussd.c index 0dd0d87..50c50ed 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_ussd.c +++ b/openbsc/src/osmo-bsc_nat/bsc_ussd.c @@ -251,7 +251,7 @@ int bsc_ussd_init(struct bsc_nat *nat) nat->ussd_listen.data = nat; return make_sock(&nat->ussd_listen, IPPROTO_TCP, - ntohl(addr.s_addr), 5001, ussd_listen_cb); + ntohl(addr.s_addr), 5001, 0, ussd_listen_cb, NULL); } static int forward_ussd(struct sccp_connections *con, const struct ussd_request *req, -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 5 16:45:19 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 5 Apr 2011 18:45:19 +0200 Subject: [PATCH 3/3] ipaccess-proxy: get rid of internal make_sock() implementation In-Reply-To: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> References: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302021919-5716-4-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso With this patch, we use the implementation available in libcommon. --- openbsc/src/ipaccess/ipaccess-proxy.c | 42 ++------------------------------ 1 files changed, 3 insertions(+), 39 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index d98eb54..a6b433f 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -44,6 +44,7 @@ #include #include #include +#include #include static struct log_target *stderr_target; @@ -288,43 +289,6 @@ static void _logp_ipbc_uid(unsigned int ss, unsigned int lvl, char *file, int li logp2(ss, lvl, file, line, 0, "unknown "); } -/* UDP socket handling */ - -static int make_sock(struct bsc_fd *bfd, u_int16_t port, int proto, int priv_nr, - int (*cb)(struct bsc_fd *fd, unsigned int what), - void *data) -{ - struct sockaddr_in addr; - int ret, on = 1; - - bfd->fd = socket(AF_INET, SOCK_DGRAM, proto); - bfd->cb = cb; - bfd->when = BSC_FD_READ; - bfd->data = data; - bfd->priv_nr = priv_nr; - - memset(&addr, 0, sizeof(addr)); - addr.sin_family = AF_INET; - addr.sin_port = htons(port); - addr.sin_addr.s_addr = INADDR_ANY; - - setsockopt(bfd->fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); - - ret = bind(bfd->fd, (struct sockaddr *) &addr, sizeof(addr)); - if (ret < 0) { - LOGP(DINP, LOGL_ERROR, "could not bind socket: %s\n", - strerror(errno)); - return -EIO; - } - - ret = bsc_register_fd(bfd); - if (ret < 0) { - perror("register UDP fd"); - return ret; - } - return 0; -} - static int handle_udp_read(struct bsc_fd *bfd) { struct ipa_bts_conn *ipbc = bfd->data; @@ -494,7 +458,7 @@ static int ipbc_alloc_connect(struct ipa_proxy_conn *ipc, struct bsc_fd *bfd, /* Create UDP socket for BTS packet injection */ udp_port = 10000 + (site_id % 1000)*100 + (bts_id % 100); - ret = make_sock(&ipbc->udp_bts_fd, udp_port, IPPROTO_UDP, + ret = make_sock(&ipbc->udp_bts_fd, IPPROTO_UDP, INADDR_ANY, udp_port, UDP_TO_BTS, udp_fd_cb, ipbc); if (ret < 0) goto err_udp_bts; @@ -503,7 +467,7 @@ static int ipbc_alloc_connect(struct ipa_proxy_conn *ipc, struct bsc_fd *bfd, /* Create UDP socket for BSC packet injection */ udp_port = 20000 + (site_id % 1000)*100 + (bts_id % 100); - ret = make_sock(&ipbc->udp_bsc_fd, udp_port, IPPROTO_UDP, + ret = make_sock(&ipbc->udp_bsc_fd, IPPROTO_UDP, INADDR_ANY, udp_port, UDP_TO_BSC, udp_fd_cb, ipbc); if (ret < 0) goto err_udp_bsc; -- 1.7.2.3 From laforge at gnumonks.org Tue Apr 5 17:28:35 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 5 Apr 2011 19:28:35 +0200 Subject: [PATCH 0/3] openbsc: cleanups for ipaccess tools (1/*) In-Reply-To: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> References: <1302021919-5716-1-git-send-email-pablo@gnumonks.org> Message-ID: <20110405172835.GN15850@prithivi.gnumonks.org> Hi Pablo, On Tue, Apr 05, 2011 at 06:45:16PM +0200, pablo at gnumonks.org wrote: > This patchset is the first in the series to cleanup redundant code > in ipaccess tools. Thanks, I've merged your cleanups branch. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From thebigguy.co.uk at gmail.com Wed Apr 6 20:57:49 2011 From: thebigguy.co.uk at gmail.com (Guy Taylor) Date: Wed, 6 Apr 2011 21:57:49 +0100 Subject: GSM equipment auction Message-ID: Hi all Just to let everyone know about an auction that people may like to look into. Online Auction Closes 3pm* on Tuesday 19th April 2011 Extensive Electronic Test and Measurment Equipment to include Agilent /HP Telecom test, Spectrum Analysers, Frequency generators, Optical Test, Oscilloscopes, Programmable Power Supplies, Inspection Scopes, 19in Test rack syetems Equipment Transport, IT equipment and more. http://www.sweeney-kincaid.com/Sales/SaleDescription.aspx?SaleId=1640 guy From 246tnt at gmail.com Sat Apr 9 11:26:50 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Sat, 09 Apr 2011 11:26:50 +0000 Subject: GSM equipment auction In-Reply-To: Message-ID: <485b393ab1615de88c04a07a9e1a@google.com> Hi, Yes, I've seen it and there are definite keeper in that one ... Unfortunately, you have to go pick it up in Edimbourg in person at a specific date :( Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From kobayashi_maru at onlinehome.de Thu Apr 7 08:32:38 2011 From: kobayashi_maru at onlinehome.de (kobayashi_maru at onlinehome.de) Date: Thu, 7 Apr 2011 10:32:38 +0200 (CEST) Subject: T3103 value Message-ID: <476089488.360551.1302165158397.JavaMail.tomcat55@mrmseu2.kundenserver.de> An HTML attachment was scrubbed... URL: -------------- next part -------------- hello what's a suitable value for the 3103? T. From kobayashi_maru at onlinehome.de Thu Apr 7 10:42:54 2011 From: kobayashi_maru at onlinehome.de (Thomas Ansorg) Date: Thu, 7 Apr 2011 12:42:54 +0200 Subject: question msg_3 in bsc_init.c Message-ID: hello to enable handover function, do i have to change in data field msg_3 the corresponding values form 0x00h to 0x01h? does 0x01h enable where 0x00h disables? T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at gnumonks.org Thu Apr 7 12:27:51 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:51 +0200 Subject: [PATCH 0/6] openbsc: cleanups for ipaccess tools (2/*) Message-ID: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patchset is the second in the series to cleanup redundant code in ipaccess tools. They have been tested by bootstraping the nanoBTS successfully in a small setup with two laptops, one acting as proxy and another with osmo-nitb. They are available in the pablo/cleanups branch in openbsc git tree. Please, merge it! Thanks. Pablo Neira Ayuso (6): ipaccess-proxy: get rid of make_listen_sock() and use make_sock() instead libabis: ipaccess: conclude new ipaccess_send_*() functions and use them libabis: ipaccess: export ipaccess_idtag_name() ipaccess-proxy: get rid of ipac_idtag_parse() libabis: ipaccess: export ipaccess_parse_unitid ipaccess-proxy: remove hardcoded IP for options `-l' and `-b' openbsc/include/openbsc/ipaccess.h | 3 + openbsc/src/ipaccess/Makefile.am | 7 +- openbsc/src/ipaccess/ipaccess-proxy.c | 188 ++++++--------------------------- openbsc/src/libabis/input/ipaccess.c | 75 +++++++++---- 4 files changed, 94 insertions(+), 179 deletions(-) -- 1.7.2.3 From pablo at gnumonks.org Thu Apr 7 12:27:52 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:52 +0200 Subject: [PATCH 1/6] ipaccess-proxy: get rid of make_listen_sock() and use make_sock() instead In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302179277-15975-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch replaces make_listen_sock() by the generic make_sock() available in libcommon/socket. --- openbsc/src/ipaccess/ipaccess-proxy.c | 51 ++------------------------------ 1 files changed, 4 insertions(+), 47 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index a6b433f..d1c7a33 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -1078,49 +1078,6 @@ static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what) return 0; } -static int make_listen_sock(struct bsc_fd *bfd, u_int16_t port, int priv_nr, - int (*cb)(struct bsc_fd *fd, unsigned int what)) -{ - struct sockaddr_in addr; - int ret, on = 1; - - bfd->fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); - bfd->cb = cb; - bfd->when = BSC_FD_READ; - bfd->priv_nr = priv_nr; - - memset(&addr, 0, sizeof(addr)); - addr.sin_family = AF_INET; - addr.sin_port = htons(port); - if (!listen_ipaddr) - addr.sin_addr.s_addr = INADDR_ANY; - else - inet_aton(listen_ipaddr, &addr.sin_addr); - - setsockopt(bfd->fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)); - - ret = bind(bfd->fd, (struct sockaddr *) &addr, sizeof(addr)); - if (ret < 0) { - LOGP(DINP, LOGL_ERROR, - "Could not bind listen socket for IP %s with error: %s.\n", - listen_ipaddr, strerror(errno)); - return -EIO; - } - - ret = listen(bfd->fd, 1); - if (ret < 0) { - perror("listen"); - return ret; - } - - ret = bsc_register_fd(bfd); - if (ret < 0) { - perror("register_listen_fd"); - return ret; - } - return 0; -} - static int make_gprs_sock(struct bsc_fd *bfd, int (*cb)(struct bsc_fd*,unsigned int), void *data) { struct sockaddr_in addr; @@ -1206,14 +1163,14 @@ static int ipaccess_proxy_setup(void) ipp->reconn_timer.data = ipp; /* Listen for OML connections */ - ret = make_listen_sock(&ipp->oml_listen_fd, IPA_TCP_PORT_OML, - OML_FROM_BTS, listen_fd_cb); + ret = make_sock(&ipp->oml_listen_fd, IPPROTO_TCP, INADDR_ANY, + IPA_TCP_PORT_OML, OML_FROM_BTS, listen_fd_cb, NULL); if (ret < 0) return ret; /* Listen for RSL connections */ - ret = make_listen_sock(&ipp->rsl_listen_fd, IPA_TCP_PORT_RSL, - RSL_FROM_BTS, listen_fd_cb); + ret = make_sock(&ipp->rsl_listen_fd, IPPROTO_TCP, INADDR_ANY, + IPA_TCP_PORT_RSL, RSL_FROM_BTS, listen_fd_cb, NULL); if (ret < 0) return ret; -- 1.7.2.3 From pablo at gnumonks.org Thu Apr 7 12:27:53 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:53 +0200 Subject: [PATCH 2/6] libabis: ipaccess: conclude new ipaccess_send_*() functions and use them In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302179277-15975-3-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch finishes the new ipaccess_send_*() functions and use them in the ipaccess-proxy code. I have also cleanup the definition of the PONG, ID_ACK and ID_REQ messages (including some minor documentation about them). I had to rename ipaccess_recvmsg() in ipaccess-proxy to avoid clashing with the one defined in libabis. --- openbsc/include/openbsc/ipaccess.h | 1 + openbsc/src/ipaccess/Makefile.am | 7 +++- openbsc/src/ipaccess/ipaccess-proxy.c | 29 +++------------ openbsc/src/libabis/input/ipaccess.c | 65 ++++++++++++++++++++++++--------- 4 files changed, 60 insertions(+), 42 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index 314ca90..b286f93 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -70,6 +70,7 @@ int ipaccess_connect(struct e1inp_line *line, struct sockaddr_in *sa); int ipaccess_rcvmsg_base(struct msgb *msg, struct bsc_fd *bfd); struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error); void ipaccess_prepend_header(struct msgb *msg, int proto); +int ipaccess_send_pong(int fd); int ipaccess_send_id_ack(int fd); int ipaccess_send_id_req(int fd); diff --git a/openbsc/src/ipaccess/Makefile.am b/openbsc/src/ipaccess/Makefile.am index c997c29..cff3505 100644 --- a/openbsc/src/ipaccess/Makefile.am +++ b/openbsc/src/ipaccess/Makefile.am @@ -18,4 +18,9 @@ ipaccess_config_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ -ldl -ldbi $(LIBCRYPT) ipaccess_proxy_SOURCES = ipaccess-proxy.c -ipaccess_proxy_LDADD = $(top_builddir)/src/libcommon/libcommon.a +ipaccess_proxy_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ + $(top_builddir)/src/libmsc/libmsc.a \ + $(top_builddir)/src/libabis/libabis.a \ + $(top_builddir)/src/libbsc/libbsc.a \ + $(top_builddir)/src/libtrau/libtrau.a \ + $(top_builddir)/src/libcommon/libcommon.a diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index d1c7a33..b8b42c0 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -131,19 +131,6 @@ static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what); #define PROXY_ALLOC_SIZE 1200 -static const u_int8_t pong[] = { 0, 1, IPAC_PROTO_IPACCESS, IPAC_MSGT_PONG }; -static const u_int8_t id_ack[] = { 0, 1, IPAC_PROTO_IPACCESS, IPAC_MSGT_ID_ACK }; -static const u_int8_t id_req[] = { 0, 17, IPAC_PROTO_IPACCESS, IPAC_MSGT_ID_GET, - 0x01, IPAC_IDTAG_UNIT, - 0x01, IPAC_IDTAG_MACADDR, - 0x01, IPAC_IDTAG_LOCATION1, - 0x01, IPAC_IDTAG_LOCATION2, - 0x01, IPAC_IDTAG_EQUIPVERS, - 0x01, IPAC_IDTAG_SWVERSION, - 0x01, IPAC_IDTAG_UNITNAME, - 0x01, IPAC_IDTAG_SERNR, - }; - static const char *idtag_names[] = { [IPAC_IDTAG_SERNR] = "Serial_Number", [IPAC_IDTAG_UNITNAME] = "Unit_Name", @@ -529,13 +516,7 @@ static int ipaccess_rcvmsg(struct ipa_proxy_conn *ipc, struct msgb *msg, switch (msg_type) { case IPAC_MSGT_PING: - ret = write(bfd->fd, pong, sizeof(pong)); - if (ret < 0) - return ret; - if (ret < sizeof(pong)) { - DEBUGP(DINP, "short write\n"); - return -EIO; - } + ret = ipaccess_send_pong(bfd->fd); break; case IPAC_MSGT_PONG: DEBUGP(DMI, "PONG!\n"); @@ -618,7 +599,7 @@ static int ipaccess_rcvmsg(struct ipa_proxy_conn *ipc, struct msgb *msg, break; case IPAC_MSGT_ID_ACK: DEBUGP(DMI, "ID_ACK? -> ACK!\n"); - ret = write(bfd->fd, id_ack, sizeof(id_ack)); + ret = ipaccess_send_id_ack(bfd->fd); break; default: LOGP(DMI, LOGL_ERROR, "Unhandled IPA type; %d\n", msg_type); @@ -628,7 +609,7 @@ static int ipaccess_rcvmsg(struct ipa_proxy_conn *ipc, struct msgb *msg, return 0; } -struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) +struct msgb *ipaccess_proxy_read_msg(struct bsc_fd *bfd, int *error) { struct msgb *msg = msgb_alloc(PROXY_ALLOC_SIZE, "Abis/IP"); struct ipaccess_head *hh; @@ -868,7 +849,7 @@ static int handle_tcp_read(struct bsc_fd *bfd) else btsbsc = "BSC"; - msg = ipaccess_read_msg(bfd, &ret); + msg = ipaccess_proxy_read_msg(bfd, &ret); if (!msg) { if (ret == 0) { logp_ipbc_uid(DINP, LOGL_NOTICE, ipbc, bfd->priv_nr >> 8); @@ -1025,7 +1006,7 @@ static int listen_fd_cb(struct bsc_fd *listen_bfd, unsigned int what) } /* Request ID. FIXME: request LOCATION, HW/SW VErsion, Unit Name, Serno */ - ret = write(bfd->fd, id_req, sizeof(id_req)); + ret = ipaccess_send_id_req(bfd->fd); return 0; } diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index ab1d41d..b652b90 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -62,18 +62,31 @@ static struct ia_e1_handle *e1h; #define TS1_ALLOC_SIZE 900 -static const u_int8_t pong[] = { 0, 1, IPAC_PROTO_IPACCESS, IPAC_MSGT_PONG }; -static const u_int8_t id_ack[] = { 0, 1, IPAC_PROTO_IPACCESS, IPAC_MSGT_ID_ACK }; -static const u_int8_t id_req[] = { 0, 17, IPAC_PROTO_IPACCESS, IPAC_MSGT_ID_GET, - 0x01, IPAC_IDTAG_UNIT, - 0x01, IPAC_IDTAG_MACADDR, - 0x01, IPAC_IDTAG_LOCATION1, - 0x01, IPAC_IDTAG_LOCATION2, - 0x01, IPAC_IDTAG_EQUIPVERS, - 0x01, IPAC_IDTAG_SWVERSION, - 0x01, IPAC_IDTAG_UNITNAME, - 0x01, IPAC_IDTAG_SERNR, - }; +/* + * Common propietary IPA messages: + * - PONG: in reply to PING. + * - ID_REQUEST: first messages once OML has been established. + * - ID_ACK: in reply to ID_ACK. + */ +const u_int8_t ipa_pong_msg[] = { + 0, 1, IPAC_PROTO_IPACCESS, IPAC_MSGT_PONG +}; + +const u_int8_t ipa_id_ack_msg[] = { + 0, 1, IPAC_PROTO_IPACCESS, IPAC_MSGT_ID_ACK +}; + +const u_int8_t ipa_id_req_msg[] = { + 0, 17, IPAC_PROTO_IPACCESS, IPAC_MSGT_ID_GET, + 0x01, IPAC_IDTAG_UNIT, + 0x01, IPAC_IDTAG_MACADDR, + 0x01, IPAC_IDTAG_LOCATION1, + 0x01, IPAC_IDTAG_LOCATION2, + 0x01, IPAC_IDTAG_EQUIPVERS, + 0x01, IPAC_IDTAG_SWVERSION, + 0x01, IPAC_IDTAG_UNITNAME, + 0x01, IPAC_IDTAG_SERNR, +}; static const char *idtag_names[] = { [IPAC_IDTAG_SERNR] = "Serial_Number", @@ -179,15 +192,33 @@ static int parse_unitid(const char *str, u_int16_t *site_id, u_int16_t *bts_id, return 0; } -/* send the id ack */ +static int ipaccess_send(int fd, const void *msg, size_t msglen) +{ + int ret; + + ret = write(fd, msg, msglen); + if (ret < 0) + return ret; + if (ret < msglen) { + DEBUGP(DINP, "ipaccess_send: short write\n"); + return -EIO; + } + return ret; +} + +int ipaccess_send_pong(int fd) +{ + return ipaccess_send(fd, ipa_pong_msg, sizeof(ipa_pong_msg)); +} + int ipaccess_send_id_ack(int fd) { - return write(fd, id_ack, sizeof(id_ack)); + return ipaccess_send(fd, ipa_id_ack_msg, sizeof(ipa_id_ack_msg)); } int ipaccess_send_id_req(int fd) { - return write(fd, id_req, sizeof(id_req)); + return ipaccess_send(fd, ipa_id_req_msg, sizeof(ipa_id_req_msg)); } /* base handling of the ip.access protocol */ @@ -199,7 +230,7 @@ int ipaccess_rcvmsg_base(struct msgb *msg, switch (msg_type) { case IPAC_MSGT_PING: - ret = write(bfd->fd, pong, sizeof(pong)); + ret = ipaccess_send_pong(bfd->fd); break; case IPAC_MSGT_PONG: DEBUGP(DMI, "PONG!\n"); @@ -721,7 +752,7 @@ static int rsl_listen_fd_cb(struct bsc_fd *listen_bfd, unsigned int what) return ret; } /* Request ID. FIXME: request LOCATION, HW/SW VErsion, Unit Name, Serno */ - ret = write(bfd->fd, id_req, sizeof(id_req)); + ret = ipaccess_send_id_req(bfd->fd); return 0; } -- 1.7.2.3 From holger at freyther.de Thu Apr 7 20:18:59 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 07 Apr 2011 22:18:59 +0200 Subject: [PATCH 2/6] libabis: ipaccess: conclude new ipaccess_send_*() functions and use them In-Reply-To: <1302179277-15975-3-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <1302179277-15975-3-git-send-email-pablo@gnumonks.org> Message-ID: <4D9E1C33.6020605@freyther.de> On 04/07/2011 02:27 PM, pablo at gnumonks.org wrote: > -/* send the id ack */ > +static int ipaccess_send(int fd, const void *msg, size_t msglen) > +{ > + int ret; > + > + ret = write(fd, msg, msglen); > + if (ret < 0) > + return ret; > + if (ret < msglen) { > + DEBUGP(DINP, "ipaccess_send: short write\n"); > + return -EIO; > + } > + return ret; > +} > + Hi Pablo, I know you are just moving this around but I think this qualifies as LOGP(LOGL_ERROR. Feel free to address this later. From pablo at gnumonks.org Thu Apr 7 12:27:54 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:54 +0200 Subject: [PATCH 3/6] libabis: ipaccess: export ipaccess_idtag_name() In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302179277-15975-4-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Now this is used by ipaccess-proxy, remove redundant implemention in it. --- openbsc/include/openbsc/ipaccess.h | 1 + openbsc/src/ipaccess/ipaccess-proxy.c | 22 +--------------------- openbsc/src/libabis/input/ipaccess.c | 4 ++-- 3 files changed, 4 insertions(+), 23 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index b286f93..6053efd 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -74,6 +74,7 @@ int ipaccess_send_pong(int fd); int ipaccess_send_id_ack(int fd); int ipaccess_send_id_req(int fd); +const char *ipaccess_idtag_name(int tag); int ipaccess_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len); int ipaccess_drop_oml(struct gsm_bts *bts); diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index b8b42c0..c6538ff 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -131,26 +131,6 @@ static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what); #define PROXY_ALLOC_SIZE 1200 -static const char *idtag_names[] = { - [IPAC_IDTAG_SERNR] = "Serial_Number", - [IPAC_IDTAG_UNITNAME] = "Unit_Name", - [IPAC_IDTAG_LOCATION1] = "Location_1", - [IPAC_IDTAG_LOCATION2] = "Location_2", - [IPAC_IDTAG_EQUIPVERS] = "Equipment_Version", - [IPAC_IDTAG_SWVERSION] = "Software_Version", - [IPAC_IDTAG_IPADDR] = "IP_Address", - [IPAC_IDTAG_MACADDR] = "MAC_Address", - [IPAC_IDTAG_UNIT] = "Unit_ID", -}; - -static const char *ipac_idtag_name(int tag) -{ - if (tag >= ARRAY_SIZE(idtag_names)) - return "unknown"; - - return idtag_names[tag]; -} - static int ipac_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len) { u_int8_t t_len; @@ -161,7 +141,7 @@ static int ipac_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len) t_len = *cur++; t_tag = *cur++; - DEBUGPC(DMI, "%s='%s' ", ipac_idtag_name(t_tag), cur); + DEBUGPC(DMI, "%s='%s' ", ipaccess_idtag_name(t_tag), cur); dec->lv[t_tag].len = t_len; dec->lv[t_tag].val = cur; diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index b652b90..6b15e47 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -100,7 +100,7 @@ static const char *idtag_names[] = { [IPAC_IDTAG_UNIT] = "Unit_ID", }; -static const char *ipac_idtag_name(int tag) +const char *ipaccess_idtag_name(int tag) { if (tag >= ARRAY_SIZE(idtag_names)) return "unknown"; @@ -126,7 +126,7 @@ int ipaccess_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len) return -1; } - DEBUGPC(DMI, "%s='%s' ", ipac_idtag_name(t_tag), cur); + DEBUGPC(DMI, "%s='%s' ", ipaccess_idtag_name(t_tag), cur); dec->lv[t_tag].len = t_len; dec->lv[t_tag].val = cur; -- 1.7.2.3 From holger at freyther.de Thu Apr 7 20:23:52 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 07 Apr 2011 22:23:52 +0200 Subject: [PATCH 3/6] libabis: ipaccess: export ipaccess_idtag_name() In-Reply-To: <1302179277-15975-4-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <1302179277-15975-4-git-send-email-pablo@gnumonks.org> Message-ID: <4D9E1D58.60801@freyther.de> On 04/07/2011 02:27 PM, pablo at gnumonks.org wrote: Hi Pablo, thanks for the cleaning, the criticism is to the code as it was before. > t_tag = *cur++; > > - DEBUGPC(DMI, "%s='%s' ", ipac_idtag_name(t_tag), cur); > + DEBUGPC(DMI, "%s='%s' ", ipaccess_idtag_name(t_tag), cur); I think we still rely that the strings on the wire have a null termination? IIRC I once patched one version (of the many) to check for it and otherwise discard it. Would you mind taking a look at it? > > -static const char *ipac_idtag_name(int tag) > +const char *ipaccess_idtag_name(int tag) > { > if (tag >= ARRAY_SIZE(idtag_names)) > return "unknown"; we probably want to make the parameter uint? From pablo at gnumonks.org Sun Apr 10 11:01:44 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sun, 10 Apr 2011 13:01:44 +0200 Subject: [PATCH 3/6] libabis: ipaccess: export ipaccess_idtag_name() In-Reply-To: <4D9E1D58.60801@freyther.de> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <1302179277-15975-4-git-send-email-pablo@gnumonks.org> <4D9E1D58.60801@freyther.de> Message-ID: <4DA18E18.8040504@gnumonks.org> Hi Holger, On 07/04/11 22:23, Holger Hans Peter Freyther wrote: > On 04/07/2011 02:27 PM, pablo at gnumonks.org wrote: > thanks for the cleaning, the criticism is to the code as it was before. > >> t_tag = *cur++; >> >> - DEBUGPC(DMI, "%s='%s' ", ipac_idtag_name(t_tag), cur); >> + DEBUGPC(DMI, "%s='%s' ", ipaccess_idtag_name(t_tag), cur); > > I think we still rely that the strings on the wire have a null termination? > IIRC I once patched one version (of the many) to check for it and otherwise > discard it. Would you mind taking a look at it? I'll have a look at all string handling. >> -static const char *ipac_idtag_name(int tag) >> +const char *ipaccess_idtag_name(int tag) >> { >> if (tag >= ARRAY_SIZE(idtag_names)) >> return "unknown"; > > we probably want to make the parameter uint? I have a patch for this here, I'll send it asap. From pablo at gnumonks.org Thu Apr 7 12:27:55 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:55 +0200 Subject: [PATCH 4/6] ipaccess-proxy: get rid of ipac_idtag_parse() In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302179277-15975-5-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Use ipaccess_idtag_parse() available in libabis instead. --- openbsc/src/ipaccess/ipaccess-proxy.c | 24 ++---------------------- 1 files changed, 2 insertions(+), 22 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index c6538ff..d2bf599 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -131,26 +131,6 @@ static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what); #define PROXY_ALLOC_SIZE 1200 -static int ipac_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len) -{ - u_int8_t t_len; - u_int8_t t_tag; - u_int8_t *cur = buf; - - while (cur < buf + len) { - t_len = *cur++; - t_tag = *cur++; - - DEBUGPC(DMI, "%s='%s' ", ipaccess_idtag_name(t_tag), cur); - - dec->lv[t_tag].len = t_len; - dec->lv[t_tag].val = cur; - - cur += t_len; - } - return 0; -} - static int parse_unitid(const char *str, u_int16_t *site_id, u_int16_t *bts_id, u_int16_t *trx_id) { @@ -504,8 +484,8 @@ static int ipaccess_rcvmsg(struct ipa_proxy_conn *ipc, struct msgb *msg, case IPAC_MSGT_ID_RESP: DEBUGP(DMI, "ID_RESP "); /* parse tags, search for Unit ID */ - ipac_idtag_parse(&tlvp, (u_int8_t *)msg->l2h + 2, - msgb_l2len(msg)-2); + ipaccess_idtag_parse(&tlvp, (u_int8_t *)msg->l2h + 2, + msgb_l2len(msg)-2); DEBUGP(DMI, "\n"); if (!TLVP_PRESENT(&tlvp, IPAC_IDTAG_UNIT)) { -- 1.7.2.3 From pablo at gnumonks.org Thu Apr 7 12:27:56 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:56 +0200 Subject: [PATCH 5/6] libabis: ipaccess: export ipaccess_parse_unitid In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302179277-15975-6-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Now this is used by ipaccess-proxy, remove redundant implementation in it. --- openbsc/include/openbsc/ipaccess.h | 1 + openbsc/src/ipaccess/ipaccess-proxy.c | 41 +------------------------------- openbsc/src/libabis/input/ipaccess.c | 6 ++-- 3 files changed, 6 insertions(+), 42 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index 6053efd..135fce2 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -76,6 +76,7 @@ int ipaccess_send_id_req(int fd); const char *ipaccess_idtag_name(int tag); int ipaccess_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len); +int ipaccess_parse_unitid(const char *str, u_int16_t *site_id, u_int16_t *bts_id, u_int16_t *trx_id); int ipaccess_drop_oml(struct gsm_bts *bts); int ipaccess_drop_rsl(struct gsm_bts_trx *trx); diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index d2bf599..b6dcad1 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -131,43 +131,6 @@ static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what); #define PROXY_ALLOC_SIZE 1200 -static int parse_unitid(const char *str, u_int16_t *site_id, u_int16_t *bts_id, - u_int16_t *trx_id) -{ - unsigned long ul; - char *endptr; - const char *nptr; - - nptr = str; - ul = strtoul(nptr, &endptr, 10); - if (endptr <= nptr) - return -EINVAL; - if (site_id) - *site_id = ul & 0xffff; - - if (*endptr++ != '/') - return -EINVAL; - - nptr = endptr; - ul = strtoul(nptr, &endptr, 10); - if (endptr <= nptr) - return -EINVAL; - if (bts_id) - *bts_id = ul & 0xffff; - - if (*endptr++ != '/') - return -EINVAL; - - nptr = endptr; - ul = strtoul(nptr, &endptr, 10); - if (endptr <= nptr) - return -EINVAL; - if (trx_id) - *trx_id = ul & 0xffff; - - return 0; -} - static struct ipa_bts_conn *find_bts_by_unitid(struct ipa_proxy *ipp, u_int16_t site_id, u_int16_t bts_id) @@ -495,8 +458,8 @@ static int ipaccess_rcvmsg(struct ipa_proxy_conn *ipc, struct msgb *msg, /* lookup BTS, create sign_link, ... */ site_id = bts_id = trx_id = 0; - parse_unitid((char *)TLVP_VAL(&tlvp, IPAC_IDTAG_UNIT), - &site_id, &bts_id, &trx_id); + ipaccess_parse_unitid((char *)TLVP_VAL(&tlvp, IPAC_IDTAG_UNIT), + &site_id, &bts_id, &trx_id); ipbc = find_bts_by_unitid(ipp, site_id, bts_id); if (!ipbc) { /* We have not found an ipbc (per-bts proxy instance) diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index 6b15e47..ecf7038 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -155,8 +155,8 @@ struct gsm_bts *find_bts_by_unitid(struct gsm_network *net, return NULL; } -static int parse_unitid(const char *str, u_int16_t *site_id, u_int16_t *bts_id, - u_int16_t *trx_id) +int ipaccess_parse_unitid(const char *str, u_int16_t *site_id, + u_int16_t *bts_id, u_int16_t *trx_id) { unsigned long ul; char *endptr; @@ -274,7 +274,7 @@ static int ipaccess_rcvmsg(struct e1inp_line *line, struct msgb *msg, /* lookup BTS, create sign_link, ... */ unitid = (char *) TLVP_VAL(&tlvp, IPAC_IDTAG_UNIT); unitid[len - 1] = '\0'; - parse_unitid(unitid, &site_id, &bts_id, &trx_id); + ipaccess_parse_unitid(unitid, &site_id, &bts_id, &trx_id); bts = find_bts_by_unitid(e1h->gsmnet, site_id, bts_id); if (!bts) { LOGP(DINP, LOGL_ERROR, "Unable to find BTS configuration for " -- 1.7.2.3 From pablo at gnumonks.org Thu Apr 7 12:27:57 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Thu, 7 Apr 2011 14:27:57 +0200 Subject: [PATCH 6/6] ipaccess-proxy: remove hardcoded IP for options `-l' and `-b' In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302179277-15975-7-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch removes the hardcoded IP addresses for options `-l' and `-b'. --- openbsc/src/ipaccess/ipaccess-proxy.c | 23 +++++++++++++++++++---- 1 files changed, 19 insertions(+), 4 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index b6dcad1..d420b63 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -1120,11 +1120,19 @@ static void print_help() static void print_usage() { - printf("Usage: ipaccess-proxy\n"); + printf("Usage: ipaccess-proxy [options]\n"); } +enum { + IPA_PROXY_OPT_LISTEN_NONE = 0, + IPA_PROXY_OPT_LISTEN_IP = (1 << 0), + IPA_PROXY_OPT_BSC_IP = (1 << 1), +}; + static void handle_options(int argc, char** argv) { + int options_mask = 0; + while (1) { int option_index = 0, c; static struct option long_options[] = { @@ -1150,9 +1158,11 @@ static void handle_options(int argc, char** argv) exit(0); case 'l': listen_ipaddr = optarg; + options_mask |= IPA_PROXY_OPT_LISTEN_IP; break; case 'b': bsc_ipaddr = optarg; + options_mask |= IPA_PROXY_OPT_BSC_IP; break; case 'g': gprs_ns_ipaddr = optarg; @@ -1171,15 +1181,20 @@ static void handle_options(int argc, char** argv) break; } } + if (!((options_mask & (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP)) + == (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP))) { + printf("ERROR: You have to specify `--listen' and `--bsc' " + "options at least.\n"); + print_usage(); + print_help(); + exit(EXIT_FAILURE); + } } int main(int argc, char **argv) { int rc; - listen_ipaddr = "192.168.100.11"; - bsc_ipaddr = "192.168.100.239"; - tall_bsc_ctx = talloc_named_const(NULL, 1, "ipaccess-proxy"); log_init(&log_info); -- 1.7.2.3 From holger at freyther.de Thu Apr 7 12:42:04 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 07 Apr 2011 14:42:04 +0200 Subject: [PATCH 6/6] ipaccess-proxy: remove hardcoded IP for options `-l' and `-b' In-Reply-To: <1302179277-15975-7-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <1302179277-15975-7-git-send-email-pablo@gnumonks.org> Message-ID: <4D9DB11C.9030306@freyther.de> On 04/07/2011 02:27 PM, pablo at gnumonks.org wrote: > } > + if (!((options_mask & (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP)) > + == (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP))) { why not != ? From pablo at gnumonks.org Thu Apr 7 16:50:32 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 07 Apr 2011 18:50:32 +0200 Subject: [PATCH 6/6] ipaccess-proxy: remove hardcoded IP for options `-l' and `-b' In-Reply-To: <4D9DB11C.9030306@freyther.de> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <1302179277-15975-7-git-send-email-pablo@gnumonks.org> <4D9DB11C.9030306@freyther.de> Message-ID: <4D9DEB58.303@gnumonks.org> On 07/04/11 14:42, Holger Hans Peter Freyther wrote: > On 04/07/2011 02:27 PM, pablo at gnumonks.org wrote: > >> } >> + if (!((options_mask & (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP)) >> + == (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP))) { > > > why not != ? Yes, != looks more readable. Although the line above works fine. I have forced a push with this change that you propose to the pablo/cleanups branch. New patch attached. From pablo at gnumonks.org Thu Apr 7 16:47:39 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 7 Apr 2011 18:47:39 +0200 Subject: [PATCH] ipaccess-proxy: remove hardcoded IP for options `-l' and `-b' Message-ID: This patch removes the hardcoded IP addresses for options `-l' and `-b'. --- openbsc/src/ipaccess/ipaccess-proxy.c | 23 +++++++++++++++++++---- 1 files changed, 19 insertions(+), 4 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index b6dcad1..55658cf 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -1120,11 +1120,19 @@ static void print_help() static void print_usage() { - printf("Usage: ipaccess-proxy\n"); + printf("Usage: ipaccess-proxy [options]\n"); } +enum { + IPA_PROXY_OPT_LISTEN_NONE = 0, + IPA_PROXY_OPT_LISTEN_IP = (1 << 0), + IPA_PROXY_OPT_BSC_IP = (1 << 1), +}; + static void handle_options(int argc, char** argv) { + int options_mask = 0; + while (1) { int option_index = 0, c; static struct option long_options[] = { @@ -1150,9 +1158,11 @@ static void handle_options(int argc, char** argv) exit(0); case 'l': listen_ipaddr = optarg; + options_mask |= IPA_PROXY_OPT_LISTEN_IP; break; case 'b': bsc_ipaddr = optarg; + options_mask |= IPA_PROXY_OPT_BSC_IP; break; case 'g': gprs_ns_ipaddr = optarg; @@ -1171,15 +1181,20 @@ static void handle_options(int argc, char** argv) break; } } + if ((options_mask & (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP)) + != (IPA_PROXY_OPT_LISTEN_IP | IPA_PROXY_OPT_BSC_IP)) { + printf("ERROR: You have to specify `--listen' and `--bsc' " + "options at least.\n"); + print_usage(); + print_help(); + exit(EXIT_FAILURE); + } } int main(int argc, char **argv) { int rc; - listen_ipaddr = "192.168.100.11"; - bsc_ipaddr = "192.168.100.239"; - tall_bsc_ctx = talloc_named_const(NULL, 1, "ipaccess-proxy"); log_init(&log_info); -- 1.7.2.3 --------------020905060808020403000801-- From laforge at gnumonks.org Thu Apr 7 22:44:14 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 8 Apr 2011 00:44:14 +0200 Subject: [PATCH 0/6] openbsc: cleanups for ipaccess tools (2/*) In-Reply-To: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> Message-ID: <20110407224414.GB3239@prithivi.gnumonks.org> Pablo, you're my hero, thanks for cleaning up the mess I left in the proxy. I will delay committing your patddches as I know zecke was also working on some ipaccess related bugfix right now and I don't want to cause unneccessary conflicts. Holger: Can you simply merge pablos patches before/after your fix, whatever you think is appropriate. Regards from Amsterdam, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Apr 7 21:19:29 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 07 Apr 2011 23:19:29 +0200 Subject: [PATCH 0/6] openbsc: cleanups for ipaccess tools (2/*) In-Reply-To: <20110407224414.GB3239@prithivi.gnumonks.org> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <20110407224414.GB3239@prithivi.gnumonks.org> Message-ID: <4D9E2A61.6050604@freyther.de> On 04/08/2011 12:44 AM, Harald Welte wrote: > Pablo, > > you're my hero, thanks for cleaning up the mess I left in the proxy. > > I will delay committing your patddches as I know zecke was also working > on some ipaccess related bugfix right now and I don't want to cause > unneccessary conflicts. > > Holger: Can you simply merge pablos patches before/after your fix, > whatever you think is appropriate. I am trying to do the bisect in some minutes but I don't think Pablo's patches will cause any conflict. So feel free to merge them, I will be out of office tomorrow but can do the merge in the evening. From holger at freyther.de Thu Apr 7 21:31:02 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 07 Apr 2011 23:31:02 +0200 Subject: [PATCH 0/6] openbsc: cleanups for ipaccess tools (2/*) In-Reply-To: <4D9E2A61.6050604@freyther.de> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <20110407224414.GB3239@prithivi.gnumonks.org> <4D9E2A61.6050604@freyther.de> Message-ID: <4D9E2D16.3020705@freyther.de> On 04/07/2011 11:19 PM, Holger Hans Peter Freyther wrote: > > I am trying to do the bisect in some minutes but I don't think Pablo's patches > will cause any conflict. So feel free to merge them, I will be out of office > tomorrow but can do the merge in the evening. Okay, i figured it is easier to just merge it now and then do my changes instead of causing conflicts myself. Pablo, if you have time and harald agrees it would be nice if you could make the ipaccess tag parsing more robust. thanks. holger From laforge at gnumonks.org Fri Apr 8 08:12:40 2011 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 8 Apr 2011 10:12:40 +0200 Subject: [PATCH 0/6] openbsc: cleanups for ipaccess tools (2/*) In-Reply-To: <4D9E2D16.3020705@freyther.de> References: <1302179277-15975-1-git-send-email-pablo@gnumonks.org> <20110407224414.GB3239@prithivi.gnumonks.org> <4D9E2A61.6050604@freyther.de> <4D9E2D16.3020705@freyther.de> Message-ID: <20110408081240.GA790@prithivi.gnumonks.org> On Thu, Apr 07, 2011 at 11:31:02PM +0200, Holger Hans Peter Freyther wrote: > Pablo, if you have time and harald agrees it would be nice if you could make > the ipaccess tag parsing more robust. thanks. ACK. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kobayashi_maru at onlinehome.de Fri Apr 8 12:08:19 2011 From: kobayashi_maru at onlinehome.de (Thomas Ansorg) Date: Fri, 8 Apr 2011 14:08:19 +0200 Subject: handover errormessage Message-ID: hello, one abis_rsl-massage is: CONNECTION FAIL: RELEASE CAUSE=0x18(Siemens: T_MSRFPCI Expired) 01 and handover always ends in a segfault error what does that mean and how can i fix it? T. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Fri Apr 8 12:18:37 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 08 Apr 2011 14:18:37 +0200 Subject: handover errormessage In-Reply-To: References: Message-ID: <4D9EFD1D.4000109@freyther.de> On 04/08/2011 02:08 PM, Thomas Ansorg wrote: > hello, > one abis_rsl-massage is: CONNECTION FAIL: RELEASE CAUSE=0x18(Siemens: > T_MSRFPCI Expired) 01 > and handover always ends in a segfault error please provide a backtrace for the segfault. From lists at infosecurity.ch Sat Apr 9 06:37:20 2011 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Sat, 09 Apr 2011 08:37:20 +0200 Subject: Any plan to fork OpenBTS and/or merge with Osmocom code? Message-ID: <4D9FFEA0.3030904@infosecurity.ch> Hi all, this email don't want to be a provocative email but just an opinion related to the creation of value for GSM TLC stack into the opensource environment. As we know currently there are several different projects growing into the GSM (then tetra and in future 3G?) opensource ecosystem. The first "pratical" base has been OpenBTS as a simplified GSM um interface for VoIP. The second major implementations was around the osmocom project that build-up a complete and well designed GSM stack with all the modular interfaces and protocols for communications between BTS and BSC, with MSC, HLR, GGSN, SGSN and major GSM network components. Additionally, if i understood correctly osmocom is much more advanced with broad scope and better design than OpenBTS. It seems to me that OpenBTS it's almost stalled due to the "commercial fork" of the OpenSource project and only fairwaves is contributing to the opensource branch. I personally really dislike the "Commercial fork" approach where the community is used only in the early phase of the project to improve it and from a certain point the community doesn't get almost any added value. I like much more the dual-licensed approach like AGPL/Commercial (like http://pjsip.org) where all the value of the code is publicly released. However, my post was related to a question: - How complex would be, leveraging existing public OpenBTS code, to integrate into the Osmocom project? I mean, having a sort of lightweight BTS component speaking A-Bis over IP to OpenBSC like the cheap nano ip.access BTS does. For what i read now Osmocom have 2 software BTS (Osmo-BTS and Soft-BTS), communicating with the A-BIS over IP interface to OpenBSC: http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html I've read that only a lot of time ago (2009) there was a discussion about OpenBTS to OpenBSC integration: http://lists.gnumonks.org/pipermail/openbsc/2009-October/000955.html At the current stage of development (2011), with Osmocom finally getting a Software-BTS part communicating to the Software-BSC side, how really complex it would be to integrate the GSM-um related part of OpenBTS into the project? With that approach the 'GSM-um' interface would be a very simplified module of the overall system and osmocom would completely replace OpenBTS all-in-one project. Am i right? -naif p.s. Sorry for the cross-posting, i just wanted to explain the idea and get the communities feedbacks to understand 'at which point' we are in order to think 'what would be required to be done' to achieve that goal. From laforge at gnumonks.org Sat Apr 9 09:24:56 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 9 Apr 2011 11:24:56 +0200 Subject: Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <4D9FFEA0.3030904@infosecurity.ch> References: <4D9FFEA0.3030904@infosecurity.ch> Message-ID: <20110409092456.GB3248@prithivi.gnumonks.org> Hi Fabio, On Sat, Apr 09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote: > this email don't want to be a provocative email but just an opinion > related to the creation of value for GSM TLC stack into the opensource > environment. Sorry, what is TLC? > The first "pratical" base has been OpenBTS as a simplified GSM um > interface for VoIP. well, the Um interface has not been simplified. But the entire fixed-part of the traditional GSM network has been simplified. > The second major implementations was around the osmocom project that > build-up a complete and well designed GSM stack with all the modular > interfaces and protocols for communications between BTS and BSC, with > MSC, HLR, GGSN, SGSN and major GSM network components. true. > Additionally, if i understood correctly osmocom is much more advanced > with broad scope and better design than OpenBTS. I think it is unfair. There are many design decisions, and I don't think you can say something is better or worse. It depends on your purpose. Do you want a sports car or a truck? Depends on your application which one is better... Also with regard to scope, I think there is not too much difference. Sure, the OpenBTS initial focus was on the SDR radiomodem and the actual BTS, while we have been working more on the RAN and now core network parts. but in the end, I guess both projects strive for being able to provide a full gsm network with telephony, sms and data - either stand-alone, as a PBX or interacting with real international GSM networks at various interfaces. > It seems to me that OpenBTS it's almost stalled due to the "commercial > fork" of the OpenSource project and only fairwaves is contributing to > the opensource branch. I cannot comment on that, as I don't follow the speed of progress in OpenBTS. > I personally really dislike the "Commercial fork" approach where the > community is used only in the early phase of the project to improve it > and from a certain point the community doesn't get almost any added value. > I like much more the dual-licensed approach like AGPL/Commercial (like > http://pjsip.org) where all the value of the code is publicly released. I personally agree, but you have to let the project owners / copyright holders decide on that. They wrote the vast majority of the code, and they get to say what happens on the licensing side. But yes, there have been really bad examples of this model before, my personal "negative favorite" is what happened to GNU Zebra after it was commercialized and the successive Quagga fork. I guess today nobody is using the abandoned zebra code base, and everyone uses Quagga. Having said that, I am certain this development/licnesing model can work properly, with satisfaction to both community and commercial interests. However, a lot of care and attention has to be paid on it. In any case, I don't think you should confuse your dislike for that licensing model with a potential combination of OpenBSC and OpenBTS. That latter combination does not require a fork, is not seen as 'aggressive' but is rather a very complimentary approach - for those operators who have legacy GSM infrastructure. See below. > However, my post was related to a question: > > - How complex would be, leveraging existing public OpenBTS code, to > integrate into the Osmocom project? > > I mean, having a sort of lightweight BTS component speaking A-Bis over > IP to OpenBSC like the cheap nano ip.access BTS does. We have been talking for quite some time about adding an A-bis interface to OpenBTS in order to combine it with OpenBSC. This is complementary, and of benefit to both projects. For OpenBSC it means we can not only run with expensive, proprietary BTS vendors but with a Free Software SDR based solution. As for OpenBTS, it means that they might be considered as a RAN provider by GSM operators with legacy equipment. OpenBSC in turn can talk the A interface to a legacy MSC. David Burgess has indicated that they are very much interested in this, for _some_ of their users. It's an alternative, and the main focus for them will likely (and logically) be the VoIP approach. I first attempted to move into that direction during the OpenBTS workshop where I called it 'TrueBTS'. The result was: It's doable, and the layering separation between LAPDm and L3(RR/CC/MM) makes it pretty easy to remove the SIP / L3 part and leave what is left. The only place where actual code changes had to be made was the command interface of OpenBTS, since it references all parts of the code, and was not modular like the rest of OpenBTS. I never had the time to finish this. Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a simplistic BTS), and I have started to split that code out into a separate repository at http://cgit.osmocom.org/cgit/osmo-bts/ This code should eventually be used with the OpenBTS, and potentially other BTS types, too. > At the current stage of development (2011), with Osmocom finally getting > a Software-BTS part communicating to the Software-BSC side, how really > complex it would be to integrate the GSM-um related part of OpenBTS into > the project? It's not really complex, it just needs engineering time. > With that approach the 'GSM-um' interface would be a very simplified > module of the overall system and osmocom would completely replace > OpenBTS all-in-one project. This is where I don't get you. All that needs to be removed is the L3-to-SIP bridge. It doesn't make the vast majority of OpenBTS code disappear, and it does not render that latter part useless. A full-blown GSM network with all its components brings a lot of complexity. The stand-alone OpenBTS is much more simple. And why would you want all the complexity if you don't need to interoperate with legacy GSM? 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 lists at infosecurity.ch Sat Apr 9 20:03:09 2011 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Sat, 09 Apr 2011 22:03:09 +0200 Subject: Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <20110409092456.GB3248@prithivi.gnumonks.org> References: <4D9FFEA0.3030904@infosecurity.ch> <20110409092456.GB3248@prithivi.gnumonks.org> Message-ID: <4DA0BB7D.9000108@infosecurity.ch> On 4/9/11 11:24 AM, Harald Welte wrote: > Hi Fabio, > > On Sat, Apr 09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote: > >> this email don't want to be a provocative email but just an opinion >> related to the creation of value for GSM TLC stack into the opensource >> environment. > > Sorry, what is TLC? I refer to TLC as "Telecommunication" that's the environment and industry segment where our so "friendly" mobile industry players apply patent and NDA everywhere to restrict access to the technology. >> Additionally, if i understood correctly osmocom is much more advanced >> with broad scope and better design than OpenBTS. > > I think it is unfair. There are many design decisions, and I don't think > you can say something is better or worse. It depends on your purpose. Do > you want a sports car or a truck? Depends on your application which one > is better... Absolutely agree, that OpenBTS had very appreciable short term practical goals, such as hooking a GSM phone to Asterisk. While Osmocom had very long term goals, like making a overall set of technologies and libraries usable to build a complete gsm systems, from bsc to baseband, to network analyzer, to ggsn/sgsn, msc, hlr. So imho current status of OpenBTS is near to stalled, without strong opensource improvements. While the current status of Osmocom is growing fast, differentiating itself in various projects, doing important refactoring to create a solid technology stack reusable for most projects. So most of the community investments sounds to be directed to Osmocom. Osmocom now it's missing a complete free hardware/software BTS (for example based on USRP devices). Given it's fast growing community we can forecast in the near future the need to support also the GSMum on USRP devices? Said that, mine is a suggestion to the OpenBTS team to rethink about the future of their projects by directing work to integrate with OpenBSC, empowering the strength of opensource technologies with the respect to such a closed industry (the mobile industry). But for sure, because i am not bringing a single euro to the project, i am just running as a sort of advocacy troll that would like to see in the world a *FULL* and *COMPLETE* opensource gsm technology stack. >> It seems to me that OpenBTS it's almost stalled due to the "commercial >> fork" of the OpenSource project and only fairwaves is contributing to >> the opensource branch. > > I cannot comment on that, as I don't follow the speed of progress in OpenBTS. Well, i just follow the mailing lists and see the code changelog on http://openbts.git.sourceforge.net/git/gitweb.cgi?p=openbts/openbts;a=history;f=public-trunk;hb=HEAD. In the last 10 months there are relatively few changes only done by Sylvain Munaut (mainly working on osmocom stuff as far as i read from mlist) and by Alexander Chemeris (mainly working on the ClockTamer hardware design for OpenBTS). What i know is that several features are only available in commercial version and those are the ones that enable OpenBTS to be used in a real-environment (not just testing). Those features for example are multi ARFCN and handover that are said to be only in the commercial version: http://sourceforge.net/mailarchive/message.php?msg_id=26792703 Those feature are already into OpenBSC: - handover is in OpenBSC code http://laforge.gnumonks.org/weblog/2009/12/21/ - Multi ARFCN / Frequency Hopping is in OpenBSC code http://lists.gnumonks.org/pipermail/openbsc/2010-June/001744.html Eventually a light BTS implementation with the DSP logic integrated with Soft-BTS/OpenBSC would already provide such kind of features, currently available only in OpenBTS commercial implementation. It would also much more easy to be able to see the possible future integration of a GPRS/EDGE endpoint running at home with your own USRP1 with osmo-ggsn. Mine it's just a a way to express that imho this approach maybe represent a stopping issue in seeing really pratically usable opensource gsm technologies, from the bts up to the ggsn passing trough a baseband processor. I think that it would create a lot more adopter of opensource gsm telephony due to the reduction of entrance barrier (costs) of the hardware. Only one piece of hardware of 1500 usd to play with it. > Having said that, I am certain this development/licnesing model can work > properly, with satisfaction to both community and commercial interests. > However, a lot of care and attention has to be paid on it. For the reason explained below i personally think, but i am no-one to affirm this, that the current approach maybe is not the right approach as it's a stopping issue just slowly down what's inevitable and before or later will happen. In such case,typically, before or later there will be some other opensource project or group that solve the need covered only the by commercial code. But that's something that happens before or later with almost any opensource project of great value and interests. > I never had the time to finish this. From laforge at gnumonks.org Sun Apr 10 08:35:53 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 10 Apr 2011 10:35:53 +0200 Subject: Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <4DA0BB7D.9000108@infosecurity.ch> References: <4D9FFEA0.3030904@infosecurity.ch> <20110409092456.GB3248@prithivi.gnumonks.org> <4DA0BB7D.9000108@infosecurity.ch> Message-ID: <20110410083552.GB9690@prithivi.gnumonks.org> Hi again. On Sat, Apr 09, 2011 at 10:03:09PM +0200, Fabio Pietrosanti (naif) wrote: > > On Sat, Apr 09, 2011 at 08:37:20AM +0200, Fabio Pietrosanti (naif) wrote: > > > >> this email don't want to be a provocative email but just an opinion > >> related to the creation of value for GSM TLC stack into the opensource > >> environment. > > > > Sorry, what is TLC? > I refer to TLC as "Telecommunication" that's the environment and > industry segment where our so "friendly" mobile industry players apply > patent and NDA everywhere to restrict access to the technology. > > >> Additionally, if i understood correctly osmocom is much more advanced > >> with broad scope and better design than OpenBTS. > > > > I think it is unfair. There are many design decisions, and I don't think > > you can say something is better or worse. It depends on your purpose. Do > > you want a sports car or a truck? Depends on your application which one > > is better... > > Absolutely agree, that OpenBTS had very appreciable short term practical > goals, such as hooking a GSM phone to Asterisk. it's not just a short-term goal, see David's response ;) > While Osmocom had very long term goals, like making a overall set of > technologies and libraries usable to build a complete gsm systems, from > bsc to baseband, to network analyzer, to ggsn/sgsn, msc, hlr. Making a GSM network that can integrate with an IMS core network without any of the usual components (bsc, sgsn, ...) is not a long-term goal? > So imho current status of OpenBTS is near to stalled, without strong > opensource improvements. > While the current status of Osmocom is growing fast, differentiating > itself in various projects, doing important refactoring to create a > solid technology stack reusable for most projects. well, I would be careful regarding the 'solid' part. Large parts are 'proof of concept' or 'alpha' status at this time. The BSC is very stable, but if you look at the SGSN or the core network parts, it's entirely different > So most of the community investments sounds to be directed to Osmocom. Well, there is a community, but it is a small community, isn't it? Basically Holger and myself on the BSC and core network side, and Sylvain and Andreas doing the majority of the work on the telephone side. Pablo is sort of an exceptional case, as he is doing paid work for me to do his cleanups and improvements. Vance has generously donated his signerl code, for which I'm grateful, but it was written a long time ago and never really 100% finished, so we still have to do a lot of work finishing and integrating it with our other code. The truth is, I don't think there are significantly more people working on Osmocom projects than on OpenBTS. Also, the comparison is odd, as you would probably have to count only the network side projects (BSC, SGSN, ...) on the Osmocom side. > Osmocom now it's missing a complete free hardware/software BTS (for > example based on USRP devices). > > Given it's fast growing community we can forecast in the near future the > need to support also the GSMum on USRP devices? From alexander.chemeris at gmail.com Sun Apr 10 13:40:42 2011 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sun, 10 Apr 2011 17:40:42 +0400 Subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <20110410083552.GB9690@prithivi.gnumonks.org> References: <4D9FFEA0.3030904@infosecurity.ch> <20110409092456.GB3248@prithivi.gnumonks.org> <4DA0BB7D.9000108@infosecurity.ch> <20110410083552.GB9690@prithivi.gnumonks.org> Message-ID: Hi Harald, On Sun, Apr 10, 2011 at 12:35, Harald Welte wrote: > If you use the USRP hardware (or any other SDR hardware), you cannot use > GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. Why do you think that USRP can't support GPRS/EDGE? Is it because of USB latency? And definitely there are SDR hardware which support GPRS/EDGE - it's just more advanced and more integrated then USRP. > Multi-ARFCN: This is an aspect of the radio-modem. ?So again, on the same > hardware any OpenBTS/OpenBSC integration will not change this. Technically, USRP can support multi-ARFCN, but open-source version of OpenBTS doesn't. -- Regards, Alexander Chemeris. http://www.fairwaves.ru From laforge at gnumonks.org Sun Apr 10 14:52:48 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 10 Apr 2011 16:52:48 +0200 Subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: References: <4D9FFEA0.3030904@infosecurity.ch> <20110409092456.GB3248@prithivi.gnumonks.org> <4DA0BB7D.9000108@infosecurity.ch> <20110410083552.GB9690@prithivi.gnumonks.org> Message-ID: <20110410145248.GF9690@prithivi.gnumonks.org> Hi Alexander, On Sun, Apr 10, 2011 at 05:40:42PM +0400, Alexander Chemeris wrote: > On Sun, Apr 10, 2011 at 12:35, Harald Welte wrote: > > If you use the USRP hardware (or any other SDR hardware), you cannot use > > GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. > > Why do you think that USRP can't support GPRS/EDGE? Is it because of > USB latency? no, that's not the point. The point is that you need to implement the CCU and PCU, both of which are not present in OpenBTS. So whether or not you combine OpenBTS with OpenBSC or run OpenBSC stand-alone, it will always have the same features regarding GPRS (or not). > And definitely there are SDR hardware which support GPRS/EDGE - it's > just more advanced and more integrated then USRP. > > > Multi-ARFCN: This is an aspect of the radio-modem. ?So again, on the same > > hardware any OpenBTS/OpenBSC integration will not change this. > > Technically, USRP can support multi-ARFCN, but open-source version of > OpenBTS doesn't. yes. But whether or not you combine OpenBTS with OpenBSC or run OpenBSC stand-alone, it will always have the same features regarding multi-arfcn -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Mon Apr 11 09:00:00 2011 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 11 Apr 2011 13:00:00 +0400 Subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <20110410145248.GF9690@prithivi.gnumonks.org> References: <4D9FFEA0.3030904@infosecurity.ch> <20110409092456.GB3248@prithivi.gnumonks.org> <4DA0BB7D.9000108@infosecurity.ch> <20110410083552.GB9690@prithivi.gnumonks.org> <20110410145248.GF9690@prithivi.gnumonks.org> Message-ID: Hi Harald, On Sun, Apr 10, 2011 at 18:52, Harald Welte wrote: > Hi Alexander, > > On Sun, Apr 10, 2011 at 05:40:42PM +0400, Alexander Chemeris wrote: > >> On Sun, Apr 10, 2011 at 12:35, Harald Welte wrote: >> > If you use the USRP hardware (or any other SDR hardware), you cannot use >> > GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. >> >> Why do you think that USRP can't support GPRS/EDGE? Is it because of >> USB latency? > > no, that's not the point. ?The point is that you need to implement the CCU > and PCU, both of which are not present in OpenBTS. > > So whether or not you combine OpenBTS with OpenBSC or run OpenBSC stand-alone, > it will always have the same features regarding GPRS (or not). Ok, I see your point now. You used words "USRP and other SDR hardware" here and that's what confused me, because hardware can support this feature. It's OpenBTS software limitation, not hardware limitation. >> And definitely there are SDR hardware which support GPRS/EDGE - it's >> just more advanced and more integrated then USRP. >> >> > Multi-ARFCN: This is an aspect of the radio-modem. ?So again, on the same >> > hardware any OpenBTS/OpenBSC integration will not change this. >> >> Technically, USRP can support multi-ARFCN, but open-source version of >> OpenBTS doesn't. > > yes. But whether or not you combine OpenBTS with OpenBSC or run OpenBSC > stand-alone, it will always have the same features regarding multi-arfcn Same here. Thanks for clarification. -- Regards, Alexander Chemeris. http://www.fairwaves.ru From laforge at gnumonks.org Mon Apr 11 17:18:19 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 11 Apr 2011 19:18:19 +0200 Subject: Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <20110410083552.GB9690@prithivi.gnumonks.org> References: <4D9FFEA0.3030904@infosecurity.ch> <20110409092456.GB3248@prithivi.gnumonks.org> <4DA0BB7D.9000108@infosecurity.ch> <20110410083552.GB9690@prithivi.gnumonks.org> Message-ID: <20110411171819.GM9690@prithivi.gnumonks.org> Hi Fabio, I would just like to add: On Sun, Apr 10, 2011 at 10:35:53AM +0200, Harald Welte wrote: > Well, there is a community, but it is a small community, isn't it? Basically > Holger and myself on the BSC and core network side, and Sylvain and Andreas > doing the majority of the work on the telephone side. Pablo is sort of an > exceptional case, as he is doing paid work for me to do his cleanups and > improvements. Vance has generously donated his signerl code, for which I'm > grateful, but it was written a long time ago and never really 100% finished, so > we still have to do a lot of work finishing and integrating it with our other > code. Please let me note that the 'community' is quite a bit larger, I did not want to ignore anyone. I was referring to those developers who actively write substantial parts of the codebase - those are unfortunately few, so my comment remains: > The truth is, I don't think there are significantly more people working on > Osmocom projects than on OpenBTS. Also, the comparison is odd, as you would > probably have to count only the network side projects (BSC, SGSN, ...) on > the Osmocom side. Also, another comment is that most current network-side GSM development is the result of paid work, at least in the case of Holger and me. 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 dburgess at jcis.net Sun Apr 10 05:33:20 2011 From: dburgess at jcis.net (David A. Burgess) Date: Sat, 9 Apr 2011 22:33:20 -0700 Subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <4D9FFEA0.3030904@infosecurity.ch> References: <4D9FFEA0.3030904@infosecurity.ch> Message-ID: <889CD53F-F0AE-4ABC-A44D-58A2786341D3@jcis.net> Fabio - On Apr 8, 2011, at 11:37 PM, Fabio Pietrosanti (naif) wrote: > Hi all, > > this email don't want to be a provocative email but just an opinion > related to the creation of value for GSM TLC stack into the opensource > environment. > > As we know currently there are several different projects growing into > the GSM (then tetra and in future 3G?) opensource ecosystem. > > The first "pratical" base has been OpenBTS as a simplified GSM um > interface for VoIP. > > The second major implementations was around the osmocom project that > build-up a complete and well designed GSM stack with all the modular > interfaces and protocols for communications between BTS and BSC, with > MSC, HLR, GGSN, SGSN and major GSM network components. I think OpenBTS and openbsc were released at very nearly the same time, although neither was aware of the other at the time. > > Additionally, if i understood correctly osmocom is much more advanced > with broad scope and better design than OpenBTS. That depends a great deal on what you are trying to achieve. The two projects are very different in their goals and their implementation approaches. For many applications, the removal of the GSM core network is a great advantage. Also, the OpenBTS approach has more in common with 4G IMS than with 2G legacy networks, so I'm not sure what you mean by "more advanced". > > It seems to me that OpenBTS it's almost stalled due to the "commercial > fork" of the OpenSource project and only fairwaves is contributing to > the opensource branch. > > I personally really dislike the "Commercial fork" approach where the > community is used only in the early phase of the project to improve it > and from a certain point the community doesn't get almost any added value. > I like much more the dual-licensed approach like AGPL/Commercial (like > http://pjsip.org) where all the value of the code is publicly released. We created a commercial fork because we've found that a pure dual-license/non-forked approach is not commercially viable in many of the markets where OpenBTS is being used. (In fact nearly all of the current public GSM code was written or paid for by just two people. We have since replaced or relicensed any previous GPL components in the SDR and GSM stack, allowing us to fork and license OpenBTS however we wish.) There are several reasons for the decision to fork, including government indemnifications for copyright violations by government contractors, suspected violations by commercial interests in inaccessible jurisdictions and specific contractual requirements from project funders to not make a public release of their features. I still personally fully support the GPL and would have preferred a pure dual-license approach, however it simply was not working for the project. The pure public release model was not generating enough income to justify our work and we've found that it was incompatible with our long-term business plan, which is to sell complete GSM/VoIP networks, hardware and software, to commercial customers. Our goal is to provide GSM capabilities with carrier-grade quality to as many people as possible. The amount of our time and money we've invested into the project would surprise most of you and the risks associated with it, professional, personal and financial, have been significant. All that said, we are committed to continue to support the public release of OpenBTS. I would also like to see it become more of a true "community" effort, rather than a small set of people giving their work away to everyone else for free. I realize that will require more active leadership than what has been typical so far. We are committed to organizing the public side of the project and we will are happy to answer any questions clarifying the relationship between the public and commercial releases. > > However, my post was related to a question: > > - How complex would be, leveraging existing public OpenBTS code, to > integrate into the Osmocom project? > > I mean, having a sort of lightweight BTS component speaking A-Bis over > IP to OpenBSC like the cheap nano ip.access BTS does. It would not be difficult to replace most of the OpenBTS control layer with an Abis interface. As Harald Welte described in his own response to this message, we have considered this before, Harald and I have discussed it, and Harald has even done some work in that direction. > For what i read now Osmocom have 2 software BTS (Osmo-BTS and Soft-BTS), > communicating with the A-BIS over IP interface to OpenBSC: > http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html > http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html > > I've read that only a lot of time ago (2009) there was a discussion > about OpenBTS to OpenBSC integration: > http://lists.gnumonks.org/pipermail/openbsc/2009-October/000955.html > > At the current stage of development (2011), with Osmocom finally getting > a Software-BTS part communicating to the Software-BSC side, how really > complex it would be to integrate the GSM-um related part of OpenBTS into > the project? > From the OpenBTS point of view, Abis is interesting only as a mechanism to integrate OpenBTS units into a "legacy" GSM network, and even then only in odd circumstances where other integration methods are not applicable. It is not a preferred mode of operation and thus we do not see the current lack of Abis as a serious shortcoming or design flaw. (In fact, the lack of Abis was a deliberate design decision. Part of the point of OpenBTS was to eliminate many of the things that openbsc is building.) > With that approach the 'GSM-um' interface would be a very simplified > module of the overall system and osmocom would completely replace > OpenBTS all-in-one project. I don't know how well these projects would merge together. The implementation styles are very different. It would also be difficult to find someone to manage such a thing, especially since none of the lead developers on either project seems to have interest in doing that. > > Am i right? > > -naif > > p.s. Sorry for the cross-posting, i just wanted to explain the idea and > get the communities feedbacks to understand 'at which point' we are in > order to think 'what would be required to be done' to achieve that goal. Well, I just cross-posted my reply. So there. :P -- David From james.jordan.fun at gmail.com Mon Apr 11 01:39:54 2011 From: james.jordan.fun at gmail.com (James Jordan) Date: Mon, 11 Apr 2011 09:39:54 +0800 Subject: [Openbts-discuss] Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <4D9FFEA0.3030904@infosecurity.ch> References: <4D9FFEA0.3030904@infosecurity.ch> Message-ID: Fabio, I don't think openbts and Osmocom should be integrated together. If you want to integrated them the source is there. I don't think there is any wrong in Commercial version. Openbts is the inteligient property to their owner. there is nothing wrong even the source is totally not open. Can anyone get the approve by the government to build truely free gsm network? On Sat, Apr 9, 2011 at 2:37 PM, Fabio Pietrosanti (naif) < lists at infosecurity.ch> wrote: > Hi all, > > this email don't want to be a provocative email but just an opinion > related to the creation of value for GSM TLC stack into the opensource > environment. > > As we know currently there are several different projects growing into > the GSM (then tetra and in future 3G?) opensource ecosystem. > > The first "pratical" base has been OpenBTS as a simplified GSM um > interface for VoIP. > > The second major implementations was around the osmocom project that > build-up a complete and well designed GSM stack with all the modular > interfaces and protocols for communications between BTS and BSC, with > MSC, HLR, GGSN, SGSN and major GSM network components. > > Additionally, if i understood correctly osmocom is much more advanced > with broad scope and better design than OpenBTS. > > It seems to me that OpenBTS it's almost stalled due to the "commercial > fork" of the OpenSource project and only fairwaves is contributing to > the opensource branch. > > I personally really dislike the "Commercial fork" approach where the > community is used only in the early phase of the project to improve it > and from a certain point the community doesn't get almost any added value. > I like much more the dual-licensed approach like AGPL/Commercial (like > http://pjsip.org) where all the value of the code is publicly released. > > However, my post was related to a question: > > - How complex would be, leveraging existing public OpenBTS code, to > integrate into the Osmocom project? > > I mean, having a sort of lightweight BTS component speaking A-Bis over > IP to OpenBSC like the cheap nano ip.access BTS does. > > For what i read now Osmocom have 2 software BTS (Osmo-BTS and Soft-BTS), > communicating with the A-BIS over IP interface to OpenBSC: > http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html > http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html > > I've read that only a lot of time ago (2009) there was a discussion > about OpenBTS to OpenBSC integration: > http://lists.gnumonks.org/pipermail/openbsc/2009-October/000955.html > > At the current stage of development (2011), with Osmocom finally getting > a Software-BTS part communicating to the Software-BSC side, how really > complex it would be to integrate the GSM-um related part of OpenBTS into > the project? > > With that approach the 'GSM-um' interface would be a very simplified > module of the overall system and osmocom would completely replace > OpenBTS all-in-one project. > > Am i right? > > -naif > > p.s. Sorry for the cross-posting, i just wanted to explain the idea and > get the communities feedbacks to understand 'at which point' we are in > order to think 'what would be required to be done' to achieve that goal. > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > 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 f.koliqi at gmail.com Wed Apr 13 03:46:48 2011 From: f.koliqi at gmail.com (Fadil Berisha) Date: Tue, 12 Apr 2011 23:46:48 -0400 Subject: Any plan to fork OpenBTS and/or merge with Osmocom code? In-Reply-To: <4D9FFEA0.3030904@infosecurity.ch> References: <4D9FFEA0.3030904@infosecurity.ch> Message-ID: Hi Fabio, > For what i read now Osmocom have 2 software BTS (Osmo-BTS and Soft-BTS), > communicating with the A-BIS over IP interface to OpenBSC: > http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html > http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html Now we have two software BTS in developing phase, softBTS and osmoBTS, In A-bis side, both communicating with OpenBSC using ipaccess style A-bis over IP protocol. Probably difference would be in Um side. I am not considering Universal Software Radio Peripheral as hardware for softBTS, that mean no plans to use openBTS as bridge to USRP. fadil From holger at freyther.de Sat Apr 9 07:37:56 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 09 Apr 2011 09:37:56 +0200 Subject: ipaccess-config perforning tests is broken Message-ID: <4DA00CD4.8090505@freyther.de> Hi Harald, I bisected this and I end at the commit that moves bsc_init.c code around and moves things to signals. Out of your head would you know if ipaccess-config needs to call some other init function or do something special? If not I will dig a bit more and come back with more details. holger From mailman-bounces at lists.osmocom.org Mon Apr 11 07:00:02 2011 From: mailman-bounces at lists.osmocom.org (mailman-bounces at lists.osmocom.org) Date: Mon, 11 Apr 2011 09:00:02 +0200 Subject: OpenBSC unsubscribe notification Message-ID: so29 at onlinehome.de has been removed from OpenBSC. From pablo at gnumonks.org Mon Apr 11 15:04:23 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:23 +0200 Subject: [PATCH 0/7] openbsc: cleanups for ipaccess tools (3/*) Message-ID: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patchset is the third in the series to cleanup code in ipaccess tools and drivers. They have been tested by bootstraping the nanoBTS successfully in a small setup with two laptops, one acting as proxy and another with osmo-nitb. They are available in the pablo/cleanups branch in openbsc git tree. BTW: I'm going to stop a bit with cleanups to add a VTY interface for ipaccess-proxy, as Harald suggested. Please, merge it! Thanks. Pablo Neira Ayuso (7): libabis: ipaccess: more robust ipaccess_idtag_name() src: more robust ipaccess_idtag_parse() libabis: ipaccess: use log instead of debug under errors in ipaccess_send() ipaccess-find: get rid of ipac_idtag_name() ipaccess-proxy: more robust option parsing and checking ipaccess-proxy: remove leftover option `--udp' ipaccess-proxy: get rid of make_gprs_sock() openbsc/include/openbsc/ipaccess.h | 2 +- openbsc/src/ipaccess/Makefile.am | 6 +++ openbsc/src/ipaccess/ipaccess-find.c | 22 +------------ openbsc/src/ipaccess/ipaccess-proxy.c | 56 +++++++++++++-------------------- openbsc/src/libabis/input/ipaccess.c | 18 ++++++---- openbsc/src/osmo-bsc_nat/bsc_nat.c | 8 ++++- openbsc/src/osmo-bsc_nat/bsc_ussd.c | 8 ++++- 7 files changed, 55 insertions(+), 65 deletions(-) -- 1.7.2.3 From pablo at gnumonks.org Mon Apr 11 15:04:24 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:24 +0200 Subject: [PATCH 1/7] libabis: ipaccess: more robust ipaccess_idtag_name() In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso ipaccess_idtag_name() now takes a uint8_t as parameter which is the length of the type tag. This patch was suggested by Zecke. --- openbsc/include/openbsc/ipaccess.h | 2 +- openbsc/src/libabis/input/ipaccess.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index 00642ff..0edd81d 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -79,7 +79,7 @@ int ipaccess_send_pong(int fd); int ipaccess_send_id_ack(int fd); int ipaccess_send_id_req(int fd); -const char *ipaccess_idtag_name(int tag); +const char *ipaccess_idtag_name(uint8_t tag); int ipaccess_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len); int ipaccess_parse_unitid(const char *str, u_int16_t *site_id, u_int16_t *bts_id, u_int16_t *trx_id); diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index e1e314b..c4c13d7 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -100,7 +100,7 @@ static const char *idtag_names[] = { [IPAC_IDTAG_UNIT] = "Unit_ID", }; -const char *ipaccess_idtag_name(int tag) +const char *ipaccess_idtag_name(uint8_t tag) { if (tag >= ARRAY_SIZE(idtag_names)) return "unknown"; -- 1.7.2.3 From pablo at gnumonks.org Mon Apr 11 15:04:25 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:25 +0200 Subject: [PATCH 2/7] src: more robust ipaccess_idtag_parse() In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-3-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Now ipaccess_idtag_parse() returns -EINVAL instead of -1. We also check for the return value of this function in every invocation to skip further processing in case of messages with malformed TLVs. This idea was suggested by Zecke. --- openbsc/src/libabis/input/ipaccess.c | 14 +++++++++----- openbsc/src/osmo-bsc_nat/bsc_nat.c | 8 +++++++- openbsc/src/osmo-bsc_nat/bsc_ussd.c | 8 +++++++- 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index c4c13d7..ba641a8 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -123,7 +123,7 @@ int ipaccess_idtag_parse(struct tlv_parsed *dec, unsigned char *buf, int len) if (t_len > len + 1) { LOGP(DMI, LOGL_ERROR, "The tag does not fit: %d\n", t_len); - return -1; + return -EINVAL; } DEBUGPC(DMI, "%s='%s' ", ipaccess_idtag_name(t_tag), cur); @@ -251,7 +251,7 @@ static int ipaccess_rcvmsg(struct e1inp_line *line, struct msgb *msg, u_int16_t site_id = 0, bts_id = 0, trx_id = 0; struct gsm_bts *bts; char *unitid; - int len; + int len, ret; /* handle base messages */ ipaccess_rcvmsg_base(msg, bfd); @@ -260,10 +260,14 @@ static int ipaccess_rcvmsg(struct e1inp_line *line, struct msgb *msg, case IPAC_MSGT_ID_RESP: DEBUGP(DMI, "ID_RESP "); /* parse tags, search for Unit ID */ - ipaccess_idtag_parse(&tlvp, (u_int8_t *)msg->l2h + 2, - msgb_l2len(msg)-2); + ret = ipaccess_idtag_parse(&tlvp, (u_int8_t *)msg->l2h + 2, + msgb_l2len(msg)-2); DEBUGP(DMI, "\n"); - + if (ret < 0) { + LOGP(DINP, LOGL_ERROR, "ignoring IPA response message " + "with malformed TLVs\n"); + return ret; + } if (!TLVP_PRESENT(&tlvp, IPAC_IDTAG_UNIT)) break; diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 7586294..8c164a2 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -1019,9 +1019,15 @@ exit: /* do we know who is handling this? */ if (msg->l2h[0] == IPAC_MSGT_ID_RESP) { struct tlv_parsed tvp; - ipaccess_idtag_parse(&tvp, + int ret; + ret = ipaccess_idtag_parse(&tvp, (unsigned char *) msg->l2h + 2, msgb_l2len(msg) - 2); + if (ret < 0) { + LOGP(DNAT, LOGL_ERROR, "ignoring IPA response " + "message with malformed TLVs\n"); + return ret; + } if (TLVP_PRESENT(&tvp, IPAC_IDTAG_UNITNAME)) ipaccess_auth_bsc(&tvp, bsc); } diff --git a/openbsc/src/osmo-bsc_nat/bsc_ussd.c b/openbsc/src/osmo-bsc_nat/bsc_ussd.c index ff1d27a..4beef7b 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_ussd.c +++ b/openbsc/src/osmo-bsc_nat/bsc_ussd.c @@ -123,9 +123,15 @@ static int ussd_read_cb(struct bsc_fd *bfd) if (hh->proto == IPAC_PROTO_IPACCESS) { if (msg->l2h[0] == IPAC_MSGT_ID_RESP) { struct tlv_parsed tvp; - ipaccess_idtag_parse(&tvp, + int ret; + ret = ipaccess_idtag_parse(&tvp, (unsigned char *) msg->l2h + 2, msgb_l2len(msg) - 2); + if (ret < 0) { + LOGP(DNAT, LOGL_ERROR, "ignoring IPA response " + "message with malformed TLVs\n"); + return ret; + } if (TLVP_PRESENT(&tvp, IPAC_IDTAG_UNITNAME)) ussd_auth_con(&tvp, conn); } -- 1.7.2.3 From holger at freyther.de Mon Apr 11 15:52:04 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 11 Apr 2011 17:52:04 +0200 Subject: [PATCH 2/7] src: more robust ipaccess_idtag_parse() In-Reply-To: <1302534270-7850-3-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> <1302534270-7850-3-git-send-email-pablo@gnumonks.org> Message-ID: <4DA323A4.4010805@freyther.de> On 04/11/2011 05:04 PM, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > Thanks, IIRC there is another issue here. We assume that the strings on the wire contain a '\0', e.g. in the printf statements we rely on this. So we could either put this in there or do something else. thanks holger From pablo at gnumonks.org Tue Apr 12 17:55:30 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 12 Apr 2011 19:55:30 +0200 Subject: [PATCH 2/7] src: more robust ipaccess_idtag_parse() In-Reply-To: <4DA323A4.4010805@freyther.de> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> <1302534270-7850-3-git-send-email-pablo@gnumonks.org> <4DA323A4.4010805@freyther.de> Message-ID: <4DA49212.1080102@gnumonks.org> Hi Holger, On 11/04/11 17:52, Holger Hans Peter Freyther wrote: > On 04/11/2011 05:04 PM, pablo at gnumonks.org wrote: >> From: Pablo Neira Ayuso >> > > Thanks, IIRC there is another issue here. We assume that the strings on the > wire contain a '\0', e.g. in the printf statements we rely on this. So we > could either put this in there or do something else. Can I assume that all IPAC_IDTAG_* are all strings? I mean all of these: [IPAC_IDTAG_SERNR] = "Serial_Number", [IPAC_IDTAG_UNITNAME] = "Unit_Name", [IPAC_IDTAG_LOCATION1] = "Location_1", [IPAC_IDTAG_LOCATION2] = "Location_2", [IPAC_IDTAG_EQUIPVERS] = "Equipment_Version", [IPAC_IDTAG_SWVERSION] = "Software_Version", [IPAC_IDTAG_IPADDR] = "IP_Address", [IPAC_IDTAG_MACADDR] = "MAC_Address", [IPAC_IDTAG_UNIT] = "Unit_ID", If so, I'll send a patch to check for the trailing \0 to: dec->lv[t_tag].val = cur; Sorry, I didn't get you in the first hand, I'm not ignoring your requests :-). Let me know if this is not what you mean. From holger at freyther.de Wed Apr 13 11:38:41 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 13 Apr 2011 13:38:41 +0200 Subject: [PATCH 2/7] src: more robust ipaccess_idtag_parse() In-Reply-To: <4DA49212.1080102@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> <1302534270-7850-3-git-send-email-pablo@gnumonks.org> <4DA323A4.4010805@freyther.de> <4DA49212.1080102@gnumonks.org> Message-ID: <4DA58B41.1010008@freyther.de> On 04/12/2011 07:55 PM, Pablo Neira Ayuso wrote: >> Thanks, IIRC there is another issue here. We assume that the strings on the >> wire contain a '\0', e.g. in the printf statements we rely on this. So we >> could either put this in there or do something else. > > Can I assume that all IPAC_IDTAG_* are all strings? I'm sorry. I do not know. > If so, I'll send a patch to check for the trailing \0 to: > > dec->lv[t_tag].val = cur; > > Sorry, I didn't get you in the first hand, I'm not ignoring your > requests :-). > > Let me know if this is not what you mean. It would be good to find out which of these tags have the null termination and which not. holger From pablo at gnumonks.org Mon Apr 11 15:04:26 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:26 +0200 Subject: [PATCH 3/7] libabis: ipaccess: use log instead of debug under errors in ipaccess_send() In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-4-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch was suggested by Zecke. --- openbsc/src/libabis/input/ipaccess.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index ba641a8..cba03a0 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -200,7 +200,7 @@ static int ipaccess_send(int fd, const void *msg, size_t msglen) if (ret < 0) return ret; if (ret < msglen) { - DEBUGP(DINP, "ipaccess_send: short write\n"); + LOGP(DINP, LOGL_ERROR, "ipaccess_send: short write\n"); return -EIO; } return ret; -- 1.7.2.3 From pablo at gnumonks.org Mon Apr 11 15:04:27 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:27 +0200 Subject: [PATCH 4/7] ipaccess-find: get rid of ipac_idtag_name() In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-5-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Use generic ipaccess_idtag_name() available in libabis instead. --- openbsc/src/ipaccess/Makefile.am | 6 ++++++ openbsc/src/ipaccess/ipaccess-find.c | 22 +--------------------- 2 files changed, 7 insertions(+), 21 deletions(-) diff --git a/openbsc/src/ipaccess/Makefile.am b/openbsc/src/ipaccess/Makefile.am index cff3505..4fe1e37 100644 --- a/openbsc/src/ipaccess/Makefile.am +++ b/openbsc/src/ipaccess/Makefile.am @@ -4,6 +4,12 @@ AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(COVERAGE_LDFLAGS) bin_PROGRAMS = ipaccess-find ipaccess-config ipaccess-proxy +ipaccess_find_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ + $(top_builddir)/src/libmsc/libmsc.a \ + $(top_builddir)/src/libabis/libabis.a \ + $(top_builddir)/src/libbsc/libbsc.a \ + $(top_builddir)/src/libtrau/libtrau.a \ + $(top_builddir)/src/libcommon/libcommon.a ipaccess_find_SOURCES = ipaccess-find.c ipaccess_config_SOURCES = ipaccess-config.c ipaccess-firmware.c network_listen.c diff --git a/openbsc/src/ipaccess/ipaccess-find.c b/openbsc/src/ipaccess/ipaccess-find.c index a273609..987e35c 100644 --- a/openbsc/src/ipaccess/ipaccess-find.c +++ b/openbsc/src/ipaccess/ipaccess-find.c @@ -32,26 +32,6 @@ #include #include -static const char *idtag_names[] = { - [IPAC_IDTAG_SERNR] = "Serial Number", - [IPAC_IDTAG_UNITNAME] = "Unit Name", - [IPAC_IDTAG_LOCATION1] = "Location 1", - [IPAC_IDTAG_LOCATION2] = "Location 2", - [IPAC_IDTAG_EQUIPVERS] = "Equipment Version", - [IPAC_IDTAG_SWVERSION] = "Software Version", - [IPAC_IDTAG_IPADDR] = "IP Address", - [IPAC_IDTAG_MACADDR] = "MAC Address", - [IPAC_IDTAG_UNIT] = "Unit ID", -}; - -static const char *ipac_idtag_name(int tag) -{ - if (tag >= ARRAY_SIZE(idtag_names)) - return "unknown"; - - return idtag_names[tag]; -} - static int udp_sock(const char *ifname) { int fd, rc, bc = 1; @@ -133,7 +113,7 @@ static int parse_response(unsigned char *buf, int len) t_len = *cur++; t_tag = *cur++; - printf("%s='%s' ", ipac_idtag_name(t_tag), cur); + printf("%s='%s' ", ipaccess_idtag_name(t_tag), cur); cur += t_len; } -- 1.7.2.3 From pablo at gnumonks.org Mon Apr 11 15:04:28 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:28 +0200 Subject: [PATCH 5/7] ipaccess-proxy: more robust option parsing and checking In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-6-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso With this patch, ipaccess-proxy makes more robust option checking: $ ./ipaccess-proxy -l 1.1.1.1 -b 2.2.2.2 -e ERROR: missing mandatory argument for `-e' option And we return to shell to enforce the user to try again with the appropriate invocation. Before this patch, the default getopt_long() error handling was enabled which displayed this message: ./ipaccess-proxy: option requires an argument -- 'e' and ipaccess-proxy continued working. This is generic enough to cover other option that require mandatory arguments like `--bsc' and `--listen'. --- openbsc/src/ipaccess/ipaccess-proxy.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index 55658cf..dd0a739 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -1133,6 +1133,9 @@ static void handle_options(int argc, char** argv) { int options_mask = 0; + /* disable explicit missing arguments error output from getopt_long */ + opterr = 0; + while (1) { int option_index = 0, c; static struct option long_options[] = { @@ -1176,6 +1179,18 @@ static void handle_options(int argc, char** argv) case 'e': log_set_log_level(stderr_target, atoi(optarg)); break; + case '?': + if (optopt) { + printf("ERROR: missing mandatory argument " + "for `%s' option\n", argv[optind-1]); + } else { + printf("ERROR: unknown option `%s'\n", + argv[optind-1]); + } + print_usage(); + print_help(); + exit(EXIT_FAILURE); + break; default: /* ignore */ break; -- 1.7.2.3 From pablo at gnumonks.org Mon Apr 11 15:04:29 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:29 +0200 Subject: [PATCH 6/7] ipaccess-proxy: remove leftover option `--udp' In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-7-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso It seems it remains unimplemented, remove it. --- openbsc/src/ipaccess/ipaccess-proxy.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index dd0a739..4dd6ee5 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -1145,7 +1145,6 @@ static void handle_options(int argc, char** argv) {"log-level", 1, 0, 'e'}, {"listen", 1, 0, 'l'}, {"bsc", 1, 0, 'b'}, - {"udp", 1, 0, 'u'}, {0, 0, 0, 0} }; -- 1.7.2.3 From pablo at gnumonks.org Mon Apr 11 15:04:30 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 11 Apr 2011 17:04:30 +0200 Subject: [PATCH 7/7] ipaccess-proxy: get rid of make_gprs_sock() In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <1302534270-7850-8-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso It is similar to make_sock() available in openbsc/libcommon. --- openbsc/src/ipaccess/ipaccess-proxy.c | 40 +++++--------------------------- 1 files changed, 7 insertions(+), 33 deletions(-) diff --git a/openbsc/src/ipaccess/ipaccess-proxy.c b/openbsc/src/ipaccess/ipaccess-proxy.c index 4dd6ee5..5254959 100644 --- a/openbsc/src/ipaccess/ipaccess-proxy.c +++ b/openbsc/src/ipaccess/ipaccess-proxy.c @@ -126,7 +126,6 @@ static char *listen_ipaddr; static char *bsc_ipaddr; static char *gprs_ns_ipaddr; -static int make_gprs_sock(struct bsc_fd *bfd, int (*cb)(struct bsc_fd*,unsigned int), void *); static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what); #define PROXY_ALLOC_SIZE 1200 @@ -389,7 +388,13 @@ static int ipbc_alloc_connect(struct ipa_proxy_conn *ipc, struct bsc_fd *bfd, if (gprs_ns_ipaddr) { struct sockaddr_in sock; socklen_t len = sizeof(sock); - ret = make_gprs_sock(&ipbc->gprs_ns_fd, gprs_ns_cb, ipbc); + struct in_addr addr; + uint32_t ip; + + inet_aton(listen_ipaddr, &addr); + ip = ntohl(addr.s_addr); /* make_sock() needs host byte order */ + ret = make_sock(&ipbc->gprs_ns_fd, IPPROTO_UDP, ip, 0, 0, + gprs_ns_cb, ipbc); if (ret < 0) { LOGP(DINP, LOGL_ERROR, "Creating the GPRS socket failed.\n"); goto err_udp_bsc; @@ -982,37 +987,6 @@ static int gprs_ns_cb(struct bsc_fd *bfd, unsigned int what) return 0; } -static int make_gprs_sock(struct bsc_fd *bfd, int (*cb)(struct bsc_fd*,unsigned int), void *data) -{ - struct sockaddr_in addr; - int ret; - - bfd->fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); - bfd->cb = cb; - bfd->data = data; - bfd->when = BSC_FD_READ; - - memset(&addr, 0, sizeof(addr)); - addr.sin_family = AF_INET; - addr.sin_port = 0; - inet_aton(listen_ipaddr, &addr.sin_addr); - - ret = bind(bfd->fd, (struct sockaddr *) &addr, sizeof(addr)); - if (ret < 0) { - LOGP(DINP, LOGL_ERROR, - "Could not bind n socket for IP %s with error: %s.\n", - listen_ipaddr, strerror(errno)); - return -EIO; - } - - ret = bsc_register_fd(bfd); - if (ret < 0) { - perror("register_listen_fd"); - return ret; - } - return 0; -} - /* Actively connect to a BSC. */ static struct ipa_proxy_conn *connect_bsc(struct sockaddr_in *sa, int priv_nr, void *data) { -- 1.7.2.3 From laforge at gnumonks.org Mon Apr 11 17:14:28 2011 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 11 Apr 2011 19:14:28 +0200 Subject: [PATCH 0/7] openbsc: cleanups for ipaccess tools (3/*) In-Reply-To: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> Message-ID: <20110411171428.GL9690@prithivi.gnumonks.org> Hi Pablo, On Mon, Apr 11, 2011 at 05:04:23PM +0200, pablo at gnumonks.org wrote: > They are available in the pablo/cleanups branch in openbsc git tree. > > BTW: I'm going to stop a bit with cleanups to add a VTY interface > for ipaccess-proxy, as Harald suggested. > > Please, merge it! thanks, merged! -- - 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 Tue Apr 12 17:56:29 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 12 Apr 2011 19:56:29 +0200 Subject: [PATCH 0/7] openbsc: cleanups for ipaccess tools (3/*) In-Reply-To: <20110411171428.GL9690@prithivi.gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> <20110411171428.GL9690@prithivi.gnumonks.org> Message-ID: <4DA4924D.7080004@gnumonks.org> On 11/04/11 19:14, Harald Welte wrote: > Hi Pablo, > > On Mon, Apr 11, 2011 at 05:04:23PM +0200, pablo at gnumonks.org wrote: > >> They are available in the pablo/cleanups branch in openbsc git tree. >> >> BTW: I'm going to stop a bit with cleanups to add a VTY interface >> for ipaccess-proxy, as Harald suggested. >> >> Please, merge it! > > thanks, merged! Hm, I don't see them in the master branch, still in your local tree? From laforge at gnumonks.org Tue Apr 12 19:51:01 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 12 Apr 2011 21:51:01 +0200 Subject: [PATCH 0/7] openbsc: cleanups for ipaccess tools (3/*) In-Reply-To: <4DA4924D.7080004@gnumonks.org> References: <1302534270-7850-1-git-send-email-pablo@gnumonks.org> <20110411171428.GL9690@prithivi.gnumonks.org> <4DA4924D.7080004@gnumonks.org> Message-ID: <20110412195101.GA32563@prithivi.gnumonks.org> On Tue, Apr 12, 2011 at 07:56:29PM +0200, Pablo Neira Ayuso wrote: > On 11/04/11 19:14, Harald Welte wrote: > > Hi Pablo, > > > > On Mon, Apr 11, 2011 at 05:04:23PM +0200, pablo at gnumonks.org wrote: > > > >> They are available in the pablo/cleanups branch in openbsc git tree. > >> > >> BTW: I'm going to stop a bit with cleanups to add a VTY interface > >> for ipaccess-proxy, as Harald suggested. > >> > >> Please, merge it! > > > > thanks, merged! > > Hm, I don't see them in the master branch, still in your local tree? yes, sorry. fixed now. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From meierk at informatik.uni-freiburg.de Wed Apr 13 11:10:54 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Wed, 13 Apr 2011 13:10:54 +0200 Subject: nanoBTS multi-TRX setup Message-ID: <4DA584BE.9070700@informatik.uni-freiburg.de> Hi all, I was just reading the wiki page about the nanoBTS multi-TRX setup. Two things are not clear to me. 1. What is the purpose of the "RF cable"? Is the TX port of the master BTS looped through the second BTS? Or hase every nanoBTS his own TRX/RX? I am asking because I would like to use a nanoBTS-Booster with the multi-TRX setup and therefore require a combined RF signal. 2. The example example "openbsc.cfg" configures the trx 1 as follows: timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 Is this really needed? My first idea was to configure the second trx to TCH/F only. Best regards Konrad Meier From 246tnt at gmail.com Wed Apr 13 12:00:01 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 13 Apr 2011 14:00:01 +0200 Subject: nanoBTS multi-TRX setup In-Reply-To: <4DA584BE.9070700@informatik.uni-freiburg.de> References: <4DA584BE.9070700@informatik.uni-freiburg.de> Message-ID: Hi, > 1. What is the purpose of the "RF cable"? > Is the TX port of the master BTS looped through the second BTS? Or hase > every nanoBTS his own TRX/RX? > I am asking because I would like to use a nanoBTS-Booster with the multi-TRX > setup and therefore require a combined RF signal. I'm not entirely sure, but I think that's just the reference clock ? But in any case you can use splitter / combiner for both the RX and TX path. You will loose 3dB on the RX path because of the split but that might be ok with you if you have a LNA before hand anyway. > 2. The example example "openbsc.cfg" configures the trx 1 as follows: > > ?timeslot 0 > ? ?phys_chan_config CCCH+SDCCH4 > ?timeslot 1 > ? ?phys_chan_config SDCCH8 No, all TCH should work fine. Cheers, Sylvain From laforge at gnumonks.org Wed Apr 13 12:30:18 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 13 Apr 2011 14:30:18 +0200 Subject: nanoBTS multi-TRX setup In-Reply-To: <4DA584BE.9070700@informatik.uni-freiburg.de> References: <4DA584BE.9070700@informatik.uni-freiburg.de> Message-ID: <20110413123018.GM4388@prithivi.gnumonks.org> On Wed, Apr 13, 2011 at 01:10:54PM +0200, Konrad Meier wrote: > Hi all, > > I was just reading the wiki page about the nanoBTS multi-TRX setup. > Two things are not clear to me. > > 1. What is the purpose of the "RF cable"? that is unclear, we don't have documentation on it.. The TIB (timing interface bus) cable is obvious: to synchronize timing. The OML gets routed via the ethernet ports. So I don't really know why they need an extra RF cable... > Is the TX port of the master BTS looped through the second BTS? Or > hase every nanoBTS his own TRX/RX? NO !!! my god, you don't want to kill your BTSs. Tx / Rx is separate like before. > I am asking because I would like to use a nanoBTS-Booster with the > multi-TRX setup and therefore require a combined RF signal. the best idea is to use independent boosters. If you want to run two TRX nanoBTS throguh one amplifier, you need high-grade RF combiner, make sure the amplifier doesn't produce intermodulation, etc. Definitely not something you want to be doing without somebody who has a clue about proper RF setups at those frequencies. > 2. The example example "openbsc.cfg" configures the trx 1 as follows: > > timeslot 0 > phys_chan_config CCCH+SDCCH4 > timeslot 1 > phys_chan_config SDCCH8 > > Is this really needed? My first idea was to configure the second trx > to TCH/F only. That depends on your network requirements, you can of course have all TCH/F. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From spaar at mirider.augusta.de Wed Apr 13 15:23:48 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 13 Apr 2011 15:23:48 CEST Subject: nanoBTS multi-TRX setup Message-ID: <4da5c005.mirider@mirider.augusta.de> Hello Konrad, On Wed, 13 Apr 2011 13:10:54 +0200, "Konrad Meier" wrote: > > 1. What is the purpose of the "RF cable"? > Is the TX port of the master BTS looped through the second BTS? Or hase > every nanoBTS his own TRX/RX? The RF cable is used to route TX from the rear unit to the AUX connector of the front unit. The SMB socket at the back and AUX are directly connected, there is nothing special about them. So in a stacked two-units assembly the front unit also has the TRX antenna of the rear unit at the AUX connector. Most certainly the idea is to improve transmission of the rear unit or to better separate the two TRX antennas. So TX is looped through one unit but the two TX signals are not combined. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From meierk at informatik.uni-freiburg.de Wed Apr 13 14:16:01 2011 From: meierk at informatik.uni-freiburg.de (Konrad Meier) Date: Wed, 13 Apr 2011 16:16:01 +0200 Subject: nanoBTS multi-TRX setup In-Reply-To: <4da5c005.mirider@mirider.augusta.de> References: <4da5c005.mirider@mirider.augusta.de> Message-ID: <4DA5B021.4070007@informatik.uni-freiburg.de> Am 13.04.2011 15:23, schrieb Dieter Spaar: > Hello Konrad, > > On Wed, 13 Apr 2011 13:10:54 +0200, "Konrad Meier" wrote: >> >> 1. What is the purpose of the "RF cable"? >> Is the TX port of the master BTS looped through the second BTS? Or hase >> every nanoBTS his own TRX/RX? > > The RF cable is used to route TX from the rear unit to the AUX connector > of the front unit. The SMB socket at the back and AUX are directly connected, > there is nothing special about them. So in a stacked two-units assembly > the front unit also has the TRX antenna of the rear unit at the AUX connector. > Most certainly the idea is to improve transmission of the rear unit or to > better separate the two TRX antennas. > > So TX is looped through one unit but the two TX signals are not combined. Thank you. This made it clear. I thought about the same setup but was hoping that the TRX signal is combined. Any idea what the NWL connector is for? Best regards Konrad From spaar at mirider.augusta.de Wed Apr 13 17:02:25 2011 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 13 Apr 2011 17:02:25 CEST Subject: nanoBTS multi-TRX setup Message-ID: <4da5d721.mirider@mirider.augusta.de> Hello Konrad, On Wed, 13 Apr 2011 16:16:01 +0200, "Konrad Meier" wrote: > > Any idea what the NWL connector is for? Its the Rx Antenna for the "Network Listen" feature of the nanoBTS, its used for receiving the downlink of other basestations. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From admin at manateeshome.com Wed Apr 13 11:51:37 2011 From: admin at manateeshome.com (Seungju Kim) Date: Wed, 13 Apr 2011 07:51:37 -0400 Subject: How can I calibrate the clock of nanobts? Message-ID: <44F2C750-05D4-4834-9ED6-4201476895DE@manateeshome.com> How can I calibrate the clock of the nanobts? I looked through the mailing list and all I have found is that it is not implemented.... Sent from my iPhone From holger at freyther.de Wed Apr 13 13:12:29 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 13 Apr 2011 15:12:29 +0200 Subject: How can I calibrate the clock of nanobts? In-Reply-To: <44F2C750-05D4-4834-9ED6-4201476895DE@manateeshome.com> References: <44F2C750-05D4-4834-9ED6-4201476895DE@manateeshome.com> Message-ID: <4DA5A13D.1070104@freyther.de> On 04/13/2011 01:51 PM, Seungju Kim wrote: > How can I calibrate the clock of the nanobts? > I looked through the mailing list and all I have found is that it is not implemented.... We would need a trace from someone using the BTS Installer (i assume it does the calibration) and then could implement it. holger From ammar_naamat1 at yahoo.com Thu Apr 14 09:25:42 2011 From: ammar_naamat1 at yahoo.com (Ammar Naamat Hameed) Date: Thu, 14 Apr 2011 02:25:42 -0700 (PDT) Subject: Using openBSC as MSC Message-ID: <257589.193.qm@web45202.mail.sp1.yahoo.com> Dear All,? Is it possible to use openbsc as MSC, VLR and HLR without using nanBTS as i'm?trying?to develop an SMSC.In other words, to make it work as MSC,HLR emulator with dummy subscribers? Regards, Ammar -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Apr 14 11:35:19 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 14 Apr 2011 13:35:19 +0200 Subject: Using openBSC as MSC In-Reply-To: <257589.193.qm@web45202.mail.sp1.yahoo.com> References: <257589.193.qm@web45202.mail.sp1.yahoo.com> Message-ID: <20110414113519.GZ4388@prithivi.gnumonks.org> Hi, On Thu, Apr 14, 2011 at 02:25:42AM -0700, Ammar Naamat Hameed wrote: > Is it possible to use openbsc as MSC, VLR and HLR without using nanBTS as > i'm?trying?to develop an SMSC.In other words, to make it work as MSC,HLR > emulator with dummy subscribers? Regards, no. you need something that exports the various MAP based interfaces, which we don't implement (so far). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From madmaxmarbler at gmail.com Sat Apr 16 08:57:55 2011 From: madmaxmarbler at gmail.com (Max Marbler) Date: Sat, 16 Apr 2011 01:57:55 -0700 Subject: Strange nanoBTS Behavior Message-ID: Dear List, I'm a long time listener, first time caller - but have been enjoying experimenting with OpenBSC for a little while now. I've come across a new (to me) nanoBTS with some strange behavior: it seems to come up normally and pull an IP over DHCP, and interacts as expected with the ipaccess-find and ipaccess-config tools, but *never* attempts to establish an OML link. After provisioning the correct settings with ipaccess-config, the unit reboots and slow-flashes the orange light (no OML) and there is *no* network traffic initiated by the nanoBTS past the DHCP exchange; however, I can ping the unit using ipaccess-find and ping. After running a reset with the dongle and a repeat of the above, I get the same results. Any ideas? Thank You, -MM -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Apr 16 17:16:04 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Apr 2011 19:16:04 +0200 Subject: Strange nanoBTS Behavior In-Reply-To: References: Message-ID: <20110416171604.GC9379@prithivi.gnumonks.org> Hi Max, On Sat, Apr 16, 2011 at 01:57:55AM -0700, Max Marbler wrote: > I've come across a new (to me) nanoBTS with some strange behavior: it seems > to come up normally and pull an IP over DHCP, and interacts as expected with > the ipaccess-find and ipaccess-config tools, but *never* attempts to > establish an OML link. > > After provisioning the correct settings with ipaccess-config, the unit > reboots and slow-flashes the orange light (no OML) and there is *no* network > traffic initiated by the nanoBTS past the DHCP exchange; however, I can ping > the unit using ipaccess-find and ping. > > After running a reset with the dongle and a repeat of the above, I get the > same results. > > Any ideas? you can try to set the respective nvram flags and then use ipaccess-telnet to get some debug information. maybe it will tell you what is happening. http://openbsc.osmocom.org/trac/wiki/nanoBTS#TelnetDebugPort the other thing I would do is to take a pcap trace with wireshark/tcpdump _directly_ at the BTS, either only with a hub (no switch!!) or beter with a crossover-cable between poe injector and a computer. This way you can see all the messages in detail that are sent by the BTS. I'm pretty confident it is trying to connect somewhere, maybe just the wrong address. Maybe the DHCP sender is sending some attributes that we don't know which contain the OML ip address? 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 madmaxmarbler at gmail.com Thu Apr 21 08:45:39 2011 From: madmaxmarbler at gmail.com (Max Marbler) Date: Thu, 21 Apr 2011 01:45:39 -0700 Subject: Strange nanoBTS Behavior In-Reply-To: <20110416171604.GC9379@prithivi.gnumonks.org> References: <20110416171604.GC9379@prithivi.gnumonks.org> Message-ID: Harald, Thanks for the helpful reply; you were right in that the OML was going somewhere. My error was a combination of two things: 1) A smart switch that was too smart for it's own good (in dropping the outgoing OML from my nanoBTS to an unroutable host) 2) A repeatable (at least for me) quirk in ipaccess-config, where specifying both the unit ID and the OML ip in one pass seems to not save the OML IP. eg. issuing a command of the form: ./ipaccess-config -u 1801/0/0 -o -r ...has been failing to properly set the OML IP. However, issuing two separate commands seems to work reliably. This, at least, has been my experience, test on two separate hosts targeting both a model 139 and 165 nanoBTS. Your suggestion about using telnet as a diagnostic mechanism came in handy though for me to determine that the original problem-unit is probably dead. After establishing the primary OML and with everything looking good on the openBSC side of things, the unit continues to slow-flash the green light, indicating that the radio is not transmitting. Note line 32319 and 32638. A telnet-dump of the OML startup follows: 29389:DBG:IP_CHANNEL:Assigning RX Client A 29389:DBG:IP_CHAN_RX_A:39369:ipChanConn: EVENT 0x00001742 rxd in STATE notconnected 29389:DBG:IP_CHAN_RX_A:Attempting connection to 192.168.15.1:3002 29389:DBG:IP_CHAN_RX_A:39370:ipChanConn: EVENT 0x00001747 rxd in STATE outgoingconnecting 29389:DBG:IP_STREAM:inside ipStreamChannelPeerIdentifiedEntry channelId =64 PeerPort = 3002 29823:DBG:OAM_IM:Changing SYSTEM LINK from 0.0 to 64.255 29893:DBG:OAM_MOI:oid=BTS:0 publisher attributes set 29913:DBG:TRX_BOOT:Trx Boot Timer started 29913:DBG:TRX_BOOT:Booting TRX image idx=1 30098:DBG:TRX_BOOT:Downloading blackfin boot code... 30767:DBG:TRX_BOOT:BFIN Booted successfully 30767:DBG:TRX_BOOT:actualItemId found = 0x900a 30815:DBG:TRX_BOOT:HPI Readback worked! 30815:DBG:TRX_BOOT:uncompressTrxImage : TRXtgtaddr = 0, sourceLen = 13086, max = 1500 30822:DBG:TRX_BOOT:uncompressTrxImage totals: stream.total_in = 13086, total_out = 46896 30822:DBG:TRX_BOOT:Downloaded FirstBootAndPost to DSP 30822:DBG:TRX_BOOT:DEBUG from TRX: First Boot and Post running... 30822:DBG:TRX_BOOT:DEBUG from TRX: Testing internal RAM... 30836:DBG:TRX_BOOT:DEBUG from TRX: Testing external RAM... 31195:DBG:TRX_BOOT:DEBUG from TRX: Testing FPGA... 31195:DBG:TRX_BOOT:DEBUG from TRX: TRX reports FPGA version number as 0826 31195:DBG:TRX_BOOT:DEBUG from TRX: Testing NWL VBC... 31195:DBG:TRX_BOOT:DEBUG from TRX: Testing DL VBC... 31517:DBG:TRX_BOOT:DEBUG from TRX: Testing AD9874... 31518:DBG:TRX_BOOT:DEBUG from TRX: [ AD9874 ID reg=0x0089] 31518:DBG:TRX_BOOT:DEBUG from TRX: firstBootAndPost finished 31518:DBG:TRX_BOOT:TRX boot reported all okay 31518:DBG:TRX_BOOT:DEBUG from TRX: requesting main app. download 31518:DBG:TRX_BOOT:TRX Requested image dld of imageId: 0x100b 31518:DBG:TRX_BOOT:actualItemId found = 0x900b 31518:DBG:TRX_BOOT:Reseting TRX for main application download 31564:DBG:TRX_BOOT:uncompressTrxImage : TRXtgtaddr = 80000000, sourceLen = 735441, max = 1500 31946:DBG:TRX_BOOT:uncompressTrxImage totals: stream.total_in = 735441, total_out = 2187808 31946:DBG:TRX_BOOT:Starting the TRX 32280:DBG:GENIE_SERVER:TRX now ready for genie signals. 32280:DBG:TRX_BOOT:Booted TRX idx=1 32284:DBG:RSL:39909:rsl: EVENT 0x0000104a rxd in STATE initial 32284:DBG:RSL:39909:rsl: ENTERING open 32319:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_db.c:202Failed to initialise" 32319:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_db.c:202Failed to initialise" 32526:DBG:OAM_MOI:oid=BBTRX:0-0 publisher attributes set 32528:DBG:OAM_MOI:oid=Carrier:0-0 subscriber attributes set 32529:DBG:RSL:40381:rsl: EVENT 0x0000104b rxd in STATE opennotconnected 32530:DBG:OAM_MOI:oid=BBTRX:0-0 subscriber attributes set 32530:DBG:OAM_MOI:oid=Carrier:0-0 publisher attributes set 32627:DBG:RSL:41176:rsl: EVENT 0x00001049 rxd in STATE configurednotconnected 32627:DBG:RSL:41176:rsl: ENTERING on 32628:DBG:IP_CHANNEL:Assigning RX Client B 32629:DBG:RSL:41205:rsl: EVENT 0x00001044 rxd in STATE ongoingconnecting 32629:DBG:IP_CHAN_RX_B:41206:ipChanConn: EVENT 0x00001742 rxd in STATE notconnected 32629:DBG:IP_CHAN_RX_B:Attempting connection to 192.168.15.1:3003 32629:DBG:IP_CHAN_RX_B:41207:ipChanConn: EVENT 0x00001747 rxd in STATE outgoingconnecting 32629:DBG:IP_STREAM:inside ipStreamChannelPeerIdentifiedEntry channelId =65 PeerPort = 3003 32630:DBG:RSL:41214:rsl: EVENT 0x00001043 rxd in STATE onconnecting 32630:DBG:RSL:41214:rsl: ENTERING onconnected 32638:DBG:BH_TRX_ROUTER_UL:AlarmInd rx'd:"l1_bg_activate.c:238TX_OPLL_RADIO_FAIL" 32651:DBG:RSL:41536:rsl: EVENT 0x00001048 rxd in STATE onconnected 32651:DBG:RSL:41536:rsl: EXITING on I'm assuming that this unit is dead unless someone knows better; the extended write-up is mostly to document the experience and symptoms. Thanks Again! -MM On Sat, Apr 16, 2011 at 10:16 AM, Harald Welte wrote: > Hi Max, > > On Sat, Apr 16, 2011 at 01:57:55AM -0700, Max Marbler wrote: > > > I've come across a new (to me) nanoBTS with some strange behavior: it > seems > > to come up normally and pull an IP over DHCP, and interacts as expected > with > > the ipaccess-find and ipaccess-config tools, but *never* attempts to > > establish an OML link. > > > > After provisioning the correct settings with ipaccess-config, the unit > > reboots and slow-flashes the orange light (no OML) and there is *no* > network > > traffic initiated by the nanoBTS past the DHCP exchange; however, I can > ping > > the unit using ipaccess-find and ping. > > > > After running a reset with the dongle and a repeat of the above, I get > the > > same results. > > > > Any ideas? > > you can try to set the respective nvram flags and then use ipaccess-telnet > to get some debug information. maybe it will tell you what is happening. > > http://openbsc.osmocom.org/trac/wiki/nanoBTS#TelnetDebugPort > > the other thing I would do is to take a pcap trace with wireshark/tcpdump > _directly_ at the BTS, either only with a hub (no switch!!) or beter with > a crossover-cable between poe injector and a computer. This way you can > see all the messages in detail that are sent by the BTS. I'm pretty > confident > it is trying to connect somewhere, maybe just the wrong address. > > Maybe the DHCP sender is sending some attributes that we don't know which > contain the OML ip address? > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Thu Apr 21 10:36:09 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 21 Apr 2011 12:36:09 +0200 Subject: Strange nanoBTS Behavior In-Reply-To: References: <20110416171604.GC9379@prithivi.gnumonks.org> Message-ID: <4DB00899.8060205@freyther.de> On 04/21/2011 10:45 AM, Max Marbler wrote: > > ./ipaccess-config -u 1801/0/0 -o -r > > ...has been failing to properly set the OML IP. However, issuing two separate > commands seems to work reliably. Yes, this is one of the problems with ipaccess-config. We should have a queue of things we want to do with the nanoBTS (always putting reboot to the end) and then execute this queue.. instead we probably issue reboot after the first ack we get before we set the IP address. > > This, at least, has been my experience, test on two separate hosts targeting > both a model 139 and 165 nanoBTS. > > Your suggestion about using telnet as a diagnostic mechanism came in handy > though for me to determine that the original problem-unit is probably dead. > > After establishing the primary OML and with everything looking good on the > openBSC side of things, the unit continues to slow-flash the green light, > indicating that the radio is not transmitting. No NACk or such on the OML link? From madmaxmarbler at gmail.com Sat Apr 23 03:06:06 2011 From: madmaxmarbler at gmail.com (Max Marbler) Date: Fri, 22 Apr 2011 20:06:06 -0700 Subject: Strange nanoBTS Behavior In-Reply-To: <4DB00899.8060205@freyther.de> References: <20110416171604.GC9379@prithivi.gnumonks.org> <4DB00899.8060205@freyther.de> Message-ID: Holger, Nothing resembling a nack that I could see; definitely nothing erroneous on the openBSC console, but I didn't have time to check the packet traces too carefully. -MM On Thu, Apr 21, 2011 at 3:36 AM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 04/21/2011 10:45 AM, Max Marbler wrote: > > > > > ./ipaccess-config -u 1801/0/0 -o -r > > > > ...has been failing to properly set the OML IP. However, issuing two > separate > > commands seems to work reliably. > > Yes, this is one of the problems with ipaccess-config. We should have a > queue > of things we want to do with the nanoBTS (always putting reboot to the end) > and then execute this queue.. instead we probably issue reboot after the > first > ack we get before we set the IP address. > > > > > > This, at least, has been my experience, test on two separate hosts > targeting > > both a model 139 and 165 nanoBTS. > > > > Your suggestion about using telnet as a diagnostic mechanism came in > handy > > though for me to determine that the original problem-unit is probably > dead. > > > > After establishing the primary OML and with everything looking good on > the > > openBSC side of things, the unit continues to slow-flash the green light, > > indicating that the radio is not transmitting. > > No NACk or such on the OML link? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Apr 23 08:59:22 2011 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 23 Apr 2011 10:59:22 +0200 Subject: Strange nanoBTS Behavior In-Reply-To: References: <20110416171604.GC9379@prithivi.gnumonks.org> <4DB00899.8060205@freyther.de> Message-ID: <20110423085922.GD4235@prithivi.gnumonks.org> Hi Max, On Fri, Apr 22, 2011 at 08:06:06PM -0700, Max Marbler wrote: > Nothing resembling a nack that I could see; definitely nothing erroneous on > the openBSC console, but I didn't have time to check the packet traces too > carefully. If possible, you could simply make the pcap file available for others to review. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bertoncello at netzing.de Tue Apr 19 07:09:57 2011 From: bertoncello at netzing.de (Luca Bertoncello) Date: Tue, 19 Apr 2011 09:09:57 +0200 Subject: Blocks OpenBSC the calls to 112? Message-ID: <20110419090957.1dd20f16@Luca> Hi, List! Just a question, does OpenBSC block the connection to special number such 112? I connected OpenBSC to Asterisk and in Asterisk I have an extension 112 (now just as test), an 110 and an 115. If I call the 110 or 115 I can see that Asterisk will be asked to connect the phone and the VoIP-phone with the number will be called. If I call the 112 the connection terminates and I can't see OpenBSC sending any signal to Asterisk. Could you confirm me, that OpenBSC blocks this number? And, maybe, suggest me how to delete this block... :) Thanks a lot! Luca Bertoncello -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fr?belstr. 57, 01159 Dresden Fax: 0351/41381 - 12 _______________________________________________________________________ Impressum: NETZING Solutions AG - Fr?belstra?e 57 - 01159 Dresden Sitz der Gesellschaft Amtsgericht Dresden HRB 18926 Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz USt.Id DE211326547 Mail: netzing.ag at netzing.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From holger at freyther.de Tue Apr 19 07:27:40 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 19 Apr 2011 09:27:40 +0200 Subject: Blocks OpenBSC the calls to 112? In-Reply-To: <20110419090957.1dd20f16@Luca> References: <20110419090957.1dd20f16@Luca> Message-ID: <4DAD396C.4060809@freyther.de> On 04/19/2011 09:09 AM, Luca Bertoncello wrote: > Hi, List! > Could you confirm me, that OpenBSC blocks this number? > And, maybe, suggest me how to delete this block... :) Hi, when you dial an emergency number (911, 11...) the phone will not do normal call control but will send a CM Service Request (IIRC) with an emergency reason, this is rejected by OpenBSC right now. See libmsc/gsm_04_08.c. From bertoncello at netzing.de Tue Apr 19 09:44:14 2011 From: bertoncello at netzing.de (Luca Bertoncello) Date: Tue, 19 Apr 2011 11:44:14 +0200 Subject: Blocks OpenBSC the calls to 112? In-Reply-To: <4DAD396C.4060809@freyther.de> References: <20110419090957.1dd20f16@Luca> <4DAD396C.4060809@freyther.de> Message-ID: <20110419114414.4e0a729e@Luca> Am Tue, 19 Apr 2011 09:27:40 +0200 schrieb Holger Hans Peter Freyther : > when you dial an emergency number (911, 11...) the phone will not do > normal call control but will send a CM Service Request (IIRC) with an > emergency reason, this is rejected by OpenBSC right now. See > libmsc/gsm_04_08.c. Hi, Holger! Thanks for your answer. But why can I call the 110 and 115? Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello at netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fr?belstr. 57, 01159 Dresden Fax: 0351/41381 - 12 _______________________________________________________________________ Impressum: NETZING Solutions AG - Fr?belstra?e 57 - 01159 Dresden Sitz der Gesellschaft Amtsgericht Dresden HRB 18926 Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz USt.Id DE211326547 Mail: netzing.ag at netzing.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From 246tnt at gmail.com Tue Apr 19 09:56:15 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 19 Apr 2011 11:56:15 +0200 Subject: Blocks OpenBSC the calls to 112? In-Reply-To: <20110419114414.4e0a729e@Luca> References: <20110419090957.1dd20f16@Luca> <4DAD396C.4060809@freyther.de> <20110419114414.4e0a729e@Luca> Message-ID: > Thanks for your answer. But why can I call the 110 and 115? I don't think those are considered emergency numbers. The list may be dependent on the phone but will at least include 112 (EU standardized number) and 911. Just remove the sim and try to dial a number (without going through to the _actual_ dialling). Cheers, Sylvain From holger at freyther.de Tue Apr 19 11:02:30 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 19 Apr 2011 13:02:30 +0200 Subject: Blocks OpenBSC the calls to 112? In-Reply-To: References: <20110419090957.1dd20f16@Luca> <4DAD396C.4060809@freyther.de> <20110419114414.4e0a729e@Luca> Message-ID: <4DAD6BC6.7080306@freyther.de> On 04/19/2011 11:56 AM, Sylvain Munaut wrote: >> Thanks for your answer. But why can I call the 110 and 115? > > I don't think those are considered emergency numbers. > The list may be dependent on the phone but will at least include 112 > (EU standardized number) and 911. These numbers are specified in GSM 02.30 and 22.101, maybe also the behavior when which number should be allowed... From holger at freyther.de Tue Apr 19 11:03:36 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 19 Apr 2011 13:03:36 +0200 Subject: Blocks OpenBSC the calls to 112? In-Reply-To: <20110419114414.4e0a729e@Luca> References: <20110419090957.1dd20f16@Luca> <4DAD396C.4060809@freyther.de> <20110419114414.4e0a729e@Luca> Message-ID: <4DAD6C08.8000601@freyther.de> On 04/19/2011 11:44 AM, Luca Bertoncello wrote: > Hi, Holger! > > Thanks for your answer. But why can I call the 110 and 115? The easiest way is to generate a trace and then look at which messages are sent. I assume one will be normal call control the other not. From 246tnt at gmail.com Tue Apr 19 10:03:55 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Tue, 19 Apr 2011 10:03:55 +0000 Subject: Blocks OpenBSC the calls to 112? In-Reply-To: <20110419115948.197ba502@Luca> Message-ID: <0015174c11ac48629604a142a035@google.com> > Does it mean, that it is not possible for me to have a 112 number b > called in my network? No, it's not possible. You should avoid anything starting by '1' and anything starting by '9' in your dialplan ... Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.henard at esial.net Tue Apr 19 11:15:35 2011 From: christopher.henard at esial.net (Christopher HENARD) Date: Tue, 19 Apr 2011 13:15:35 +0200 Subject: bsc_hack Message-ID: Hi everyone, I have successfully compiled and installed openBSC-0.9.13, but there isn't the program bsc_hack. However, in src/osmo-nitb, there's bsc_hack source code and object (.c and .o) and an executable osmo-nitb. Has bsc_hack been replaced by osmo-nitb ? Thanks. Christopher H?nard -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at gnumonks.org Tue Apr 19 11:53:16 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 19 Apr 2011 13:53:16 +0200 Subject: bsc_hack In-Reply-To: References: Message-ID: <4DAD77AC.3020201@gnumonks.org> On 19/04/11 13:15, Christopher HENARD wrote: > Hi everyone, > > I have successfully compiled and installed openBSC-0.9.13, but there > isn't the program bsc_hack. However, in src/osmo-nitb, there's bsc_hack > source code and object (.c and .o) and an executable osmo-nitb. Has > bsc_hack been replaced by osmo-nitb ? Yes. From holger at freyther.de Tue Apr 19 12:38:20 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 19 Apr 2011 14:38:20 +0200 Subject: bsc_hack In-Reply-To: References: Message-ID: <4DAD823C.4020306@freyther.de> On 04/19/2011 01:15 PM, Christopher HENARD wrote: > Hi everyone, > > I have successfully compiled and installed openBSC-0.9.13, but there isn't the > program bsc_hack. However, in src/osmo-nitb, there's bsc_hack source code and > object (.c and .o) and an executable osmo-nitb. Has bsc_hack been replaced by > osmo-nitb ? Is the wiki still referring to bsc_hack? From ammar_naamat1 at yahoo.com Wed Apr 20 05:22:32 2011 From: ammar_naamat1 at yahoo.com (Ammar Naamat Hameed) Date: Tue, 19 Apr 2011 22:22:32 -0700 (PDT) Subject: bsc_hack In-Reply-To: <4DAD823C.4020306@freyther.de> Message-ID: <738987.79782.qm@web45211.mail.sp1.yahoo.com> Hi Holger,? yes,?osmo-nitb (formerly called bsc_hack), Read this?wiki.? Regards, Ammar --- On Tue, 4/19/11, Holger Hans Peter Freyther wrote: From: Holger Hans Peter Freyther Subject: Re: bsc_hack To: openbsc at lists.osmocom.org Date: Tuesday, April 19, 2011, 3:38 PM On 04/19/2011 01:15 PM, Christopher HENARD wrote: > Hi everyone, > > I have successfully compiled and installed openBSC-0.9.13, but there isn't the > program bsc_hack. However, in src/osmo-nitb, there's bsc_hack source code and > object (.c and .o) and an executable osmo-nitb. Has bsc_hack been replaced by > osmo-nitb ? Is the wiki still referring to bsc_hack? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Apr 20 07:09:27 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 20 Apr 2011 09:09:27 +0200 Subject: bsc_hack In-Reply-To: <738987.79782.qm@web45211.mail.sp1.yahoo.com> References: <4DAD823C.4020306@freyther.de> <738987.79782.qm@web45211.mail.sp1.yahoo.com> Message-ID: <20110420070927.GE31023@prithivi.gnumonks.org> On Tue, Apr 19, 2011 at 10:22:32PM -0700, Ammar Naamat Hameed wrote: > Hi Holger,? > yes,?osmo-nitb (formerly called bsc_hack), Read this?wiki.? Well, tot be fair: After reading this thread, I had taken some time yesterday to update the wiki. So at the time the original question was posted, it still referred to bsc_hack almost everywhere. -- - 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 Tue Apr 19 17:47:44 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 19 Apr 2011 19:47:44 +0200 Subject: [PATCH 0/3] new VTY commands to enable IPA proxy Message-ID: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Hi! This patchset adds new VTY commands that allows to route IPA flows. Patch 3/3 includes one feature that changes the current default behaviour of OpenBSC since you explicity have to make a "ipa setup" to enable OML and RSL links. If you like it, I can make a similar patch for HSL femto, so the only initial open socket is the one at port 4242 for telnet configuration. BTW, the original command syntax was proposed by Harald. Successfully tested bootstrapping the nanoBTS. See the patches for more details. Comments welcome! Pablo Neira Ayuso (3): libcommon: add make_sock_stream_connect() libabis: add VTY commands to route IPA flows libabis: add IPA VTY command to setup ip.access nanoBTS OML and RSL links openbsc/include/openbsc/ipaccess.h | 3 + openbsc/include/openbsc/socket.h | 2 + openbsc/include/openbsc/vty.h | 1 + openbsc/src/ipaccess/Makefile.am | 4 +- openbsc/src/libabis/Makefile.am | 2 +- openbsc/src/libabis/e1_input.c | 2 + openbsc/src/libabis/input/ipaccess.c | 962 +++++++++++++++++++++++++++++- openbsc/src/libbsc/bsc_vty.c | 1 + openbsc/src/libcommon/socket.c | 54 ++ openbsc/src/openbsc.cfg.ipa-proxy | 18 + openbsc/src/openbsc.cfg.nanobts | 3 + openbsc/src/openbsc.cfg.nanobts.multitrx | 3 + openbsc/tests/db/Makefile.am | 5 +- 13 files changed, 1043 insertions(+), 17 deletions(-) create mode 100644 openbsc/src/openbsc.cfg.ipa-proxy -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 19 17:47:45 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 19 Apr 2011 19:47:45 +0200 Subject: [PATCH 1/3] libcommon: add make_sock_stream_connect() In-Reply-To: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> References: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> Message-ID: <1303235267-14168-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch adds make_sock_stream_connect() which allows to perform a non-blocking connect to some host and port. This only support TCP by now, but it could be easily extensible to support other stream-based layer 4 protocols. --- openbsc/include/openbsc/socket.h | 2 + openbsc/src/libcommon/socket.c | 54 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 0 deletions(-) diff --git a/openbsc/include/openbsc/socket.h b/openbsc/include/openbsc/socket.h index 87ef37f..af5f729 100644 --- a/openbsc/include/openbsc/socket.h +++ b/openbsc/include/openbsc/socket.h @@ -11,4 +11,6 @@ int make_sock(struct bsc_fd *bfd, int proto, uint32_t ip, uint16_t port, int priv_nr, int (*cb)(struct bsc_fd *fd, unsigned int what), void *data); +int make_sock_stream_connect(struct bsc_fd *bfd, int proto, struct in_addr addr, uint16_t port, int priv_nr, int (*cb)(struct bsc_fd *fd, unsigned int what), void *data); + #endif /* _BSC_SOCKET_H */ diff --git a/openbsc/src/libcommon/socket.c b/openbsc/src/libcommon/socket.c index dd25dd7..f4a533d 100644 --- a/openbsc/src/libcommon/socket.c +++ b/openbsc/src/libcommon/socket.c @@ -107,3 +107,57 @@ int make_sock(struct bsc_fd *bfd, int proto, } return 0; } + +/* this function performs a non-blocking stream connect. */ +int make_sock_stream_connect(struct bsc_fd *bfd, int proto, + struct in_addr addr, uint16_t port, int priv_nr, + int (*cb)(struct bsc_fd *fd, unsigned int what), + void *data) +{ + int ret, flags, type; + struct sockaddr_in saddr; + + switch (proto) { + case IPPROTO_TCP: + type = SOCK_STREAM; + break; + default: + return -EINVAL; + } + + bfd->fd = socket(AF_INET, type, proto); + bfd->cb = cb; + /* non-blocking connect() confirms by setting BSC_FD_READ. */ + bfd->when = BSC_FD_READ | BSC_FD_WRITE; + bfd->data = data; + bfd->priv_nr = priv_nr; + + if (bfd->fd < 0) { + LOGP(DINP, LOGL_ERROR, "could not create socket.\n"); + return -EIO; + } + flags = fcntl(bfd->fd, F_GETFL, 0); + if (fcntl(bfd->fd, F_SETFL, flags | O_NONBLOCK) < 0) { + LOGP(DINP, LOGL_ERROR, "could not fcntl.\n"); + return -EIO; + } + memset(&saddr, 0, sizeof(addr)); + saddr.sin_family = AF_INET; + saddr.sin_port = port; + memcpy(&saddr.sin_addr, &addr, sizeof(struct in_addr)); + + ret = connect(bfd->fd, (struct sockaddr *) &saddr, sizeof(saddr)); + if (ret < 0 && errno != EINPROGRESS) { + LOGP(DINP, LOGL_ERROR, "could not connect socket %s\n", + strerror(errno)); + close(bfd->fd); + return -EIO; + } + ret = bsc_register_fd(bfd); + if (ret < 0) { + perror("register_listen_fd"); + close(bfd->fd); + return ret; + } + return 0; +} -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 19 17:47:46 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 19 Apr 2011 19:47:46 +0200 Subject: [PATCH 2/3] libabis: add VTY commands to route IPA flows In-Reply-To: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> References: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> Message-ID: <1303235267-14168-3-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch adds VTY commands to route IPA flows. This works as it follows: $ telnet localhost 4242 %% enter ENABLE mode > enable %% create an input instance that binds to 192.168.1.1:9999 # ipa instance input bind 192.168.1.1 tcp port 9999 %% create an output instance that connects to 192.168.1.2:8888 # ipa instance output connect 192.168.1.2 tcp port 8888 %% create a route between the input and output instance, routing messages whose streamid is 0xff (OML). # ipa route instance input streamid 0xff instance output streamid 0xff We also allow mangling the streamid in case that the source and the destination streamids are not the same. This patch includes the following commands: %% to delete one instance # ipa no instance input %% to delete one route # ipa no route instance input streamid 0xff instance output streamid 0xff --- openbsc/include/openbsc/ipaccess.h | 2 + openbsc/include/openbsc/vty.h | 1 + openbsc/src/ipaccess/Makefile.am | 4 +- openbsc/src/libabis/Makefile.am | 2 +- openbsc/src/libabis/input/ipaccess.c | 891 ++++++++++++++++++++++++++++++++++ openbsc/src/libbsc/bsc_vty.c | 1 + openbsc/src/openbsc.cfg.ipa-proxy | 18 + openbsc/tests/db/Makefile.am | 5 +- 8 files changed, 919 insertions(+), 5 deletions(-) create mode 100644 openbsc/src/openbsc.cfg.ipa-proxy diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index d965aea..28ec49a 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -86,6 +86,8 @@ int ipaccess_parse_unitid(const char *str, uint16_t *site_id, uint16_t *bts_id, int ipaccess_drop_oml(struct gsm_bts *bts); int ipaccess_drop_rsl(struct gsm_bts_trx *trx); +void ipaccess_vty_init(void); + /* * Firmware specific header */ diff --git a/openbsc/include/openbsc/vty.h b/openbsc/include/openbsc/vty.h index ded2e15..56950b5 100644 --- a/openbsc/include/openbsc/vty.h +++ b/openbsc/include/openbsc/vty.h @@ -35,6 +35,7 @@ enum bsc_vty_node { MSC_NODE, OM2K_NODE, TRUNK_NODE, + IPA_NODE, }; extern int bsc_vty_is_config_node(struct vty *vty, int node); diff --git a/openbsc/src/ipaccess/Makefile.am b/openbsc/src/ipaccess/Makefile.am index 4fe1e37..2ee30e3 100644 --- a/openbsc/src/ipaccess/Makefile.am +++ b/openbsc/src/ipaccess/Makefile.am @@ -1,6 +1,6 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) -AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(COVERAGE_CFLAGS) -AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(COVERAGE_LDFLAGS) +AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(COVERAGE_CFLAGS) +AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) $(COVERAGE_LDFLAGS) bin_PROGRAMS = ipaccess-find ipaccess-config ipaccess-proxy diff --git a/openbsc/src/libabis/Makefile.am b/openbsc/src/libabis/Makefile.am index ffaa201..d340a3f 100644 --- a/openbsc/src/libabis/Makefile.am +++ b/openbsc/src/libabis/Makefile.am @@ -1,6 +1,6 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(COVERAGE_CFLAGS) -AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(COVERAGE_LDFLAGS) +AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) $(COVERAGE_LDFLAGS) noinst_LIBRARIES = libabis.a diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index d2572fb..0cd3b2d 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include @@ -45,6 +46,8 @@ #include #include #include +#include +#include #define PRIV_OML 1 #define PRIV_RSL 2 @@ -808,6 +811,894 @@ int ipaccess_connect(struct e1inp_line *line, struct sockaddr_in *sa) //return e1inp_line_register(line); } +/* + * data structures used by the IPA VTY commands + */ +static LLIST_HEAD(ipa_instance_list); + +enum ipa_instance_net_type { + IPA_INSTANCE_T_NONE, + IPA_INSTANCE_T_BIND, + IPA_INSTANCE_T_CONNECT, + IPA_INSTANCE_T_MAX +}; + +struct ipa_instance_net { + struct in_addr addr; + uint16_t port; + enum ipa_instance_net_type type; +}; + +struct ipa_instance { + struct llist_head head; +#define IPA_INSTANCE_NAME 16 + char name[IPA_INSTANCE_NAME]; + struct ipa_instance_net net; + int refcnt; +}; + +static LLIST_HEAD(ipa_route_list); + +/* Several routes pointing to the same instances share this. */ +struct ipa_route_shared { + int refcnt; + + /* this file descriptor is used to accept() new connections. */ + struct bsc_fd bfd; + + struct { + struct ipa_instance *inst; + struct bitvec streamid_map; + uint8_t streamid_map_data[(0xff+1)/8]; + uint8_t streamid[0xff]; + } src; + struct { + struct ipa_instance *inst; + struct bitvec streamid_map; + uint8_t streamid_map_data[(0xff+1)/8]; + uint8_t streamid[0xff]; + } dst; + + struct llist_head conn_list; +}; + +/* One route is composed of two instances. */ +struct ipa_route { + struct llist_head head; + + struct { + uint8_t streamid; + } src; + struct { + uint8_t streamid; + } dst; + + struct ipa_route_shared *shared; +}; + +enum ipa_conn_state { + IPA_CONN_S_NONE, + IPA_CONN_S_CONNECTING, + IPA_CONN_S_CONNECTED, + IPA_CONN_S_MAX +}; + +/* One route may forward more than one connection. */ +struct ipa_conn { + struct llist_head head; + + struct { + /* this is the file descriptor that accept() returns. */ + struct bsc_fd bfd; + struct llist_head tx_queue; + /* special handling for segmented message. */ + ssize_t remaining_bytes; + } src; + struct { + /* this is the file descriptor that connect() returns. */ + struct bsc_fd bfd; + struct llist_head tx_queue; + /* special handling for segmented message. */ + ssize_t remaining_bytes; + enum ipa_conn_state state; + struct timer_list reconnect_timer; + } dst; + struct ipa_route *route; +}; + +/* + * socket callbacks used by IPA VTY commands + */ + +/* try to reconnect after 5 seconds, make this configurable in the future. */ +#define IPA_TIMER_RECONNECT 5 + +/* if we use TS1_ALLOC_SIZE, which is 900 bytes, we may truncate messages. */ +#define IPA_PROXY_ALLOC_SIZE 1200 + +static void ipa_reconnect_timer_cb(void *data); + +static void ipa_sock_dst_reconnect(struct bsc_fd *bfd, struct ipa_conn *conn) +{ + if (bsc_timer_pending(&conn->dst.reconnect_timer)) { + LOGP(DINP, LOGL_ERROR, "Report bug, this SHOULD NOT happen " + "reconnection already scheduled\n"); + return; + } + bsc_unregister_fd(&conn->dst.bfd); + close(conn->dst.bfd.fd); + conn->dst.bfd.fd = -1; + + conn->dst.reconnect_timer.cb = ipa_reconnect_timer_cb; + conn->dst.reconnect_timer.data = conn; + bsc_schedule_timer(&conn->dst.reconnect_timer, IPA_TIMER_RECONNECT, 0); + LOGP(DINP, LOGL_NOTICE, "I will try to reconnect to dst " + "IPA peer in %d seconds\n", IPA_TIMER_RECONNECT); +} + +static int ipa_sock_dst_read(struct bsc_fd *connect_bfd, struct ipa_conn *conn) +{ + struct ipaccess_head *hh; + struct msgb *msg; + int ret; + + msg = msgb_alloc(IPA_PROXY_ALLOC_SIZE, "IPA"); + if (msg == NULL) { + LOGP(DINP, LOGL_ERROR, "failed to alloc msg\n"); + return -ENOMEM; + } + ret = recv(connect_bfd->fd, msg->data, + msg->data_len, 0); + if (ret < 0) { + if (errno == EPIPE || errno == ENOTCONN) { + LOGP(DINP, LOGL_NOTICE, + "destination IPA peer has closed " + "the connection\n"); + } else { + LOGP(DINP, LOGL_ERROR, "failed to " + "recv from destination IPA peer, " + "reason=`%s'\n", strerror(errno)); + } + conn->dst.state = IPA_CONN_S_CONNECTING; + ipa_sock_dst_reconnect(connect_bfd, conn); + msgb_free(msg); + return ret; + } else if (ret == 0) { + LOGP(DINP, LOGL_NOTICE, "destination IPA peer " + "has closed the connection\n"); + conn->dst.state = IPA_CONN_S_CONNECTING; + ipa_sock_dst_reconnect(connect_bfd, conn); + msgb_free(msg); + return 0; + } + /* remaining bytes of a segmented message. */ + if (conn->dst.remaining_bytes > 0) { + conn->dst.remaining_bytes -= ret; + msgb_put(msg, ret); + msgb_enqueue(&conn->src.tx_queue, msg); + conn->src.bfd.when |= BSC_FD_WRITE; + return 0; + } + if (ret < sizeof(struct ipaccess_head)) { + LOGP(DINP, LOGL_ERROR, "received too small " + "message from destination IPA\n"); + msgb_free(msg); + return -EINVAL; + } + msgb_put(msg, ret); + hh = (struct ipaccess_head *)msg->data; + /* check if we have a route for this message. */ + if (bitvec_get_bit_pos( + &conn->route->shared->dst.streamid_map, + hh->proto) != ONE) { + LOGP(DINP, LOGL_NOTICE, "we don't have a " + "route for streamid 0x%x\n", hh->proto); + msgb_free(msg); + return 0; + } + /* segmented message, expect remaining bytes. */ + if (ret < ntohs(hh->len)) { + conn->dst.remaining_bytes = + ntohs(hh->len) + sizeof(*hh) - ret; + } + /* mangle message, if required. */ + hh->proto = conn->route->shared->src.streamid[hh->proto]; + msgb_enqueue(&conn->src.tx_queue, msg); + conn->src.bfd.when |= BSC_FD_WRITE; + return 0; +} + +static int ipa_sock_dst_cb(struct bsc_fd *connect_bfd, unsigned int what) +{ + int ret = 0; + struct msgb *msg; + struct llist_head *lh; + struct ipa_conn *conn = connect_bfd->data; + int error; + size_t len = sizeof(error); + + switch(conn->dst.state) { + case IPA_CONN_S_CONNECTING: + ret = getsockopt(connect_bfd->fd, SOL_SOCKET, SO_ERROR, + &error, &len); + if (ret >= 0 && error > 0) { + conn->dst.state = IPA_CONN_S_CONNECTING; + ipa_sock_dst_reconnect(connect_bfd, conn); + return 0; + } + conn->dst.state = IPA_CONN_S_CONNECTED; + LOGP(DINP, LOGL_NOTICE, "connected to destination IPA peer!\n"); + break; + case IPA_CONN_S_CONNECTED: + /* receive messages: destination -> source. */ + if (what & BSC_FD_READ) + ipa_sock_dst_read(connect_bfd, conn); + + /* send messages: source -> destination. */ + if (what & BSC_FD_WRITE) { + if (llist_empty(&conn->dst.tx_queue)) { + connect_bfd->when &= ~BSC_FD_WRITE; + return 0; + } + lh = conn->dst.tx_queue.next; + llist_del(lh); + msg = llist_entry(lh, struct msgb, list); + + ret = send(conn->dst.bfd.fd, msg->data, msg->len, 0); + if (ret < 0) { + if (errno == EPIPE || errno == ENOTCONN) { + conn->dst.state = + IPA_CONN_S_CONNECTING; + ipa_sock_dst_reconnect(connect_bfd, + conn); + } + LOGP(DINP, LOGL_ERROR, "failed to send (%s)\n", + strerror(errno)); + } + msgb_free(msg); + } + break; + default: + LOGP(DINP, LOGL_ERROR, "unknown state type"); + break; + } + return ret; +} + +static void ipa_reconnect_timer_cb(void *data) +{ + struct ipa_conn *conn = data; + int ret; + + ret = make_sock_stream_connect(&conn->dst.bfd, IPPROTO_TCP, + conn->route->shared->dst.inst->net.addr, + conn->route->shared->dst.inst->net.port, + 0, ipa_sock_dst_cb, conn); + if (ret < 0) + LOGP(DINP, LOGL_ERROR, "cannot create destination IPA socket"); +} + +static int ipa_sock_src_read(struct bsc_fd *bfd, struct ipa_conn *conn) +{ + int ret; + struct msgb *msg; + struct ipaccess_head *hh; + + msg = msgb_alloc(IPA_PROXY_ALLOC_SIZE, "IPA"); + if (msg == NULL) { + LOGP(DINP, LOGL_ERROR, "failed to msgb_alloc\n"); + return -ENOMEM; + } + ret = recv(bfd->fd, msg->data, msg->data_len, 0); + if (ret < 0) { + LOGP(DINP, LOGL_ERROR, "failed to recv from origin " + "IPA peer, reason=`%s'\n", strerror(errno)); + bsc_unregister_fd(bfd); + close(bfd->fd); + bfd->fd = -1; + msgb_free(msg); + return ret; + } else if (ret == 0) { + LOGP(DINP, LOGL_NOTICE, "origin IPA peer has closed " + "the connection\n"); + bsc_unregister_fd(bfd); + close(bfd->fd); + bfd->fd = -1; + bsc_del_timer(&conn->dst.reconnect_timer); + if (conn->dst.bfd.fd != -1) { + bsc_unregister_fd(&conn->dst.bfd); + close(conn->dst.bfd.fd); + conn->dst.bfd.fd = -1; + } + llist_del(&conn->head); + talloc_free(conn); + msgb_free(msg); + return 0; + } + /* remaining bytes of a segmented message. */ + if (conn->src.remaining_bytes > 0) { + conn->src.remaining_bytes -= ret; + msgb_put(msg, ret); + msgb_enqueue(&conn->dst.tx_queue, msg); + conn->dst.bfd.when |= BSC_FD_WRITE; + return 0; + } + if (ret < sizeof(struct ipaccess_head)) { + LOGP(DINP, LOGL_ERROR, "received too small message " + "from origin IPA\n"); + msgb_free(msg); + return -EINVAL; + } + msgb_put(msg, ret); + hh = (struct ipaccess_head *)msg->data; + /* check if we have a route for this message. */ + if (bitvec_get_bit_pos(&conn->route->shared->src.streamid_map, + hh->proto) != ONE) { + LOGP(DINP, LOGL_NOTICE, "we don't have a " + "route for streamid 0x%x\n", hh->proto); + msgb_free(msg); + return 0; + } + /* segmented message, expect remaining bytes. */ + if (ret < ntohs(hh->len)) { + conn->src.remaining_bytes = + ntohs(hh->len) + sizeof(*hh) - ret; + } + /* mangle message, if required. */ + hh->proto = conn->route->shared->dst.streamid[hh->proto]; + msgb_enqueue(&conn->dst.tx_queue, msg); + conn->dst.bfd.when |= BSC_FD_WRITE; + return 0; +} + +static int ipa_sock_src_cb(struct bsc_fd *bfd, unsigned int what) +{ + struct ipa_conn *conn = bfd->data; + struct msgb *msg; + int ret = 0; + + /* receive messages: source -> destination. */ + if (what & BSC_FD_READ) + ipa_sock_src_read(bfd, conn); + + /* send messages: destination -> source. */ + if (what & BSC_FD_WRITE) { + struct llist_head *lh; + + if (llist_empty(&conn->src.tx_queue)) { + bfd->when &= ~BSC_FD_WRITE; + return 0; + } + lh = conn->src.tx_queue.next; + llist_del(lh); + msg = llist_entry(lh, struct msgb, list); + + ret = send(bfd->fd, msg->data, msg->len, 0); + if (ret < 0) { + LOGP(DINP, LOGL_ERROR, "failed to send (%s)\n", + strerror(errno)); + bsc_unregister_fd(bfd); + close(bfd->fd); + bfd->fd = -1; + msgb_free(msg); + } + } + return ret; +} + +static int +ipa_sock_src_accept_cb(struct bsc_fd *listen_bfd, unsigned int what) +{ + int ret; + struct sockaddr_in sa; + struct ipa_route *route = listen_bfd->data; + socklen_t sa_len = sizeof(sa); + struct ipa_conn *conn; + + ret = accept(listen_bfd->fd, (struct sockaddr *) &sa, &sa_len); + if (ret < 0) { + LOGP(DINP, LOGL_ERROR, "failed to accept from origin IPA " + "peer, reason=`%s'\n", strerror(errno)); + return ret; + } + LOGP(DINP, LOGL_NOTICE, "accept()ed new link from origin IPA " + "peer: %s\n", inet_ntoa(sa.sin_addr)); + + conn = talloc_zero(tall_bsc_ctx, struct ipa_conn); + if (conn == NULL) { + LOGP(DINP, LOGL_ERROR, "cannot allocate memory for origin IPA " + "peer: %s\n", inet_ntoa(sa.sin_addr)); + close(ret); + return ret; + } + conn->route = route; + INIT_LLIST_HEAD(&conn->src.tx_queue); + INIT_LLIST_HEAD(&conn->dst.tx_queue); + conn->dst.state = IPA_CONN_S_CONNECTING; + + conn->src.bfd.fd = ret; + conn->src.bfd.data = conn; + conn->src.bfd.cb = ipa_sock_src_cb; + conn->src.bfd.when = BSC_FD_READ; + ret = bsc_register_fd(&conn->src.bfd); + if (ret < 0) { + LOGP(DINP, LOGL_ERROR, "could not register FD\n"); + close(conn->src.bfd.fd); + conn->src.bfd.fd = -1; + return ret; + } + ret = make_sock_stream_connect(&conn->dst.bfd, IPPROTO_TCP, + route->shared->dst.inst->net.addr, + route->shared->dst.inst->net.port, + 0, ipa_sock_dst_cb, conn); + if (ret < 0) { + LOGP(DINP, LOGL_ERROR, "could not create client: %s\n", + strerror(errno)); + conn->dst.state = IPA_CONN_S_CONNECTING; + ipa_sock_dst_reconnect(&conn->dst.bfd, conn); + } + llist_add(&conn->head, &route->shared->conn_list); + return ret; +} + +/* + * VTY commands for IPA + */ +DEFUN(ipa_proxy, ipa_cmd, "ipa", "Configure the ipaccess proxy") +{ + vty->index = NULL; + vty->node = IPA_NODE; + return CMD_SUCCESS; +} + +static int __ipa_instance_add(struct vty *vty, int argc, const char *argv[]) +{ + struct ipa_instance *ipi; + enum ipa_instance_net_type type; + struct in_addr addr; + uint16_t port; + + if (argc < 4) + return CMD_ERR_INCOMPLETE; + + llist_for_each_entry(ipi, &ipa_instance_list, head) { + if (strncmp(ipi->name, argv[0], IPA_INSTANCE_NAME) != 0) + continue; + + vty_out(vty, "%% instance `%s' already exists%s", + ipi->name, VTY_NEWLINE); + return CMD_WARNING; + } + if (strncmp(argv[1], "bind", IPA_INSTANCE_NAME) == 0) + type = IPA_INSTANCE_T_BIND; + else if (strncmp(argv[1], "connect", IPA_INSTANCE_NAME) == 0) + type = IPA_INSTANCE_T_CONNECT; + else + return CMD_ERR_INCOMPLETE; + + if (inet_aton(argv[2], &addr) < 0) { + vty_out(vty, "%% invalid address %s%s", argv[1], VTY_NEWLINE); + return CMD_WARNING; + } + port = atoi(argv[3]); + + ipi = talloc_zero(tall_bsc_ctx, struct ipa_instance); + if (ipi == NULL) { + vty_out(vty, "%% can't allocate memory for new instance%s", + VTY_NEWLINE); + return CMD_WARNING; + } + strncpy(ipi->name, argv[0], IPA_INSTANCE_NAME); + ipi->net.type = type; + memcpy(&ipi->net.addr, &addr, sizeof(struct in_addr)); + ipi->net.port = htons(port); + llist_add_tail(&ipi->head, &ipa_instance_list); + + return CMD_SUCCESS; +} + +DEFUN(ipa_instance_add, ipa_instance_add_cmd, + "ipa instance NAME (bind|connect) IP tcp port PORT", + "Bind or connect instance to address and port") +{ + return __ipa_instance_add(vty, argc, argv); +} + +DEFUN(ipa_instance_del, ipa_instance_del_cmd, + "ipa no instance NAME", + "Delete instance to address and port") +{ + struct ipa_instance *ipi; + + if (argc < 1) + return CMD_ERR_INCOMPLETE; + + llist_for_each_entry(ipi, &ipa_instance_list, head) { + if (strncmp(ipi->name, argv[0], IPA_INSTANCE_NAME) != 0) + continue; + + if (ipi->refcnt > 0) { + vty_out(vty, "%% instance `%s' is in use%s", + ipi->name, VTY_NEWLINE); + return CMD_WARNING; + } + llist_del(&ipi->head); + talloc_free(ipi); + return CMD_SUCCESS; + } + vty_out(vty, "%% instance `%s' does not exist%s", + ipi->name, VTY_NEWLINE); + + return CMD_WARNING; +} + +DEFUN(ipa_instance_show, ipa_instance_show_cmd, + "ipa instance show", "Show existing ipaccess proxy instances") +{ + struct ipa_instance *this; + + llist_for_each_entry(this, &ipa_instance_list, head) { + vty_out(vty, "instance %s %s %s tcp port %u%s", + this->name, inet_ntoa(this->net.addr), + this->net.type == IPA_INSTANCE_T_BIND ? + "bind" : "connect", + ntohs(this->net.port), VTY_NEWLINE); + } + return CMD_SUCCESS; +} + +static int __ipa_route_add(struct vty *vty, int argc, const char *argv[]) +{ + struct ipa_instance *ipi = vty->index; + struct ipa_instance *src = NULL, *dst = NULL; + uint32_t src_streamid, dst_streamid; + struct ipa_route *route, *matching_route = NULL; + struct ipa_route_shared *shared = NULL; + int ret; + + if (argc < 4) + return CMD_ERR_INCOMPLETE; + + llist_for_each_entry(ipi, &ipa_instance_list, head) { + if (strncmp(ipi->name, argv[0], IPA_INSTANCE_NAME) == 0) { + src = ipi; + continue; + } + if (strncmp(ipi->name, argv[2], IPA_INSTANCE_NAME) == 0) { + dst = ipi; + continue; + } + } + if (src == NULL) { + vty_out(vty, "%% instance `%s' does not exists%s", + argv[0], VTY_NEWLINE); + return CMD_WARNING; + } + if (dst == NULL) { + vty_out(vty, "%% instance `%s' does not exists%s", + argv[2], VTY_NEWLINE); + return CMD_WARNING; + } + if (src->net.type != IPA_INSTANCE_T_BIND) { + vty_out(vty, "%% instance `%s' is not of bind type%s", + argv[0], VTY_NEWLINE); + return CMD_WARNING; + } + if (dst->net.type != IPA_INSTANCE_T_CONNECT) { + vty_out(vty, "%% instance `%s' is not of connect type%s", + argv[2], VTY_NEWLINE); + return CMD_WARNING; + } + src_streamid = strtoul(argv[1], NULL, 16); + if (src_streamid > 0xff) { + vty_out(vty, "%% source streamid must be " + ">= 0x00 and <= 0xff%s", VTY_NEWLINE); + return CMD_WARNING; + } + dst_streamid = strtoul(argv[3], NULL, 16); + if (dst_streamid > 0xff) { + vty_out(vty, "%% destination streamid must be " + ">= 0x00 and <= 0xff%s", VTY_NEWLINE); + return CMD_WARNING; + } + llist_for_each_entry(route, &ipa_route_list, head) { + if (route->shared->src.inst == src && + route->shared->dst.inst == dst) { + if (route->src.streamid == src_streamid && + route->dst.streamid == dst_streamid) { + vty_out(vty, "%% this route already exists%s", + VTY_NEWLINE); + return CMD_WARNING; + } + matching_route = route; + break; + } + } + /* new route for this configuration. */ + route = talloc_zero(tall_bsc_ctx, struct ipa_route); + if (route == NULL) { + vty_out(vty, "%% can't allocate memory for new route%s", + VTY_NEWLINE); + return CMD_WARNING; + } + route->src.streamid = src_streamid; + route->dst.streamid = dst_streamid; + + if (matching_route != NULL) { + /* there's already a master route for these configuration. */ + if (matching_route->shared->src.inst != src) { + vty_out(vty, "%% route does not contain " + "source instance `%s'%s", + argv[0], VTY_NEWLINE); + return CMD_WARNING; + } + if (matching_route->shared->dst.inst != dst) { + vty_out(vty, "%% route does not contain " + "destination instance `%s'%s", + argv[2], VTY_NEWLINE); + return CMD_WARNING; + } + /* use already existing shared routing information. */ + shared = matching_route->shared; + } else { + /* this is a brand new route, allocate shared routing info. */ + shared = talloc_zero(tall_bsc_ctx, struct ipa_route_shared); + if (shared == NULL) { + vty_out(vty, "%% can't allocate memory for " + "new route shared%s", VTY_NEWLINE); + return CMD_WARNING; + } + shared->src.streamid_map.data_len = + sizeof(shared->src.streamid_map_data); + shared->src.streamid_map.data = + shared->src.streamid_map_data; + shared->dst.streamid_map.data_len = + sizeof(shared->dst.streamid_map_data); + shared->dst.streamid_map.data = + shared->dst.streamid_map_data; + + ret = make_sock(&shared->bfd, IPPROTO_TCP, INADDR_ANY, + ntohs(src->net.port), 0, + ipa_sock_src_accept_cb, route); + if (ret < 0) { + vty_out(vty, "%% can't bind instance `%s' to port%s", + src->name, VTY_NEWLINE); + return CMD_WARNING; + } + INIT_LLIST_HEAD(&shared->conn_list); + } + route->shared = shared; + src->refcnt++; + route->shared->src.inst = src; + dst->refcnt++; + route->shared->dst.inst = dst; + shared->src.streamid[src_streamid] = dst_streamid; + shared->dst.streamid[dst_streamid] = src_streamid; + ret = bitvec_set_bit_pos(&shared->src.streamid_map, src_streamid, ONE); + if (ret < 0) { + vty_out(vty, "%% bad bitmask (?)%s", VTY_NEWLINE); + return CMD_WARNING; + } + ret = bitvec_set_bit_pos(&shared->dst.streamid_map, dst_streamid, ONE); + if (ret < 0) { + vty_out(vty, "%% bad bitmask (?)%s", VTY_NEWLINE); + return CMD_WARNING; + } + shared->refcnt++; + + llist_add_tail(&route->head, &ipa_route_list); + return CMD_SUCCESS; +} + +DEFUN(ipa_route_add, ipa_route_add_cmd, + "ipa route instance NAME streamid HEXNUM " + "instance NAME streamid HEXNUM", "Add IPA route") +{ + return __ipa_route_add(vty, argc, argv); +} + +DEFUN(ipa_route_del, ipa_route_del_cmd, + "ipa no route instance NAME streamid HEXNUM " + "instance NAME streamid HEXNUM", "Delete IPA route") +{ + struct ipa_instance *ipi = vty->index; + struct ipa_instance *src = NULL, *dst = NULL; + uint32_t src_streamid, dst_streamid; + struct ipa_route *route, *matching_route = NULL; + struct ipa_conn *conn, *tmp; + + if (argc < 4) + return CMD_ERR_INCOMPLETE; + + llist_for_each_entry(ipi, &ipa_instance_list, head) { + if (strncmp(ipi->name, argv[0], IPA_INSTANCE_NAME) == 0) { + src = ipi; + continue; + } + if (strncmp(ipi->name, argv[2], IPA_INSTANCE_NAME) == 0) { + dst = ipi; + continue; + } + } + if (src == NULL) { + vty_out(vty, "%% instance `%s' does not exists%s", + argv[0], VTY_NEWLINE); + return CMD_WARNING; + } + if (dst == NULL) { + vty_out(vty, "%% instance `%s' does not exists%s", + argv[2], VTY_NEWLINE); + return CMD_WARNING; + } + if (src->net.type != IPA_INSTANCE_T_BIND) { + vty_out(vty, "%% instance `%s' is not of bind type%s", + argv[0], VTY_NEWLINE); + return CMD_WARNING; + } + if (dst->net.type != IPA_INSTANCE_T_CONNECT) { + vty_out(vty, "%% instance `%s' is not of connect type%s", + argv[2], VTY_NEWLINE); + return CMD_WARNING; + } + src_streamid = strtoul(argv[1], NULL, 16); + if (src_streamid > 0xff) { + vty_out(vty, "%% source streamid must be " + ">= 0x00 and <= 0xff%s", VTY_NEWLINE); + return CMD_WARNING; + } + dst_streamid = strtoul(argv[3], NULL, 16); + if (dst_streamid > 0xff) { + vty_out(vty, "%% destination streamid must be " + ">= 0x00 and <= 0xff%s", VTY_NEWLINE); + return CMD_WARNING; + } + llist_for_each_entry(route, &ipa_route_list, head) { + if (route->shared->src.inst == src && + route->shared->dst.inst == dst && + route->src.streamid == src_streamid && + route->dst.streamid == dst_streamid) { + matching_route = route; + break; + } + } + if (matching_route == NULL) { + vty_out(vty, "%% no route with that configuration%s", + VTY_NEWLINE); + return CMD_WARNING; + } + /* delete this route from list. */ + llist_del(&matching_route->head); + + if (--matching_route->shared->refcnt == 0) { + /* nobody else using this route, release all resources. */ + llist_for_each_entry_safe(conn, tmp, + &matching_route->shared->conn_list, head) { + bsc_unregister_fd(&conn->src.bfd); + close(conn->src.bfd.fd); + conn->src.bfd.fd = -1; + bsc_del_timer(&conn->dst.reconnect_timer); + if (conn->dst.bfd.fd != -1) { + bsc_unregister_fd(&conn->dst.bfd); + close(conn->dst.bfd.fd); + conn->dst.bfd.fd = -1; + } + llist_del(&conn->head); + talloc_free(conn); + } + bsc_unregister_fd(&route->shared->bfd); + close(route->shared->bfd.fd); + route->shared->bfd.fd = -1; + + talloc_free(route->shared); + } else { + /* otherwise, revert the mapping that this route applies. */ + bitvec_set_bit_pos(&matching_route->shared->src.streamid_map, + src_streamid, ZERO); + bitvec_set_bit_pos(&matching_route->shared->dst.streamid_map, + dst_streamid, ZERO); + matching_route->shared->src.streamid[src_streamid] = 0x00; + matching_route->shared->dst.streamid[dst_streamid] = 0x00; + } + matching_route->shared->src.inst->refcnt--; + matching_route->shared->dst.inst->refcnt--; + talloc_free(matching_route); + + return CMD_SUCCESS; +} + +DEFUN(ipa_route_show, ipa_route_show_cmd, + "ipa route show", "Show existing ipaccess proxy routes") +{ + struct ipa_route *this; + + llist_for_each_entry(this, &ipa_route_list, head) { + vty_out(vty, "route instance %s streamid 0x%.2x " + "instance %s streamid 0x%.2x%s", + this->shared->src.inst->name, this->src.streamid, + this->shared->dst.inst->name, this->dst.streamid, + VTY_NEWLINE); + } + return CMD_SUCCESS; +} + +/* + * Config for ipaccess-proxy + */ +DEFUN(ipa_cfg, ipa_cfg_cmd, "ipa", "Configure the ipaccess proxy") +{ + vty->index = NULL; + vty->node = IPA_NODE; + return CMD_SUCCESS; +} + +/* all these below look like enable commands, but without the ipa prefix. */ +DEFUN(ipa_route_cfg_add, ipa_route_cfg_add_cmd, + "route instance NAME streamid HEXNUM " + "instance NAME streamid HEXNUM", "Add IPA route") +{ + return __ipa_route_add(vty, argc, argv); +} + +DEFUN(ipa_instance_cfg_add, ipa_instance_cfg_add_cmd, + "instance NAME (bind|connect) IP tcp port PORT", + "Bind or connect instance to address and port") +{ + return __ipa_instance_add(vty, argc, argv); +} + +struct cmd_node ipa_node = { + IPA_NODE, + "%s(ipa)#", + 1, +}; + +static int ipa_cfg_write(struct vty *vty) +{ + bool heading = false; + struct ipa_instance *inst; + struct ipa_route *route; + + llist_for_each_entry(inst, &ipa_instance_list, head) { + if (!heading) { + vty_out(vty, "ipa%s", VTY_NEWLINE); + heading = true; + } + vty_out(vty, " instance %s %s %s tcp port %u%s", + inst->name, + inst->net.type == IPA_INSTANCE_T_BIND ? + "bind" : "connect", + inet_ntoa(inst->net.addr), + ntohs(inst->net.port), VTY_NEWLINE); + } + llist_for_each_entry(route, &ipa_route_list, head) { + vty_out(vty, " route instance %s streamid 0x%.2x " + "instance %s streamid 0x%.2x%s", + route->shared->src.inst->name, route->src.streamid, + route->shared->dst.inst->name, route->dst.streamid, + VTY_NEWLINE); + } + return CMD_SUCCESS; +} + +void ipaccess_vty_init(void) +{ + install_element(ENABLE_NODE, &ipa_cmd); + install_element(ENABLE_NODE, &ipa_instance_add_cmd); + install_element(ENABLE_NODE, &ipa_instance_del_cmd); + install_element(ENABLE_NODE, &ipa_instance_show_cmd); + install_element(ENABLE_NODE, &ipa_route_add_cmd); + install_element(ENABLE_NODE, &ipa_route_del_cmd); + install_element(ENABLE_NODE, &ipa_route_show_cmd); + + install_element(CONFIG_NODE, &ipa_cfg_cmd); + install_node(&ipa_node, ipa_cfg_write); + install_default(IPA_NODE); + install_element(IPA_NODE, &ournode_exit_cmd); + install_element(IPA_NODE, &ournode_end_cmd); + install_element(IPA_NODE, &ipa_instance_cfg_add_cmd); + install_element(IPA_NODE, &ipa_route_cfg_add_cmd); +} + int ipaccess_setup(struct gsm_network *gsmnet) { int ret; diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c index e052bda..9c1066d 100644 --- a/openbsc/src/libbsc/bsc_vty.c +++ b/openbsc/src/libbsc/bsc_vty.c @@ -2791,6 +2791,7 @@ int bsc_vty_init(const struct log_info *cat) abis_nm_vty_init(); abis_om2k_vty_init(); e1inp_vty_init(); + ipaccess_vty_init(); bsc_vty_init_extra(); diff --git a/openbsc/src/openbsc.cfg.ipa-proxy b/openbsc/src/openbsc.cfg.ipa-proxy new file mode 100644 index 0000000..30615da --- /dev/null +++ b/openbsc/src/openbsc.cfg.ipa-proxy @@ -0,0 +1,18 @@ +! +! Example file to setup an IPA proxy between ip.access nanoBTS and OpenBSC +! +password foo +! +line vty + no login +! +ipa + instance in0 bind 192.168.0.1 tcp port 3002 + instance out0 connect 192.168.0.2 tcp port 3002 + instance in1 bind 192.168.0.1 tcp port 3003 + instance out1 connect 192.168.0.2 tcp port 3003 + route instance in0 streamid 0xff instance out0 streamid 0xff + route instance in0 streamid 0xfe instance out0 streamid 0xfe + route instance in1 streamid 0x00 instance out1 streamid 0x00 + route instance in1 streamid 0xfe instance out1 streamid 0xfe +end diff --git a/openbsc/tests/db/Makefile.am b/openbsc/tests/db/Makefile.am index 98fdccc..2a21c0d 100644 --- a/openbsc/tests/db/Makefile.am +++ b/openbsc/tests/db/Makefile.am @@ -1,5 +1,5 @@ INCLUDES = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(COVERAGE_CFLAGS) +AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(COVERAGE_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) noinst_PROGRAMS = db_test @@ -11,5 +11,6 @@ db_test_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libabis/libabis.a \ $(top_builddir)/src/libtrau/libtrau.a \ $(top_builddir)/src/libcommon/libcommon.a \ - $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) -ldl -ldbi + $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) \ + -ldl -ldbi -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 19 17:47:47 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 19 Apr 2011 19:47:47 +0200 Subject: [PATCH 3/3] libabis: add IPA VTY command to setup ip.access nanoBTS OML and RSL links In-Reply-To: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> References: <1303235267-14168-1-git-send-email-pablo@gnumonks.org> Message-ID: <1303235267-14168-4-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch adds the following command: $ telnet localhost 4242 > enable # ipa setup To explicitly setup OML and RSL links. You can check that the sockets have been up by means of netstat: $ netstat -untap tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN 15204/osmo-nitb tcp 0 0 0.0.0.0:3003 0.0.0.0:* LISTEN 15204/osmo-nitb This changes the current behaviour of OpenBSC since it creates the OML and RSL sockets by default. I think that this is useful to have in case that you have no nanoBTS in your setup (for example, you use HSL femto instead). The command to disable nanoBTS OML and RSL links in runtime is not yet implemented, it shows the following: # ipa no setup %% sorry, disabling OML and RSL links in runtime is not yet implemented The main point of this patch is that we will be able to use openBSC as IPA proxy, instead of the standalone ipaccess-proxy tool. Since the OML and RSL ports for nanoBTS are no used by default, we can add an IPA route rule to bind to OML and RSL ports and forward them to the real BSC. Still, there are some features in ipaccess-proxy that are not available (like the UDP packet injection) but I expect to include them soon. --- openbsc/include/openbsc/ipaccess.h | 1 + openbsc/src/libabis/e1_input.c | 2 + openbsc/src/libabis/input/ipaccess.c | 83 +++++++++++++++++++++++------- openbsc/src/openbsc.cfg.nanobts | 3 + openbsc/src/openbsc.cfg.nanobts.multitrx | 3 + 5 files changed, 74 insertions(+), 18 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index 28ec49a..a9d31cb 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -87,6 +87,7 @@ int ipaccess_drop_oml(struct gsm_bts *bts); int ipaccess_drop_rsl(struct gsm_bts_trx *trx); void ipaccess_vty_init(void); +int e1inp_ipaccess_init(void); /* * Firmware specific header diff --git a/openbsc/src/libabis/e1_input.c b/openbsc/src/libabis/e1_input.c index 1a79261..8efef13 100644 --- a/openbsc/src/libabis/e1_input.c +++ b/openbsc/src/libabis/e1_input.c @@ -52,6 +52,7 @@ #include #include #include +#include #include "../../bscconfig.h" @@ -645,4 +646,5 @@ void e1inp_init(void) #ifdef HAVE_DAHDI_USER_H e1inp_dahdi_init(); #endif + e1inp_ipaccess_init(); } diff --git a/openbsc/src/libabis/input/ipaccess.c b/openbsc/src/libabis/input/ipaccess.c index 0cd3b2d..d117547 100644 --- a/openbsc/src/libabis/input/ipaccess.c +++ b/openbsc/src/libabis/input/ipaccess.c @@ -1621,6 +1621,50 @@ DEFUN(ipa_route_show, ipa_route_show_cmd, return CMD_SUCCESS; } +static bool ipa_setup_already = false; + +static int __ipa_setup(struct vty *vty, int argc, const char *argv[]) +{ + int ret; + + if (ipa_setup_already) { + vty_out(vty, "%% OML and RSL links has been already set up%s", + VTY_NEWLINE); + return CMD_WARNING; + } + /* Listen for OML connections */ + ret = make_sock(&e1h->listen_fd, IPPROTO_TCP, INADDR_ANY, + IPA_TCP_PORT_OML, 0, listen_fd_cb, NULL); + if (ret < 0) { + vty_out(vty, "%% cannot setup OML link, reason=`%s'%s", + strerror(errno), VTY_NEWLINE); + return CMD_WARNING; + } + /* Listen for RSL connections */ + ret = make_sock(&e1h->rsl_listen_fd, IPPROTO_TCP, INADDR_ANY, + IPA_TCP_PORT_RSL, 0, rsl_listen_fd_cb, NULL); + if (ret < 0) { + vty_out(vty, "%% cannot setup RSL link, reason=`%s'%s", + strerror(errno), VTY_NEWLINE); + return CMD_WARNING; + } + return CMD_SUCCESS; +} + +DEFUN(ipa_setup, ipa_setup_cmd, + "ipa setup", "Set up OML and RSL links for ip.access nanoBTS") +{ + return __ipa_setup(vty, argc, argv); +} + +DEFUN(ipa_setup_del, ipa_setup_del_cmd, + "ipa no setup", "Disable OML and RSL links for ip.access nanoBTS") +{ + vty_out(vty, "%% sorry, disabling OML and RSL links in runtime " + "is not yet implemented%s", VTY_NEWLINE); + return CMD_WARNING; +} + /* * Config for ipaccess-proxy */ @@ -1646,6 +1690,12 @@ DEFUN(ipa_instance_cfg_add, ipa_instance_cfg_add_cmd, return __ipa_instance_add(vty, argc, argv); } +DEFUN(ipa_setup_cfg, ipa_setup_cfg_cmd, + "setup", "Set up OML and RSL links for ip.access nanoBTS") +{ + return __ipa_setup(vty, argc, argv); +} + struct cmd_node ipa_node = { IPA_NODE, "%s(ipa)#", @@ -1677,12 +1727,17 @@ static int ipa_cfg_write(struct vty *vty) route->shared->dst.inst->name, route->dst.streamid, VTY_NEWLINE); } + if (ipa_setup_already) + vty_out(vty, " setup%s", VTY_NEWLINE); + return CMD_SUCCESS; } void ipaccess_vty_init(void) { install_element(ENABLE_NODE, &ipa_cmd); + install_element(ENABLE_NODE, &ipa_setup_cmd); + install_element(ENABLE_NODE, &ipa_setup_del_cmd); install_element(ENABLE_NODE, &ipa_instance_add_cmd); install_element(ENABLE_NODE, &ipa_instance_del_cmd); install_element(ENABLE_NODE, &ipa_instance_show_cmd); @@ -1695,37 +1750,29 @@ void ipaccess_vty_init(void) install_default(IPA_NODE); install_element(IPA_NODE, &ournode_exit_cmd); install_element(IPA_NODE, &ournode_end_cmd); + install_element(IPA_NODE, &ipa_setup_cfg_cmd); install_element(IPA_NODE, &ipa_instance_cfg_add_cmd); install_element(IPA_NODE, &ipa_route_cfg_add_cmd); } int ipaccess_setup(struct gsm_network *gsmnet) { + e1h->gsmnet = gsmnet; + return 0; +} + +int e1inp_ipaccess_init(void) +{ int ret; - /* register the driver with the core */ - /* FIXME: do this in the plugin initializer function */ ret = e1inp_driver_register(&ipaccess_driver); - if (ret) + if (ret < 0) return ret; + /* this is initialized via VTY commands and later ipaccess_setup(). */ e1h = talloc_zero(tall_bsc_ctx, struct ia_e1_handle); if (!e1h) return -ENOMEM; - e1h->gsmnet = gsmnet; - - /* Listen for OML connections */ - ret = make_sock(&e1h->listen_fd, IPPROTO_TCP, INADDR_ANY, - IPA_TCP_PORT_OML, 0, listen_fd_cb, NULL); - if (ret < 0) - return ret; - - /* Listen for RSL connections */ - ret = make_sock(&e1h->rsl_listen_fd, IPPROTO_TCP, INADDR_ANY, - IPA_TCP_PORT_RSL, 0, rsl_listen_fd_cb, NULL); - if (ret < 0) - return ret; - - return ret; + return 0; } diff --git a/openbsc/src/openbsc.cfg.nanobts b/openbsc/src/openbsc.cfg.nanobts index 3e7b932..e132655 100644 --- a/openbsc/src/openbsc.cfg.nanobts +++ b/openbsc/src/openbsc.cfg.nanobts @@ -73,3 +73,6 @@ network phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F + +ipa + setup diff --git a/openbsc/src/openbsc.cfg.nanobts.multitrx b/openbsc/src/openbsc.cfg.nanobts.multitrx index 9c9108c..969f50d 100644 --- a/openbsc/src/openbsc.cfg.nanobts.multitrx +++ b/openbsc/src/openbsc.cfg.nanobts.multitrx @@ -95,3 +95,6 @@ network phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F + +ipa + setup -- 1.7.2.3 From ammar_naamat1 at yahoo.com Wed Apr 20 05:31:09 2011 From: ammar_naamat1 at yahoo.com (Ammar Naamat Hameed) Date: Tue, 19 Apr 2011 22:31:09 -0700 (PDT) Subject: nanoBTS Message-ID: <202390.64233.qm@web45201.mail.sp1.yahoo.com> Hi All,? I wanna buy a nanoBTS, can you help with that please.?from where can I buy it and how much does it cost ? Thanks, Ammar -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher.henard at esial.net Wed Apr 20 05:54:59 2011 From: christopher.henard at esial.net (Christopher HENARD) Date: Wed, 20 Apr 2011 07:54:59 +0200 Subject: nanoBTS In-Reply-To: <202390.64233.qm@web45201.mail.sp1.yahoo.com> References: <202390.64233.qm@web45201.mail.sp1.yahoo.com> Message-ID: Hi, You can buy one from ip.access http://www.ipaccess.com/en/nanoGSM-picocell However, I have no idea regarding the price. You have to take contact with ip.access. chris 2011/4/20 Ammar Naamat Hameed > Hi All, > > I wanna buy a nanoBTS, can you help with that please. from where can I buy > it and how much does it cost ? > > Thanks, > Ammar > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Apr 20 07:10:30 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 20 Apr 2011 09:10:30 +0200 Subject: nanoBTS In-Reply-To: References: <202390.64233.qm@web45201.mail.sp1.yahoo.com> Message-ID: <20110420071030.GF31023@prithivi.gnumonks.org> Hi all, On Wed, Apr 20, 2011 at 07:54:59AM +0200, Christopher HENARD wrote: > You can buy one from ip.access http://www.ipaccess.com/en/nanoGSM-picocell > However, I have no idea regarding the price. You have to take contact with > ip.access. there are some companies and individuals that are in the business of re-selling them. I just don't really want to post this publicly on the list, as it would be advertising. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dburgess at jcis.net Thu Apr 21 02:35:11 2011 From: dburgess at jcis.net (David A. Burgess) Date: Wed, 20 Apr 2011 19:35:11 -0700 Subject: SIM programmer recommendations? Message-ID: All - I am looking for a full-card SIM programmer to use with pySim and GR-Card SIMs. By full-card I mean it accepts a full-size smart-card with the SIM still attached. I have tried the Bludrive II unit provided by GR-Card under both Mac OS X and Ubuntu with no luck. (And yes, I tried downloading and installing the drivers.) Can anyone recommend something that is known to work with pySim under Linux or OS X? Or is there some other driver that I need to install or configure? -- David From 246tnt at gmail.com Thu Apr 21 05:20:54 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 21 Apr 2011 07:20:54 +0200 Subject: SIM programmer recommendations? In-Reply-To: References: Message-ID: Hi, > I am looking for a full-card SIM programmer to use with pySim and GR-Card SIMs. I'd recommend any reader that is USB CCID compliant (so you don't need vendor specific drivers). http://pcsclite.alioth.debian.org/ccid/supported.html I hqve a gemalto pc twin reader personally. I use it under linux all the time (both with pcsc and other application). I also used it on mac osx but I never tried py-sim there. Cheers, Sylvain From laforge at gnumonks.org Thu Apr 21 06:52:27 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Apr 2011 08:52:27 +0200 Subject: SIM programmer recommendations? In-Reply-To: References: Message-ID: <20110421065227.GV31023@prithivi.gnumonks.org> Hi David, On Wed, Apr 20, 2011 at 07:35:11PM -0700, David A. Burgess wrote: > I am looking for a full-card SIM programmer to use with pySim and GR-Card > SIMs. By full-card I mean it accepts a full-size smart-card with the SIM > still attached. I have tried the Bludrive II unit provided by GR-Card under > both Mac OS X and Ubuntu with no luck. (And yes, I tried downloading and > installing the drivers.) Can anyone recommend something that is known to > work with pySim under Linux or OS X? Or is there some other driver that I > need to install or configure? Under Linux you can use any PC/SC supported smartcard reader, as long as you install pcsc-lite, and the device has a PC/SC ifd_handler driver. My personal recommendation are readers that support the USB CCID specification. CCID is a vendor-independent USB protocol for smart card readers, very similar to other generic USB classes like HID for keyboards. A list of well-known working readers is available from: http://pcsclite.alioth.debian.org/ccid/supported.html A more verbose list with 'should work' and 'don't work' can be found at http://pcsclite.alioth.debian.org/ccid/section.html I'm personally mostly using the Omnikey 3121 / 5121 readers here. 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 christopher.henard at esial.net Thu Apr 21 09:08:43 2011 From: christopher.henard at esial.net (Christopher HENARD) Date: Thu, 21 Apr 2011 11:08:43 +0200 Subject: intra BSC Handover Message-ID: Hello all, I want a confirmation. I 've seen in openBSC features that openBSC handles handover between cells inside one BSC. So I think it's possible to connect several nanoBTS to openBSC and move from one cell to another without losing the outgoing call. Am I right ? Thank you. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Apr 21 09:30:24 2011 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Apr 2011 11:30:24 +0200 Subject: intra BSC Handover In-Reply-To: References: Message-ID: <20110421093024.GF31023@prithivi.gnumonks.org> On Thu, Apr 21, 2011 at 11:08:43AM +0200, Christopher HENARD wrote: > I 've seen in openBSC features that openBSC handles handover between cells > inside one BSC. So I think it's possible to connect several nanoBTS to > openBSC and move from one cell to another without losing the outgoing call. > Am I right ? Yes, you are right. Please note, you need to use the --rtp-proxy option of osmo-nitb, as hand-over support is only enabled if the RTP data passes through OpenBSC, it can no longer be routed directly between the BTS's. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Apr 21 10:06:07 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 21 Apr 2011 12:06:07 +0200 Subject: intra BSC Handover In-Reply-To: References: Message-ID: <4DB0018F.3020103@freyther.de> On 04/21/2011 11:08 AM, Christopher HENARD wrote: > Hello all, > I want a confirmation. > > I 've seen in openBSC features that openBSC handles handover between cells > inside one BSC. So I think it's possible to connect several nanoBTS to openBSC > and move from one cell to another without losing the outgoing call. Am I right ? Yes, there is one bug in the RTP proxy code though. When we move the call we get a new RTP stream (sequence numbers, SSRC...) and our patching seems to add a lag. At public installations (congress) we have not suffered from this as LCR was handling this for us. From christopher.henard at esial.net Thu Apr 21 10:44:12 2011 From: christopher.henard at esial.net (Christopher HENARD) Date: Thu, 21 Apr 2011 12:44:12 +0200 Subject: intra BSC Handover In-Reply-To: <4DB0018F.3020103@freyther.de> References: <4DB0018F.3020103@freyther.de> Message-ID: I understand, thank you both of you. 2011/4/21 Holger Hans Peter Freyther > On 04/21/2011 11:08 AM, Christopher HENARD wrote: > > Hello all, > > I want a confirmation. > > > > I 've seen in openBSC features that openBSC handles handover between > cells > > inside one BSC. So I think it's possible to connect several nanoBTS to > openBSC > > and move from one cell to another without losing the outgoing call. Am I > right ? > > Yes, there is one bug in the RTP proxy code though. When we move the call > we > get a new RTP stream (sequence numbers, SSRC...) and our patching seems to > add > a lag. At public installations (congress) we have not suffered from this as > LCR was handling this for us. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at gnumonks.org Tue Apr 26 01:07:46 2011 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Tue, 26 Apr 2011 03:07:46 +0200 Subject: [PATCH] include: fix missing extern in osmo_panic* declarations Message-ID: <1303780066-2565-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This patch adds the missing extern to osmo_panic* declarations. --- include/osmocom/core/panic.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/osmocom/core/panic.h b/include/osmocom/core/panic.h index c5a8377..c28a844 100644 --- a/include/osmocom/core/panic.h +++ b/include/osmocom/core/panic.h @@ -5,7 +5,7 @@ typedef void (*osmo_panic_handler_t)(const char *fmt, va_list args); -void osmo_panic(const char *fmt, ...); -void osmo_set_panic_handler(osmo_panic_handler_t h); +extern void osmo_panic(const char *fmt, ...); +extern void osmo_set_panic_handler(osmo_panic_handler_t h); #endif -- 1.7.2.3 From pablo at gnumonks.org Tue Apr 26 01:15:28 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Tue, 26 Apr 2011 03:15:28 +0200 Subject: [PATCH] include: fix missing extern in osmo_panic* declarations In-Reply-To: <1303780066-2565-1-git-send-email-pablo@gnumonks.org> References: <1303780066-2565-1-git-send-email-pablo@gnumonks.org> Message-ID: <4DB61CB0.2080502@gnumonks.org> On 26/04/11 03:07, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso ^^^^^^^^^^^^^ Two comments on this my own patch: * This patch is so small that I didn't create a branch for it, so please git-am it :-). * Mangle my email, as you can notice I added .orgt instead of .org. Thanks! > This patch adds the missing extern to osmo_panic* declarations. > --- > include/osmocom/core/panic.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/osmocom/core/panic.h b/include/osmocom/core/panic.h > index c5a8377..c28a844 100644 > --- a/include/osmocom/core/panic.h > +++ b/include/osmocom/core/panic.h > @@ -5,7 +5,7 @@ > > typedef void (*osmo_panic_handler_t)(const char *fmt, va_list args); > > -void osmo_panic(const char *fmt, ...); > -void osmo_set_panic_handler(osmo_panic_handler_t h); > +extern void osmo_panic(const char *fmt, ...); > +extern void osmo_set_panic_handler(osmo_panic_handler_t h); > > #endif From laforge at gnumonks.org Tue Apr 26 12:37:33 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 26 Apr 2011 14:37:33 +0200 Subject: [PATCH] include: fix missing extern in osmo_panic* declarations In-Reply-To: <1303780066-2565-1-git-send-email-pablo@gnumonks.org> References: <1303780066-2565-1-git-send-email-pablo@gnumonks.org> Message-ID: <20110426123733.GB655@prithivi.gnumonks.org> On Tue, Apr 26, 2011 at 03:07:46AM +0200, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso > > This patch adds the missing extern to osmo_panic* declarations. thanks, applied (with fix to typo in email address) -- - 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 Wed Apr 27 12:11:29 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 27 Apr 2011 14:11:29 +0200 Subject: Your http://openbsc.mciroembedded.com/ site Message-ID: <20110427121129.GB8371@prithivi.gnumonks.org> Hi "Mr. Unknown", it has come to my attention that you are running a copy of our OpenBSC website (http://openbsc.osmocom.org/) at http://openbsc.microembedded.com/ We appreciate your enthusiasm for OpenBSC and like to thank you for your work on the Chinese translation. However, it would have been good to coordinate about this with us. Making a copy of the website as a sub-domain to your company "MicroEmbedded" may seem to some people as if you were representing the OpenBSC project (which you are not), or that OpenBSC is somehow a work of your MicroEmbedded company. After some checking, it seems that the final line on each page "?? BscHack ?????? ?????????? OpenBSC ?????! email: support at microembedded.com ?" provides a link to the orignal page at bs11-abis.gnumonks.org. Once again in this link you provide your e-mail address, followed by the company footer of your web-page. The contents of the OpenBSC website has copyright, and we do not think it is appropriate for you to associate your company in this way with OpenBSC. You are not a member of the project, you have not contributed to the OpenBSC software, and you have not contacted us about obtainign permission to make such a translated copy. Furthermore, there are several problems with your website: 1) it is out of date, as you have used a very old version of the OpenBSC website to translate. As a result, quite some of your links back to the original OpenBSC site are broken. 2) You have introduced capitalization changes like "$ Sqlite" which will not work, as the command is "$ sqlite" If your intentions in running a translated OpenBSC site are honest, I would like to invite you to do so in working together with us. We can provide you with the respective space on the official homepage, and you can contribute your translated content there. In return, we may put a "thank you" link to microembedded.com in the Thanks section at http://openbsc.osmocom.org/trac/wiki#Thanks We hope this is acceptable to you. In any case, we hope you can understand that we will not tolerate you putting your company name next to a copy of the OpenBSC wiki. 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 laforge at gnumonks.org Wed Apr 27 12:16:20 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 27 Apr 2011 14:16:20 +0200 Subject: Licensing of the wiki Message-ID: <20110427121620.GM655@prithivi.gnumonks.org> Hi all, so far we do not have any statement about the licensing of the content on our wiki. This means the default copyright rules apply: All the content is copyrighted, and nobody has any rgiht to reproduce it at all. I would like to propose an official license for the content in the wiki: Create Commons CC-BY-SA. The alternative would be to go for CC-BY-NC-SA, disallowing commercial use of the content. I'm not certain if NC is really what we want. After all, even somebody using OpenBSC in a commercial environment should be able to make copies of the reference documentation we have available - as long as he will releas the result again (which the SA part already covers). If the major contributors to the wiki would agree to a license, I would update the wiki accordingly. Thanks, 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 Wed Apr 27 12:55:56 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Wed, 27 Apr 2011 12:55:56 +0000 Subject: Licensing of the wiki In-Reply-To: <20110427121620.GM655@prithivi.gnumonks.org> Message-ID: <000e0ce0b65624622504a1e5f699@google.com> > If the major contributors to the wiki would agree to a license, I would > update the wiki accordingly. FWIW, CC-BY-SA is fine for me. I also don't really see the need for NC here. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Apr 27 16:46:29 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 27 Apr 2011 18:46:29 +0200 Subject: TODO: openbsc.cfg console logging options Message-ID: <20110427164629.GC655@prithivi.gnumonks.org> Hi Pablo! I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work. This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version. Maybe you can find some time to investigate and fix the issue. 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 holger at freyther.de Fri Apr 29 14:57:36 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 29 Apr 2011 16:57:36 +0200 Subject: TODO: openbsc.cfg console logging options In-Reply-To: <20110427164629.GC655@prithivi.gnumonks.org> References: <20110427164629.GC655@prithivi.gnumonks.org> Message-ID: <4DBAD1E0.10802@freyther.de> On 04/27/2011 06:46 PM, Harald Welte wrote: > Hi Pablo! > > I've recently received a bug report that somehow the config-file-stored > configuration of which log levels/subsystems to enable on stderr don't work. > > This may be related to the legacy "-d DINP:DNM:... style log level > specifications, e.g. we first read the config file and then set some default > logging options usign the legacy version. > I have seen that '-e 1' specified on the CLI will be ignored (at least on osmo-bsc). I think we should define an order of when to apply this and when to read the config file. From pablo at gnumonks.org Fri Apr 29 19:27:05 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 29 Apr 2011 21:27:05 +0200 Subject: TODO: openbsc.cfg console logging options In-Reply-To: <4DBAD1E0.10802@freyther.de> References: <20110427164629.GC655@prithivi.gnumonks.org> <4DBAD1E0.10802@freyther.de> Message-ID: <4DBB1109.8050506@gnumonks.org> On 29/04/11 16:57, Holger Hans Peter Freyther wrote: > On 04/27/2011 06:46 PM, Harald Welte wrote: >> Hi Pablo! >> >> I've recently received a bug report that somehow the config-file-stored >> configuration of which log levels/subsystems to enable on stderr don't work. >> >> This may be related to the legacy "-d DINP:DNM:... style log level >> specifications, e.g. we first read the config file and then set some default >> logging options usign the legacy version. > > I have seen that '-e 1' specified on the CLI will be ignored (at least on > osmo-bsc). I think we should define an order of when to apply this and when to > read the config file. It seems -e 1 is broken if: * -d is not passed * -d is passed after -e. We don't check this sort of dependencies. May this be related to the problem that you noticed? From pablo at gnumonks.org Fri Apr 29 20:16:33 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 29 Apr 2011 22:16:33 +0200 Subject: TODO: openbsc.cfg console logging options In-Reply-To: <4DBB1109.8050506@gnumonks.org> References: <20110427164629.GC655@prithivi.gnumonks.org> <4DBAD1E0.10802@freyther.de> <4DBB1109.8050506@gnumonks.org> Message-ID: <4DBB1CA1.80808@gnumonks.org> On 29/04/11 21:27, Pablo Neira Ayuso wrote: > On 29/04/11 16:57, Holger Hans Peter Freyther wrote: >> On 04/27/2011 06:46 PM, Harald Welte wrote: >>> Hi Pablo! >>> >>> I've recently received a bug report that somehow the config-file-stored >>> configuration of which log levels/subsystems to enable on stderr don't work. >>> >>> This may be related to the legacy "-d DINP:DNM:... style log level >>> specifications, e.g. we first read the config file and then set some default >>> logging options usign the legacy version. >> >> I have seen that '-e 1' specified on the CLI will be ignored (at least on >> osmo-bsc). I think we should define an order of when to apply this and when to >> read the config file. > > It seems -e 1 is broken if: > > * -d is not passed > * -d is passed after -e. > > We don't check this sort of dependencies. May this be related to the > problem that you noticed? Sorry, I misunderstood the code, my statement above is not true. I'll investigate what Holger points out. From pablo at gnumonks.org Fri Apr 29 23:49:12 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Sat, 30 Apr 2011 01:49:12 +0200 Subject: TODO: openbsc.cfg console logging options In-Reply-To: <4DBAD1E0.10802@freyther.de> References: <20110427164629.GC655@prithivi.gnumonks.org> <4DBAD1E0.10802@freyther.de> Message-ID: <4DBB4E78.5000800@gnumonks.org> Hi Holger, On 29/04/11 16:57, Holger Hans Peter Freyther wrote: > On 04/27/2011 06:46 PM, Harald Welte wrote: >> Hi Pablo! >> >> I've recently received a bug report that somehow the config-file-stored >> configuration of which log levels/subsystems to enable on stderr don't work. >> >> This may be related to the legacy "-d DINP:DNM:... style log level >> specifications, e.g. we first read the config file and then set some default >> logging options usign the legacy version. >> > > I have seen that '-e 1' specified on the CLI will be ignored (at least on > osmo-bsc). I think we should define an order of when to apply this and when to > read the config file. Could you develop the scenario a bit? The problem that you refer would occur if `-d' and `-e' are used? From pablo at gnumonks.org Fri Apr 29 19:24:40 2011 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 29 Apr 2011 21:24:40 +0200 Subject: TODO: openbsc.cfg console logging options In-Reply-To: <20110427164629.GC655@prithivi.gnumonks.org> References: <20110427164629.GC655@prithivi.gnumonks.org> Message-ID: <4DBB1078.3040304@gnumonks.org> On 27/04/11 18:46, Harald Welte wrote: > Hi Pablo! > > I've recently received a bug report that somehow the config-file-stored > configuration of which log levels/subsystems to enable on stderr don't work. > > This may be related to the legacy "-d DINP:DNM:... style log level > specifications, e.g. we first read the config file and then set some default > logging options usign the legacy version. It seems to be the opposite as for the existing code. > Maybe you can find some time to investigate and fix the issue. Looking at the code, we first parse the command line options and, then, the config file (by calling bsc_bootstrap_network). Extracted from libosmocore/src/vty/logging_vty.c: DEFUN(cfg_log_stderr, cfg_log_stderr_cmd, "log stderr", LOG_STR "Logging via STDERR of the process\n") { struct log_target *tgt; tgt = log_target_find(LOG_TGT_TYPE_STDERR, NULL); if (!tgt) { tgt = log_target_create_stderr(); if (!tgt) { vty_out(vty, "%% Unable to create stderr log%s", VTY_NEWLINE); return CMD_WARNING; } log_add_target(tgt); } In the config file parsing, it seems that we skip adding a logging target of stderr type if we already got one for stderr. This looks fine to me, since the command line options should override the config file settings. Should we consider this feature instead of a bug? :-)