2017년 11월 23일 목요일 오후 10시 34분 47초 CET에 Harald Welte 님이 쓴 글:
> On Thu, Nov 23, 2017 at 09:47:25PM +0100, Martin Heusse wrote:
> > Harald, Shinjo,
> > please find below is a tiny patch to add
> > #define GSMTAP_TYPE_LTE_NAS 0x12
> > to packet-gsmtap.h
> > and the corresponding code that uses it.
>
> great, feel free to push this to the wireshark gerrit.
>
> I've made a corresponding change in libosmocore, see
> https://gerrit.osmocom.org/5018
>
Forwarding the discussion at Wireshark gerrit at https://code.wireshark.org/
review/#/c/24554/4:
Devices dumping NAS messages can give both encrypted and plain messages. At
least for Qualcomm LTE basebands it is true. Therefore using sub_type for
differentiating encrypted and plain NAS messages were discussed there. This
will likely introduce another modifications to gsmtap.h, and therefore want to
discuss more about this topic also here.
Shinjo
--
Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272
Hello,
I heard that it's possible to connect to a femtocell without knowing Ki and Opc... of the sim-card like the conferences of Nico Golde and Ranvinshar on the poisoning the femtocell.My question is , is it possible to make the same with the osmo-iuh on the future !?
Chears,
Hi Jolly,
my current task is to implement load based handover between BTS, and in old
tradition of adopting your code to implement dynamic timeslots on
osmo-{bts,bsc}, I am now looking at the openbsc.git jolly/new_handover branch.
I notice that, on that branch, there are improvements on the "old" handover,
followed by a new elaborate handover_2 algorithm, which looks very sane at
first sight, paired with an elaborate test suite.
So my question is whether handover_2.c has some obvious shortcomings or open
issues that need to be resolved before I can consider merging that to OsmoBSC's
master branch.
Should we still keep the "old" handover decision code around as well for
particular reasons, or would it make sense to adopt handover_2.c by default?
Is one better than the other in particular situations?
And ... do you remember any high level conclusions from when you implemented
the branch, things I should be aware of when testing and adopting the code? Did
it work out as expected? How well tested is it?
Thanks!
~N
Looking at https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
OsmoMSC currently uses 0.23.1 for A-and-Iu,
and 0.23.2 for Iu only if Iu is on a different cs7 instance than A (i.e.
practically never).
Either way that doesn't really make sense to me. If OsmoMSC is connecting to
the same STP for A and Iu, it is sufficient to have one point-code for the two
SSNs for A (BSSAP) and Iu (RANAP) and hence use one cs7 instance for both.
If it is connecting to two different STPs, the point codes do not collide
anyway, and it makes no sense to use a different one for Iu. It only confuses
the defaults, e.g. the wiki page was wrong until I fixed it just now.
I would rather have just 0.23.1 for the MSC for all SSNs.
See ss7_setup() in msc_main.c.
Agreed?
~N
Hello!
I got this problem:
*root@pc:~/osmocom# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg((*)) | / \
OsmoBTS<0017> control_if.c:828 CTRL at 127.0.0.1 4238<0010>
telnet_interface.c:104 telnet at 127.0.0.1 4241<0012> input/ipaccess.c:886
enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002
<http://127.0.0.1:3002><000b> trx_if.c:595 Open transceiver for
phy0.0<0012> input/ipa.c:129 connection done.<0012> input/ipaccess.c:707
received ID get<0001> oml.c:229 O&M Get Attributes [0], Manufacturer
Dependent State is unsupported by TRX.<0001> oml.c:680 Ignoring T200[0]
(150 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680
Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug!<0001>
oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm
bug!<0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to
suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by
BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[5] (165 ms)
as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[6]
(1680 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:1049 ADM
state already was Unlocked<0012> input/ipa.c:129 connection done.<0012>
input/ipaccess.c:707 received ID get*
*<000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command with
response: 'RSP SETTSC -1'*
*<0001> bts.c:210 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL*
*<0007> l1sap.c:462 Invalid condition detected: Frame difference is
2452951-0 > 1!*
*Shutdown timer expired*
What is the problem and how can fix it?
I used 1 phone and cfg files (from this tutorial
https://osmocom.org/projects/baseband/wiki/CalypsoBTS):
- OsmoNITB: 'doc/examples/osmo-nitb/sysmobts/openbsc.cfg'
- OsmoBTS: 'doc/examples/trx/osmo-bts.cfg'
thanks!
Hi list,
While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add
NAS/EPS as a new payload type for gsmtap.h.
Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and
RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS
security had been activated only encrypted NAS messages are available at RRC
layer. This is reflected into the baseband diagnostics of various makers:
Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and
plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this
issue. I can submit a patch if this looks positive.
Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN
is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making
14-bits available for raw value. This causes some problem in LTE:
1) EARFCNs for uplink are starting from 18000, which is larger than 2^14
2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies)
3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network
Also in UMTS, there are overlapping UARFCNs between bands, which necessitates
a separate field for band indicator. Changes regarding these will break the
GSMTAP header structure, therefore I want to discuss about how these could be
addressed.
Best Regards,
Shinjo
--
Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272
Hi,
working on a diagnostic interface, I also ran into the lack of a gsmtap type for LTE NAS plain messages.
So I am supporting Shinzo's request for a new GSMTAP_TYPE_LTE_NAS (or GSMTAP_TYPE_LTE_UU) type in packet-gsmtap.h.
This type would play a similar role to that of GSMTAP_TYPE_UM for GSM, if my understanding is correct.
Best regards,
Martin
> Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and
> RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS
> security had been activated only encrypted NAS messages are available at RRC
> layer. This is reflected into the baseband diagnostics of various makers:
> Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and
> plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this
> issue. I can submit a patch if this looks positive.
>
>
Hi,
> I read a tutorial called "CalypsoBTS"
The tutorial has been updated. Check out a new version please.
https://osmocom.org/projects/baseband/wiki/CalypsoBTS
> *There is no such command. Error occurred during reading
> the below line: fn-advance 30*". How to fix it? Are there
> any tutorials for beginners how configure these
> "Osmo-bts.cfg" "Open-bsc.cfg" files?
The configuration suggested by the previous version of this
tutorial is obsolete. I may find the actual configuration
examples in 'doc/examples/' of almost each project.
With best regards,
Vadim Yanitskiy.
Hello! I read a tutorial called "CalypsoBTS" (
http://osmocom.org/projects/baseband/wiki/CalypsoBTS). Everything was good
before I ran "Osmo-bts.cfg".
I got a error : "
*There is no such command. Error occurred during reading the below line:
fn-advance 30*". How to fix it? Are there any tutorials for beginners how
configure these "Osmo-bts.cfg" "Open-bsc.cfg" files? I need just to run
"fake base station" for testing android app. Is there any another ways to
run it with motorola?
Thanks!
Hi,
We have a Litecell 1.5 unit. It is updated to the latest packages on the nightly build and configured to an osmo-bsc set up on an another machine.
On mobile phones, the network does not show the short or long name set, instead it shows just numbers "09070" and calls can not be made.
This has happened to us before when there was problem with the clock calibration on the BTS.
A GPS device is attached to the BTS, and when running cgps, there is a 3D Fix and a correct GPS location coordinates show up.
The lc15 bts should be able to calibrate automatically using the lc15bts-mgr package, however, it seems like it is failing to do so.
When we tried stopping the lc15bts-mgr service and start it manually to log the output by running:
/usr/bin/lc15bts-mgr -s -c /etc/osmocom/lc15bts-mgr.cfg
We notice the following errors:
```
Failed to open /mnt/storage/var/run/lc15bts-mgr/volt-supply-max due to 'No such file or directory' error
<0000> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_misc.c:315 Total hours of Operation: 393
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system.
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002e,m:0x000000000000007f
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system.
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f
```
It seems the lc15bts_mgr service can not read the values from the GPS device for some reason, can someone please advise what might be causing this issue?
Best Regards,
Rayan
