From: Max <msuraev(a)sysmocom.de>
According to 3GPP TS 05.02 § 6.3.1.3 SI2ter messages should be scheduled
in FN with TC=4 only if SI2bis messages are also available.
---
src/common/sysinfo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/common/sysinfo.c b/src/common/sysinfo.c
index f079199..ee42da2 100644
--- a/src/common/sysinfo.c
+++ b/src/common/sysinfo.c
@@ -76,9 +76,10 @@ uint8_t *bts_sysinfo_get(struct gsm_bts *bts, struct gsm_time *g_time)
/* iterate over 2ter, 2quater, 9, 13 */
/* determine how many SI we need to send on TC=4,
* and which of them we send when */
- if (BTS_HAS_SI(bts, SYSINFO_TYPE_2ter)) {
+ if (BTS_HAS_SI(bts, SYSINFO_TYPE_2ter) &&
+ BTS_HAS_SI(bts, SYSINFO_TYPE_2bis)) {
tc4_sub[tc4_cnt] = SYSINFO_TYPE_2ter;
- tc4_cnt += 1; /* 2bis */
+ tc4_cnt += 1;
}
if (BTS_HAS_SI(bts, SYSINFO_TYPE_2quater) &&
(BTS_HAS_SI(bts, SYSINFO_TYPE_2bis) ||
--
2.7.3
Hi, i was wondering how is the status of osmo-ganc? Is there a working
implementation?
As far as i understand it, to test GAN + OpenBSC i would need a GAN capable
mobile phone, or a modified version of OsmocomBB.
Greetings, Florian
Hi Daniel and 3G folks,
about our difficulty in maintaining a prolonged link with the UE, I found
a bit of discrepancy concerning the TMSIs used.
When looking at a pcap where we authenticate and MM LU / GMM Attach
successfully on CS / PS, and with TMSI assignment enabled in CSCN, I see
TMSIs in these places:
1) UE sends TMSI in "(GMM) Attach Request" (PS)
2) SGSN sends TMSI in "(GMM) Attach Accept" (PS)
3) CSCN sends TMSI in "Location Update Accept" (CS)
All these TMSIs differ.
When I look in the RRC log of the hnb, it is logging a TMSI for pretty
much every received message on CS and PS domains. But it is always and
only logging the TMSI matching 1), i.e. the TMSI originally sent on the PS
domain. To rephrase, the same TMSI is logged for PS and CS domain
messages; for the MM LU Accept as well as the GMM Attach Accept, the hnb
logs TMSI 1) even though the CN sent TMSIs 3) and 2), respectively.
For 1) and 2), it seems that the SGSN should accept and use the TMSI sent
by the UE during the Attach Request, right?
For 3), according to the RRC log, it seems that the UE expects to see the
very same TMSI in CS that it sent to PS -- that'd be a problem. On the
other hand, when noting that, in the Location Updating Request, the UE
identified itself using the IMSI and not a TMSI, it may be indeed the
correct choice to disable TMSI use for CS?
I must admit that I'm not firm in the IMSI/TMSI realm, and staring at 3GPP
04.08 doesn't clarify it right away, so I'd appreciate some feedback from
this list. I can stare some more, but maybe you guys are quicker.
Thanks!
~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
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
The user might issue restarts while no BTS is connected and we
should not block the abis queue because of these messages.
---
openbsc/src/libbsc/abis_nm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/src/libbsc/abis_nm.c b/openbsc/src/libbsc/abis_nm.c
index c05e2f9..3afc4c4 100644
--- a/openbsc/src/libbsc/abis_nm.c
+++ b/openbsc/src/libbsc/abis_nm.c
@@ -2598,7 +2598,7 @@ int abis_nm_ipaccess_restart(struct gsm_bts_trx *trx)
fill_om_fom_hdr(oh, 0, NM_MT_IPACC_RESTART, NM_OC_BASEB_TRANSC,
trx->bts->nr, trx->nr, 0xff);
- return abis_nm_sendmsg(trx->bts, msg);
+ return abis_nm_sendmsg_direct(trx->bts, msg);
}
int abis_nm_ipaccess_set_attr(struct gsm_bts *bts, uint8_t obj_class,
--
2.6.3
Hi list,
today I saw an MM Authentication Response sent from a 3G UE that
mismatches the GSM 04.08 spec. The spec says 0x14, the 3G phone sent 0x94.
And wireshark agrees that 0x94 is an Authentication Response.
The spec ETSI TS 100 940 V7.21.0 (2003-12) chapter 10.4 defines the MM
Authentication Response message type as
8 7 6 5 4 3 2 1
0 x 0 1 - - - - Security messages:
0 1 0 0 AUTHENTICATION RESPONSE
So this would be 0x14 or 0x54, depending on the don't-care bit 7.
The Osmocom code acts according to spec by applying a bitmask of
0xbf (0b10111111) before comparing to 0x14, caring about bit 8.
However, the 3G phone sent an Authentication Response message type of
0x94 (0b10010100) with bit 8 set. Interestingly enough, wireshark
interprets this as a 0x14 with the highest two bits as sequence nr.
So it seems the reality in the field differs from the spec in that bit 8
should be masked away before comparing to the MM message type code.
In consequence, I need to adjust the MM message type bitmask to 0x3f in
upcoming patches.
The thing is, our code has the apparently wrong 0xbf bitmask hardcoded in
numerous places. So as a first step, I will introduce bitmask #defines in
libosmocore and apply these in openbsc.
I will introduce separate bitmask defines for MM and CC messages, because
I'm not sure yet whether CC message types should also be masked with 0x3f
in the field and will leave the CC mask as 0xbf for now.
While doing that, I also noticed that some places apply a 0xbf bitmask
even though the message types in question aren't defined as having any
don't-care bit in TS 100 940. I'll adjust those in a separate patch.
- So at first, I will replace 0xbf with GSM48_MT_MM_MSG_TYPE_MASK or
GSM48_MT_CC_MSG_TYPE_MASK.
- Then I'll adjust the MM mask to 0x3f to allow testing 3G auth.
- Finally I'll remove bit masks where they shouldn't be applicable,
which could use a second opinion by you guys. Are the upper bits always
some sequence number, and the spec simply doesn't reflect the field?
The patch submissions will follow right up...
~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