15 May
2017
15 May
'17
9:52 p.m.
On 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_ip…]
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