We've recently noticed that our HNB-GW doesn't ever send an id-Reset to
the CN. Now I'm trying to pinpoint precisely when this should happen.
For discussion, I'm focusing on CS, though this applies to PS as well.
To facilitate paging, the CSCN needs to remember which RNC-Ids it has seen
on a given IuCS link. The id-Reset message contains the Global RNC Id and
allows the CSCN to know who's connected.
So far my thoughts are that the HNB-GW should forward all and any id-Reset
messages received from an hNodeB to the connected CSCN. It should look
like the RNCs were directly connected to the CN. "Any" number of hNodeBs
(each with an own RNC) may be connected to a single HNB-GW, and the CSCN
wants to know all of the RNC Ids (and RNC resets) using that SUA link.
On the other hand, the Location Update Requests arrive at the CSCN in an
initialUE Message, and its RANAP part always contains the Global RNC Id
(mandatory). So, technically, the CSCN doesn't need id-Reset messages to
find out the RNC Ids. It may simply remember all RNC Ids seen coming in on
a given SUA link, be they initial-UE or Reset messages.
I wonder though if it should be an error condition to receive a LU Request
with an RNC Id that wasn't seen in an id-Reset message yet.
My current focus is on paging. So even though the HNB-GW should forward
id-Resets, the CSCN can find out RNC Ids from LU requests alone, so I
guess I'm postponing the fix of HNB-GW.
Any thoughts are welcome.
~Neels
More on the pairing of RNC-Id and LAC:
We've discussed that the CN should be manually configured for which RNC-Id
belongs to which LAC, in order to find the correct SUA link to page on
upon having the to-be-paged subscriber's LAC.
Turns out: even though only the RNC-Id is sent in the id-Reset message,
both the RNC-Id *and* the LAC are transmitted in an InitialUE message.
So we can actually record the LACs as well as the RNC<->LAC mappings from
the InitialUE messages (like Location Update Request) and don't need to
configure them manually.
Does that sound reasonable?
We can still keep the manual vty config of RNC<->LAC mappings to detect
errors in the field configuration from InitialUE messages.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
I'm taking a brief look at how osmo-hnbgw would send a Reset to the CN.
So I'd like to be notified when osmo-hnbgw first establishes a link to a
CN component, and then send a Reset message on it.
I see there's an OSMO_SCU_PRIM_N_CONNECT, but am I right that this is
related to actual messages being sent on the link, and can't be used to
get notified about a connection per se?
Link establishment traces out as:
hnbgw_cnlink_init()
osmo_sua_client_connect()
osmo_stream_cli_open2() <-- includes a timer that retries connecting
In the osmo_stream_cli_* API, there's a connect_cb, but it isn't used from
osmo_sua_client_*.
So I would
* add a connect cb to struct osmo_sua_user (and osmo_sua_user_create())
* call it from a static cb fed to osmo_stream_cli_set_connect_cb()
in osmo_sua_client_connect()
Yes?
Thanks,
~Neels
Hi,
we are now running our own copy of patchwork at https://patchwork.osmocom.org. In addition to single patches this version can track series and has a REST API and git-pw client support. The system is currently subscribed to the GPRS, OpenBSC and OsmocomBB mailinglist.
The installation is running offlineimap every couple of minutes to fetch new mail, this means it can take some minutes for your comment or patch to be visible.
kind regards
holger
Dear all
I'm an independent mobile security researcher and coder from Italy
(therefore, forgive me if my English will cause you a
headache), I've been reading GSM specs for quite a few months now and
studying openbts, yatebts and osmo* source code for a few days due to a
GSM related project I'd really like to realize.
I have few questions to ask, but first let me explain my main objective.
I'm working on something like ScaPy ( an ip packet injection and
manipulation framework ) but for GSM, on a higher level what I want to
create is a C library which would allow developers to do something like
(forgive the pseudo-crappy programming and the oversimplification, I
just want to highlight what I'm looking for):
Passive / Sniffing concept:
open(sdr-device)
while(running) {
data = read_and_demodulate
burst = osmo_something_decode(data)
dump(data)
}
close(sdr-device)
Injection concept:
imsi = "1234456..."
open(sdr-device)
data = osmo_encode_packet( IMSI_DETACH, imsi )
osmo_write( sdr-device, data )
close(sdr-device)
( I know I'm not considering synchronization, not really interested in
that, the user would implement his own logic )
My point is that GSM is not "that hard" with the right tools, but
currently there're no such tools and I think it's such a shame because
it should be open to the users exactly as TCP/IP is.
Now to the questions:
A. Is the low-level communication ( from raw to basic demodulated bursts
) with SDR devices still handled by omso-bts-trx? If not, what's
handling the physical layer?
B. Could you point me to the right direction I'd need to take in order
to extend the code to support Nuand's BladeRF devices ( the only one I
have and the only one I can afford right now )?
C. Do you have simple (even incomplete) code examples for both the
"concepts" I've exposed ? I find your documentation to be really great,
but for higher level understanding people need usage examples.
Any piece of code, reference link, guidance, answer or whatever info
will be great.
Thanks,
Simone 'evilsocket' Margaritelli
Hi list,
osmo_prim_init() and msgb use firstly confuses me, and secondly is
apparently "inefficient" in sccp_helpers.c.
First, let's look at osmo_sccp_tx_unitdata() (libosmo-sccp branch
sysmocom/iu):
int osmo_sccp_tx_unitdata(struct osmo_sua_link *link,
const struct osmo_sccp_addr *calling_addr,
const struct osmo_sccp_addr *called_addr,
uint8_t *data, unsigned int len)
{
struct msgb *msg = msgb_alloc(1024, "sccp_tx_unitdata");
struct osmo_scu_prim *prim;
struct osmo_scu_unitdata_param *param;
prim = (struct osmo_scu_prim *) msgb_put(msg, sizeof(*prim));
param = &prim->u.unitdata;
memcpy(¶m->calling_addr, calling_addr, sizeof(*calling_addr));
memcpy(¶m->called_addr, called_addr, sizeof(*called_addr));
osmo_prim_init(&prim->oph, SCCP_SAP_USER, OSMO_SCU_PRIM_N_UNITDATA, PRIM_OP_REQUEST, msg);
msg->l2h = msgb_put(msg, len);
memcpy(msg->l2h, data, len);
return osmo_sua_user_link_down(link, &prim->oph);
}
First off, we allocate 1024 bytes of msgb. Into it goes an osmo_scu_prim
struct (here 'prim'). We set some parameters in prim, fair enough. But
now what, prim->oph, the prim header, has a msg pointer, which points back
at the msgb that contains the prim. really?? The msgb containing a struct
pointing back at the same msgb has my head spinning.
Finally we add the data, l2h pointing at the start of it. I'm confused ...
how large is the msgb supposed to be? Is it len + sizeof(*prim)?
Secondly, let's look at:
int osmo_sccp_tx_unitdata_msg(struct osmo_sua_link *link,
const struct osmo_sccp_addr *calling_addr,
const struct osmo_sccp_addr *called_addr,
struct msgb *msg)
{
int rc;
rc = osmo_sccp_tx_unitdata(link, calling_addr, called_addr,
msg->data, msgb_length(msg));
msgb_free(msg);
return rc;
}
So, something out there has a msgb containing data. For example, from
ranap_new_msg_paging_cmd(). That msgb has probably been allocated
specifically to compose a message to go over the sccp link.
We go on, though, to allocate *another* msgb (size 1024, remember), and
memcpy the first msgb into the second msgb, behind the osmo_scu_prim
struct.
I'll first use this as-is, talking about premature optimization. But I'd
prefer to have neither the wicked cunning nor the blunt dumbness in there;
the combination strikes me as jolly mad ;)
Are there good reasons for this?
I would have envisioned something like: tell ranap_new_msg_paging_cmd() to
allocate sizeof(*prim) of headroom; or first create a msgb of fixed
known-max size, and add first the prim header and then compose the data.
And, given the union prim->u has "unknown" size, why not point at the data
from prim->oph directly, instead of pointing back at the msgb? Or have
that union first? That would be easier to understand.
If some code needs to know the msgb that contains the prim->oph, I find it
weird to pass it the prim->oph with a backpointer, instead of just passing
the msgb right away.
~Neels
