This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Sun, May 14, 2017 at 02:03:28PM +0200, Andreas Mueller wrote: > Hello, > > I had success running an 3G network with the nano3G femtocell and osmocom-software a month ago, but I did not follow the changes which happend during the last 4 weeks. > With the latest version of the software from git I am not able to register any phone on the network! I just cleared my system of osmocom and ran the script https://osmocom.org/attachments/download/2670/clone_and_build_osmocom_3g.sh and using the 3G-config-example.tar to verify. In summary, all works as expected for me! I found an error in the instructions to add an entry to the hlr.db (we've added another column which was missing in the example and on the wiki). And I've seen the sporadic failure of data service which I reported a while back in https://osmocom.org/issues/1977 . I fixed the doc errors, also tweaked a bit, and this time around enclosed the clone_and_build_osmocom_3g.sh in the 3G-config-example.tar. Uploaded on the wiki. Since all works for me, let me try to see what went wrong for you: > The test result of 3 different phones: > * iPhone: Can see the 3G network, but cannot join > * Samsung S5 duos: Not seeing the network, when searching for providers > * Acer Liqid M330: Not able to join the network I usually use a Samsung S4mini. Note that our nano3G is on US band, some devices may only have EU band. Note that when a phone was once subscribed, the SIM card remembers the name it sends out. Before that, the MCC+MNC codes may be interpreted from an internal list kept in the SIM card. For me, I usually see the network as '90198' (i.e. MCC+MNC), and when first subscribed, that instead becomes 'OsmoMSC' (as from osmo-msc.cfg). > What I did: > * checked out the latest source-code and compiled it with the script osmocom.org/attachments/download/2670/clone_and_build_osmocom_3g.sh after completely removing the old source code > [I had to change the script to use "sudo make install", because /usr/local/ is not writable for users on my system] I added a hint to adjust the prefix in the new version. I usually just do 'sudo chown -R $USER /usr/local' since it's anyway only me writing to that location. Saves the trouble of setting LD_LIBRARY_PATH and PATH env. > => When I checked the created directories I realized, that "/usr/local/include/openbsc " has a trailing space! Not related to 3G, but hey, that's right! What the hell! Fixed in https://gerrit.osmocom.org/2649 (though I'd have expected openbsc to live in osmocom/ ...) > * I verifyed, that all needed dependencies mentioned in clone_and_build_osmocom_3g.sh are installed (running debian8 32bit) I'm running 64bit ... I dearly hope that that is not an issue! > * verifyed that the initial config of the nano3G [according to http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G] is present Yes, I also used that 1:1 now. > * I checked my config-files ggsn.conf, osmo-hlr.cfg, osmo-msc.cfg, mgcp.cfg, osmo-hnbgw.cfg, osmo-sgsn.cfg against those provided by osmocom.org/attachments/download/2669/3G-config-example.tar, but they only differ in ip-addresses and ip-networks due to my local network configuration. The IP addresses in the example are conveniently exactly those that I'm using on my computer. I trust that you understand those, if in doubt attach your configs so I can take a look. > * I created a new hlr.db with > sqlite3 hlr.db < src/osmo-hlr/sql/hlr.sql > sqlite3 hlr.db < own_hlr.sql yes > echo "update auc_3g set sqn = 32 where sqn < 32;" | sqlite3 hlr.db ^ This is no longer needed, but not harmful either. It was actually a missing software feature because I had a far too simplistic understanding of how SQNs work. I just realized that it was still on the wiki page, removed that part now. > with own_hlr.sql containing the IMSIs and auth-data of the used USIM-cards like: > INSERT INTO "subscriber" (id, imsi, msisdn) VALUES(1,'901700000014910','1111'); > INSERT INTO "auc_3g" VALUES(1,5,'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx','yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy',NULL,32,5); (This auc_3g line needed fixing in the example.) Hold on, you're actually entering an OP and not an OPC? Are you sure that's correct? The 'yyy...' is in the OP column. With sysmoUSIM I usually use the OPC column instead, i.e. 'xxx', NULL, 'yyy'. The fixed example uses explicit column names: sqlite> insert into auc_3g (subscriber_id, algo_id_3g, k, opc) values (2342, 5, '0102030405060708090a0b0c0d0e0f00', 'f0e0d0c0b0a090807060504030201000'); > When running the network and trying to join with different smartphones: > > => in sgsn.log I can see messages like: > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:699 SUBSCR(901700000014913) Received GSUP message OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:455 SUBSCR(901700000014913) Send authentication info has failed with cause 2, handled as: Permission denied > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:463 SUBSCR(901700000014913) GPRS send auth info req failed, access denied, GMM cause = 'IMSI unknown in HLR' (2) > ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:813 SUBSCR(901700000014913) Updating subscriber authentication info IMSI unknown in HLR is maybe some unrelated phone trying to camp on your network? OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR means that no auth tuples were obtained from the HLR. Also take a look at the osmo-hlr log? > => when looking at the RANAP-packages captured from eth0 I can see also "GSM A-I/F DTAP - Attach Reject" "GMM Cause: IMSI unknown in HLR" > > * I checked, that the IMSIs and auth-data is present in hlr.db > > => I observed that for one subscriber (the Acer Phone, which was connected to the network with a previous version of the software) the sqn number in auc_3g Table is increased, where the value of other subscribers is still 32 (=initial value) Looks like this gets auth tuples generated, but something fails later on. Hard to say from the distance. > => in hnbgw.log I can only see the IMSI of the acer-phone, but not of the two other phones. So it looks like phones who had joined the network before are seen there, but phones which IMSIs are new to the network do not show up there Are you sure you have allowed those IMSIs access to the nano3G on the dmi? that "open access" would allow all. > ESC[0;m20170514014439016 DHNBAP <0001> hnbgw_hnbap.c:436 UE-REGISTER-REQ ID_type=1 imsi=901700000014913 cause=1 > ESC[0;m20170514014439016 DHNBAP <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014913, tmsi 0x0 > > => in hlr.log I can also only the the IMSI of the Acer phone (keys changed) when 5 vectors are created: > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:132 901700000014913: No 2G Auth Data > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:213 901700000014913: Calling to generate 5 vectors > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:94 Computing 5 auth vectors: 3G only (2G derived from 3G keys) > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:96 3G: k = kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:99 3G: OP = oooooooooooooooooooooooooooooooo (again, I typically use OPC with sysmoUSIM) > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:101 3G: for sqn ind 0, previous sqn was 32 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:113 vector [0]: rand = rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:137 vector [0]: sqn = 64 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:139 vector [0]: autn = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:140 vector [0]: ck = cccccccccccccccccccccccccccccccc > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:141 vector [0]: ik = iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:142 vector [0]: res = 22222222222222222222222222222222 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:143 vector [0]: res_len = 8 > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:147 vector [0]: kc = kckckckckckckck > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:148 vector [0]: sres = resrestes > ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:149 vector [0]: auth_types = 0x3 > .... > > I am running the network as non-privileged user (only ggsn with sudo), but this user can write hlr.db. That should be fine. > Does this user also need to have write-access to files under /usr/local ? No. > As it looks to me that there is a problem with new USIMs, which have never joined the network: Do the USIMs need special preparation for joining the network? (the USIMs are bought from the sysmocom-shop) Try using OPC instead! Let us know of your progress... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170515/7fde387b/attachment.bin>