Make the MS the script is associated with accessible to lua. Provide
access to IMSI and IMEI. The IMSI might not be available at the given
time and just return an empty string.
Example lua usage:
print(osmo.ms():imsi());
print(osmo.ms():imei());
print(osmo.ms():shutdown_state())
print(osmo.ms():started())
function ms_started_cb(started)
print("MS started", started)
end
function ms_shutdown_cb(old_state, new_state)
print("MS shutdown", old_state, "->", new_state)
end
function sms_cb(sms, cause, valid)
print("SMS data cb", sms, cause, valid)
for i, v in pairs(sms) do
print(i, v)
end
end
function mm_cb(new_state, new_substate, old_substate)
if new_state == 19 and new_substate == 1 then
osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23)
end
end
local cbs = {
Started=ms_started_cb,
Shutdown=ms_shutdown_cb,
Sms=sms_cb,
Mm=mm_cb
}
timer = osmo.timeout(20, function()
print("Timeout occurred after 20s")
end)
osmo.ms():register(cbs)
# Can fail. Best to wait for state changes...
print(osmo.ms().start())
print(osmo.ms().stop(true))
Change-Id: Ia3ace33d6ba4e904b1ff8e271a02d67777334a58
Right now the script will be executed once it is loaded. Make sure
to write it into the config file last. Expose various log commands
for logging. Jump through some hoops and get the filename and line
number from lua.
Change-Id: I456f6b6b5e1a14ed6c8cb0dcc5140093d3c61ef6
The enum was created to understand the different states during
the shutdown and find places where it is used. The normal
transitions are like.
Idle -> Imsi Detach -> L1 Reset -> Done
Idle -> L1 Reset -> Done
The shutdown can get stuck in case:
* Out of memory situation while handling IMSI detach (timeout)
* Never receiving l1 reset acknnowledgment.
The code could benefit from the move to osmo fsm to deal with
proper timeouts.
Change-Id: Iee1140e4848923c7270495c381bf87b7e3fddee1
The state handling is complicated and maybe it gets better by
moving started to bool and then the rest to an enum.
Change-Id: I6aef22e7bf954a8a4ecda980c2c558eb8c9180b7
The approach of talloc memory management reduces memory usage,
and prevents some buffer overflows, which were possible before.
Change-Id: Icd6706117fdd7f1b3481b0e3817bbb3b31f12f60
Since libosmocore already has LAPDm implementation, we don't need the
local copy of LAPDm code anymore.
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This patch introduces cell re-relection. When camping on a cell, it
scanns neighbour cells. If a 'better' cell is found, the cell is selected.
If the cell is in a different location area, a location upating is
performed under certain conditions.
The 'better' cell depends on various informations that are broadcasted on
the BCCH of a neihbour cell and of course the RX level. Most operators
don't set these informations, so the 'better' cell depend on a better
RX level for the same location area, or a much better RX level (6 dBm)
at a different location area.
There were many issues at the idle mode process that has been fixed.
Expecially when moving, the state machines got stuck, so no more cell search
was possible, or no further calls / location updating was possible.
In order to see the process of cell selection, enter the VTY interface and
enable the network monitor:
enable
monitor network 1 (where '1' is the instance of the MS)
In order to see the current state of the processes, enter:
show ms
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
All functions for handling mobile instances and mobile relevant parts are
moved to mobile/app_mobile.c, the mobile/main.c and mobile/mncc.c become a
simple out-of-the-box mobile application. (making calls)
The mobile/main.c can be replaced easily by a different application now.
this application may have it's own call control implementation (layer 4).
Full configurations via VTY is still possible and required in this case.
To create another instance: 'ms <name> create'
To remove an instance: 'no ms <name>'
If no instance exists, 'ms 1' is created automatically on startup.
Each instance can be enabled / disabled by using 'shutdown' or
'no shutdown'. Multiple instances may share the same layer2 socket (same
phone hardware), but in this case only one instance can be enabled at the
same time. This makes it much easier to select different settings without
modifying them.
A 'shutdown' initiates the IMSI detach procedure before shutdown is
completed. A 'shutdown force' will immidiately shutdown.
There is no need to restart the software anymore, if fundamental settings
are changed. In this case, a 'shutdown' followed by a 'no shutdown' will
do the job.
If you already have an old osmocom.cfg, you need to "no shutdown" it.
Everything else behaves as before.
There are two criterions for lossing a signal, idle mode and dedicated mode.
A counter counts down when a frame is dropped, and counts up when a valid
frame is received on certain channel. The loss criterion is reached, if the
counter reaches 0. The values added to / removed from the counter and the
limits depend on the process.
The cell provides SYSTEM INFORMATION 5* and 6. These are used to create a
list of neighbor cells to monitor. Because there is no neighbor cell
monitoring supported by layer1, the list has no valid results yet.
Currently the average RX level of received frames are used to generate a new
report every second. The report is transmitted to layer1 and used there
whenever a measurement report has to be transmitted.
The timing advance and the current transmit power (as requested by network),
is included with every report.
The SIM client is now complete. Because it usefull for multiple
applications, i moved it to the layer23/src/common directory.
The SIM reader works together with mobile process. Fixes were made.
Thanx to all for testing, finding bugs, and making it work as it is
supposed to do.
The current version uses special L1CTL messages to send and receive APDUs.
This will change in the future, when BTSAP interface is completed.
Please note that this client will not work until the layer1 SIM reader
fixes and extensions are committed.
The SIM client is not the SIM reader. It is used to process higher layer
requests. One request may be: "read the IMSI file" or "unlock SIM card, here
is the key". It then selects the right file of SIM card and processes the
request by exchanging APDUs with the SIM reader.
NOTE: Because the reader inside layer 1 is not yet finished, the SIM client
will not work and cannot be tested yet.
This commit features handling of ASSIGNMENT COMMAND. Currently only channel
descriptions "after time" are processed, which is mostly the case.
The ASSIGNMENT COMMAND is essential, because public networks assign an
SDCCH4/8 before actually assigning a TCH.
This split the headers and adapt the source.
We use osmocom/bb as a prefix because libosomore also
uses osmocom and generic names such as misc & common could
conflict in the future.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Holger Hans Peter Freyther
Sylvain Munaut
Harald Welte