Hi all, Today I'm working on updating my NuRAN unit with the new osmo stack in order to try to reproduce the same behavior of old osmo-nitb we use in production in Rhizomatica (with subscriber_create_on_demand feature on).
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Best regards, Rafael Diniz
Hi Rafael,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Regards, Harald
Hi Harald,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
Cheers, Rafael Diniz
Hey Rafael,
On 7/13/19 5:55 PM, Rafael Diniz wrote:
Hi Harald,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
As Harald pointed out, the documentation could use some more examples. I'll update the docs accordingly, but to make your life easier, here are the configuration options relevant for your use case (with sending the IMEI to the HLR).
osmo-msc.cfg: msc check-imei early
osmo-hlr.cfg: hlr subscriber-create-on-demand 5 none store-imei
This will create 5 digit MSISDNs for the subscribers, and disable CS NAM and PS NAM by default (circuit switched and packet switched network access modes). Subscribers can't make phone calls or use cellular data, so their phones will not connect to the network, but the entry in the HLR will be created.
After a new subscriber was created, it will look like this in the VTY (I've replaced the real IMEI and IMSI with zeros):
OsmoHLR> enable OsmoHLR# subscriber imei 00000000000000 show ID: 1 IMSI: 000000000000000 MSISDN: 58192 <- randomly generated IMEI: 000000000000000 CS disabled PS disabled
The idea is now to enable CS and PS for the IMEIs that you know. Right now, the documentation says:
In order to do that, one can set the default NAM to none and manually approve new subscribers by enabling their nam_cs and nam_ps parameters (e.g. over the VTY).
But as I was about to create an example of how these commands look like, I realized that VTY commands for changing nam_cs and nam_ps don't actually exist yet :\ So for now, these flags have to be changed manually in the sqlite database... change nam_cs and nam_ps to 1 in the subscriber table. Maybe this is still useful for testing. I will add the missing VTY commands shortly.
Cheers, Rafael Diniz
Cheers, Oliver
"check-imei-rqd early", not "check-imei early"
On 7/15/19 10:05 AM, Oliver Smith wrote:
Hey Rafael,
On 7/13/19 5:55 PM, Rafael Diniz wrote:
Hi Harald,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
As Harald pointed out, the documentation could use some more examples. I'll update the docs accordingly, but to make your life easier, here are the configuration options relevant for your use case (with sending the IMEI to the HLR).
osmo-msc.cfg: msc check-imei early
osmo-hlr.cfg: hlr subscriber-create-on-demand 5 none store-imei
This will create 5 digit MSISDNs for the subscribers, and disable CS NAM and PS NAM by default (circuit switched and packet switched network access modes). Subscribers can't make phone calls or use cellular data, so their phones will not connect to the network, but the entry in the HLR will be created.
After a new subscriber was created, it will look like this in the VTY (I've replaced the real IMEI and IMSI with zeros):
OsmoHLR> enable OsmoHLR# subscriber imei 00000000000000 show ID: 1 IMSI: 000000000000000 MSISDN: 58192 <- randomly generated IMEI: 000000000000000 CS disabled PS disabled
The idea is now to enable CS and PS for the IMEIs that you know. Right now, the documentation says:
In order to do that, one can set the default NAM to none and manually approve new subscribers by enabling their nam_cs and nam_ps parameters (e.g. over the VTY).
But as I was about to create an example of how these commands look like, I realized that VTY commands for changing nam_cs and nam_ps don't actually exist yet :\ So for now, these flags have to be changed manually in the sqlite database... change nam_cs and nam_ps to 1 in the subscriber table. Maybe this is still useful for testing. I will add the missing VTY commands shortly.
Cheers, Rafael Diniz
Cheers, Oliver
Thanks a lot, Oliver!
The VTY commands for changing nam_cs and nam_ps will be useful. ; )
Any problems I let you know!
Cheers, Rafael Diniz
On 7/15/19 5:08 AM, Oliver Smith wrote:
"check-imei-rqd early", not "check-imei early"
On 7/15/19 10:05 AM, Oliver Smith wrote:
Hey Rafael,
On 7/13/19 5:55 PM, Rafael Diniz wrote:
Hi Harald,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
As Harald pointed out, the documentation could use some more examples. I'll update the docs accordingly, but to make your life easier, here are the configuration options relevant for your use case (with sending the IMEI to the HLR).
osmo-msc.cfg: msc check-imei early
osmo-hlr.cfg: hlr subscriber-create-on-demand 5 none store-imei
This will create 5 digit MSISDNs for the subscribers, and disable CS NAM and PS NAM by default (circuit switched and packet switched network access modes). Subscribers can't make phone calls or use cellular data, so their phones will not connect to the network, but the entry in the HLR will be created.
After a new subscriber was created, it will look like this in the VTY (I've replaced the real IMEI and IMSI with zeros):
OsmoHLR> enable OsmoHLR# subscriber imei 00000000000000 show ID: 1 IMSI: 000000000000000 MSISDN: 58192 <- randomly generated IMEI: 000000000000000 CS disabled PS disabled
The idea is now to enable CS and PS for the IMEIs that you know. Right now, the documentation says:
In order to do that, one can set the default NAM to none and manually approve new subscribers by enabling their nam_cs and nam_ps parameters (e.g. over the VTY).
But as I was about to create an example of how these commands look like, I realized that VTY commands for changing nam_cs and nam_ps don't actually exist yet :\ So for now, these flags have to be changed manually in the sqlite database... change nam_cs and nam_ps to 1 in the subscriber table. Maybe this is still useful for testing. I will add the missing VTY commands shortly.
Cheers, Rafael Diniz
Cheers, Oliver
Hello Rafael,
you're welcome. I've just merged the new VTY command and manuals update to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual
So if you rebuild your osmo-hlr packages from master, you should have the command (if I understood correctly that you are building the packages yourself, otherwise it will be in the nightly packages tomorrow).
After a subscriber has been created on demand, with network access mode set to "none", you can give the subscriber access to circuit and packet switched services as follows:
OsmoHLR> enable OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848 CS disabled PS disabled OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848
Cheers, Oliver
On 7/15/19 3:26 PM, Rafael Diniz wrote:
Thanks a lot, Oliver!
The VTY commands for changing nam_cs and nam_ps will be useful. ; )
Any problems I let you know!
Cheers, Rafael Diniz
On 7/15/19 5:08 AM, Oliver Smith wrote:
"check-imei-rqd early", not "check-imei early"
On 7/15/19 10:05 AM, Oliver Smith wrote:
Hey Rafael,
On 7/13/19 5:55 PM, Rafael Diniz wrote:
Hi Harald,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
I'm writing just in case someone already put online a set of config files with the parameters needed by such behavior set? ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
ps: I have the new splip stack working fine here, I just need to modify my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
As Harald pointed out, the documentation could use some more examples. I'll update the docs accordingly, but to make your life easier, here are the configuration options relevant for your use case (with sending the IMEI to the HLR).
osmo-msc.cfg: msc check-imei early
osmo-hlr.cfg: hlr subscriber-create-on-demand 5 none store-imei
This will create 5 digit MSISDNs for the subscribers, and disable CS NAM and PS NAM by default (circuit switched and packet switched network access modes). Subscribers can't make phone calls or use cellular data, so their phones will not connect to the network, but the entry in the HLR will be created.
After a new subscriber was created, it will look like this in the VTY (I've replaced the real IMEI and IMSI with zeros):
OsmoHLR> enable OsmoHLR# subscriber imei 00000000000000 show ID: 1 IMSI: 000000000000000 MSISDN: 58192 <- randomly generated IMEI: 000000000000000 CS disabled PS disabled
The idea is now to enable CS and PS for the IMEIs that you know. Right now, the documentation says:
In order to do that, one can set the default NAM to none and manually approve new subscribers by enabling their nam_cs and nam_ps parameters (e.g. over the VTY).
But as I was about to create an example of how these commands look like, I realized that VTY commands for changing nam_cs and nam_ps don't actually exist yet :\ So for now, these flags have to be changed manually in the sqlite database... change nam_cs and nam_ps to 1 in the subscriber table. Maybe this is still useful for testing. I will add the missing VTY commands shortly.
Cheers, Rafael Diniz
Cheers, Oliver
Hi Oliver,
you're welcome. I've just merged the new VTY command and manuals update to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual
thanks!
So if you rebuild your osmo-hlr packages from master, you should have the command (if I understood correctly that you are building the packages yourself, otherwise it will be in the nightly packages tomorrow).
I'm using the armhf nightly builds (running on the cpu of the bts unit), except for the bts and pcu which needs appropriate lc15 flags so I compile by hand from git master.
After a subscriber has been created on demand, with network access mode set to "none", you can give the subscriber access to circuit and packet switched services as follows:
OsmoHLR> enable OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848 CS disabled PS disabled OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848
That is what I need for testing, perfect.
Cheers, Rafael Diniz
Hi Oliver,
I managed to test a bit, and just two issues in the log which I saw:
When a phone try to connect (not present in the hlr db yet):
0000> hlr.c:204 IMSI='724056816211859': Creating subscriber on demand <0000> hlr.c:220 IMSI='724056816211859': Successfully assigned MSISDN='76342' <0003> hlr.c:510 IMSI='724056816211859': storing IMEI = 35345609112072
<0000> luop.c:161 LU OP state change: NULL -> LU RECEIVED <0000> luop.c:175 724056816211859: LU OP Tx Error (cause PLMN not allowed)
And after giving "cs+ps" permission, when trying to set to "none" again, I get:
<0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:370 127.0.0.1:60216 sending data <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60210 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60216 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60210 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859
Anyway, in it is working as expected! I'll investigate the logs further.
Cheers, Rafael Diniz
On 7/16/19 4:27 AM, Oliver Smith wrote:
Hello Rafael,
you're welcome. I've just merged the new VTY command and manuals update to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual
So if you rebuild your osmo-hlr packages from master, you should have the command (if I understood correctly that you are building the packages yourself, otherwise it will be in the nightly packages tomorrow).
After a subscriber has been created on demand, with network access mode set to "none", you can give the subscriber access to circuit and packet switched services as follows:
OsmoHLR> enable OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848 CS disabled PS disabled OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848
Cheers, Oliver
On 7/15/19 3:26 PM, Rafael Diniz wrote:
Thanks a lot, Oliver!
The VTY commands for changing nam_cs and nam_ps will be useful. ; )
Any problems I let you know!
Cheers, Rafael Diniz
On 7/15/19 5:08 AM, Oliver Smith wrote:
"check-imei-rqd early", not "check-imei early"
On 7/15/19 10:05 AM, Oliver Smith wrote:
Hey Rafael,
On 7/13/19 5:55 PM, Rafael Diniz wrote:
Hi Harald,
On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote: > Today I'm working on updating my NuRAN unit with the new osmo stack
Can you clarify which particular model/unit that is?
I would assume that the 'nightly' OE packages sysmocom provides should have all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
> I'm writing just in case someone already put online a set of config > files with the parameters needed by such behavior set? > ; )
I would be careful with full configuration files, as they contain all kinds of settings which may or may not do what you want. The settings for subcsriber-create-on-demand are only 2-3, AFAIR.
> ps: I have the new splip stack working fine here, I just need to modify > my setup with new features to support subscriber_create_on_demand.
Then please simply use the config files you have and not start with something else just because you need to modify one or very few lines...
See https://osmocom.org/issues/2542 where Oliver actually also points to a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
As Harald pointed out, the documentation could use some more examples. I'll update the docs accordingly, but to make your life easier, here are the configuration options relevant for your use case (with sending the IMEI to the HLR).
osmo-msc.cfg: msc check-imei early
osmo-hlr.cfg: hlr subscriber-create-on-demand 5 none store-imei
This will create 5 digit MSISDNs for the subscribers, and disable CS NAM and PS NAM by default (circuit switched and packet switched network access modes). Subscribers can't make phone calls or use cellular data, so their phones will not connect to the network, but the entry in the HLR will be created.
After a new subscriber was created, it will look like this in the VTY (I've replaced the real IMEI and IMSI with zeros):
OsmoHLR> enable OsmoHLR# subscriber imei 00000000000000 show ID: 1 IMSI: 000000000000000 MSISDN: 58192 <- randomly generated IMEI: 000000000000000 CS disabled PS disabled
The idea is now to enable CS and PS for the IMEIs that you know. Right now, the documentation says:
In order to do that, one can set the default NAM to none and manually approve new subscribers by enabling their nam_cs and nam_ps parameters (e.g. over the VTY).
But as I was about to create an example of how these commands look like, I realized that VTY commands for changing nam_cs and nam_ps don't actually exist yet :\ So for now, these flags have to be changed manually in the sqlite database... change nam_cs and nam_ps to 1 in the subscriber table. Maybe this is still useful for testing. I will add the missing VTY commands shortly.
Cheers, Rafael Diniz
Cheers, Oliver
Hello Rafael,
sorry that it took me some time to answer, I was on holiday.
On 8/3/19 7:17 PM, Rafael Diniz wrote:
When a phone try to connect (not present in the hlr db yet):
0000> hlr.c:204 IMSI='724056816211859': Creating subscriber on demand <0000> hlr.c:220 IMSI='724056816211859': Successfully assigned MSISDN='76342' <0003> hlr.c:510 IMSI='724056816211859': storing IMEI = 35345609112072
<0000> luop.c:161 LU OP state change: NULL -> LU RECEIVED <0000> luop.c:175 724056816211859: LU OP Tx Error (cause PLMN not allowed)
This is expected if you have set the default access mode to "none" (something like "subscriber-create-on-demand 5 none" in osmo-hlr.cfg). The new subscriber was created, but a location update request fails because it is not allowed to access the (circuit or packet switched) network:
https://git.osmocom.org/osmo-hlr/tree/src/hlr.c?id=28f0774e341c3dbe1045ca61a...
And after giving "cs+ps" permission, when trying to set to "none" again, I get:
<0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:370 127.0.0.1:60216 sending data <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60210 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60216 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60210 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859
This looks like a bug. I've pasted your report here (please extend if you have more details): https://osmocom.org/issues/4163
Anyway, in it is working as expected! I'll investigate the logs further.
There is a word missing, but it seems that for the most part it is working as expected? ;)
Thanks for the feedback!
Cheers, Oliver
Cheers, Rafael Diniz
On 7/16/19 4:27 AM, Oliver Smith wrote:
Hello Rafael,
you're welcome. I've just merged the new VTY command and manuals update to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual
So if you rebuild your osmo-hlr packages from master, you should have the command (if I understood correctly that you are building the packages yourself, otherwise it will be in the nightly packages tomorrow).
After a subscriber has been created on demand, with network access mode set to "none", you can give the subscriber access to circuit and packet switched services as follows:
OsmoHLR> enable OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848 CS disabled PS disabled OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848
Cheers, Oliver
On 7/15/19 3:26 PM, Rafael Diniz wrote:
Thanks a lot, Oliver!
The VTY commands for changing nam_cs and nam_ps will be useful. ; )
Any problems I let you know!
Cheers, Rafael Diniz
On 7/15/19 5:08 AM, Oliver Smith wrote:
"check-imei-rqd early", not "check-imei early"
On 7/15/19 10:05 AM, Oliver Smith wrote:
Hey Rafael,
On 7/13/19 5:55 PM, Rafael Diniz wrote:
Hi Harald,
> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote: >> Today I'm working on updating my NuRAN unit with the new osmo stack > > Can you clarify which particular model/unit that is? > > I would assume that the 'nightly' OE packages sysmocom provides should have > all related features.
It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by hand the BTS and PCU against LC 1.5 headers.
>> I'm writing just in case someone already put online a set of config >> files with the parameters needed by such behavior set? >> ; ) > > I would be careful with full configuration files, as they contain all kinds > of settings which may or may not do what you want. The settings for > subcsriber-create-on-demand are only 2-3, AFAIR. > >> ps: I have the new splip stack working fine here, I just need to modify >> my setup with new features to support subscriber_create_on_demand. > > Then please simply use the config files you have and not start with > something else just because you need to modify one or very few lines... > > See https://osmocom.org/issues/2542 where Oliver actually also points to > a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf > > If yo have more specific questions, feel free to raise them here :)
Fine, I'll just adapt my config - Thanks!!
As Harald pointed out, the documentation could use some more examples. I'll update the docs accordingly, but to make your life easier, here are the configuration options relevant for your use case (with sending the IMEI to the HLR).
osmo-msc.cfg: msc check-imei early
osmo-hlr.cfg: hlr subscriber-create-on-demand 5 none store-imei
This will create 5 digit MSISDNs for the subscribers, and disable CS NAM and PS NAM by default (circuit switched and packet switched network access modes). Subscribers can't make phone calls or use cellular data, so their phones will not connect to the network, but the entry in the HLR will be created.
After a new subscriber was created, it will look like this in the VTY (I've replaced the real IMEI and IMSI with zeros):
OsmoHLR> enable OsmoHLR# subscriber imei 00000000000000 show ID: 1 IMSI: 000000000000000 MSISDN: 58192 <- randomly generated IMEI: 000000000000000 CS disabled PS disabled
The idea is now to enable CS and PS for the IMEIs that you know. Right now, the documentation says:
In order to do that, one can set the default NAM to none and manually approve new subscribers by enabling their nam_cs and nam_ps parameters (e.g. over the VTY).
But as I was about to create an example of how these commands look like, I realized that VTY commands for changing nam_cs and nam_ps don't actually exist yet :\ So for now, these flags have to be changed manually in the sqlite database... change nam_cs and nam_ps to 1 in the subscriber table. Maybe this is still useful for testing. I will add the missing VTY commands shortly.
Cheers, Rafael Diniz
Cheers, Oliver
Hi Oliver,
sorry that it took me some time to answer, I was on holiday.
soon it will be my holiday too!
This looks like a bug. I've pasted your report here (please extend if you have more details): https://osmocom.org/issues/4163
I will extend the report and take a look in the code to see what is going on.
Anyway, in it is working as expected! I'll investigate the logs further.
There is a word missing, but it seems that for the most part it is working as expected? ;)
Sorry for the typo - It is working as expected, yes! ; )
Rafael
-
Harald Welte -
Oliver Smith -
Rafael Diniz