proposed same patch as already submitted for opensuse at
https://build.opensuse.org/request/show/286595
Michel Normand (1):
avoid smscb test failure for ppc/ppc64 archi
include/osmocom/gsm/protocol/gsm_03_41.h | 37 ++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
--
1.7.9.5
Hello list,
I'm playing with the mobile application of OsmocomBB. I have two SIM
cards of
two different operators. Everything works fine with one of them, but it
doesn't
with the other one.
Layer1 hangs there:
SIM Request (7): a0 a4 00 00 02 6f 30
SIM Response (2): 9f 0f
SIM Request (5): a0 c0 00 00 0f
SIM Response (17): 00 00 00 f6 6f 30 04 00 11 ff ff 01 02 00 00 90 00
SIM Request (5): a0 b0 00 00 f6
and mobile hangs there:
<0005> subscriber.c:600 Requesting SIM file 0x6f30
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:241 SELECT (file=0x6f30)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
<000f> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
<000f> sim.c:949 command successfull
<000f> sim.c:571 GET RESPONSE (len=15)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
<000f> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
<000f> sim.c:949 command successfull
<000f> sim.c:1065 selected file (len 246)
<000f> sim.c:277 READ BINARY (offset=0 len=246)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
So, as I understand it, it tries to read the PLMN selectors from SIM but
does
not get any answer and the callback function is not called.
Also, when using the command "off", everything shuts down with the first
SIM,
but I have to use ctrl-c for the second one after mobile hangs here:
<000f> sim.c:1234 exit SIM client
I have the last versions of libosmocore and osmocom-bb in the master
branch,
and I enabled TX support. I also tried to set my IMEI in the mobile.cfg
file
but this does not change anything. The config file is joined as well.
Did I forget something? Do you have an idea?
Thank you!
Dear Osmocom.org project members,
I'm happy to be able to announce the annual incarnation of OsmoDevCon.
The Date is set for March 27 through 30. Venue: As usual, IN-Berlin
e.V. in Berlin, Germany.
Further details can be obtained from
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2015
Attendance, as usual, is restricted to people with an active history in
the Project by contributions in terms of code, patches, discussions,
documentation or in other form.
= Registration =
If you have wiki access, please add yourself to the #Requested section.
Alternatively, you can send me private e-mail about it.
After review, your (nick)name will be listed in the #Confirmed section.
Looking forward to meeting all of you again soon!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello list,
I'm playing with the mobile application of OsmocomBB. I have two SIM
cards of
two different operators. Everything works fine with one of them, as you
can see
in the mobile_ok log, but it doesn't with the other one, as you can see
in the
mobile_ko and layer1_ko log.
Layer1 hangs there:
SIM Request (5): a0 b0 00 00 f6
and mobile hangs there:
<000f> sim.c:1065 selected file (len 246)
<000f> sim.c:277 READ BINARY (offset=0 len=246)
<000f> sim.c:187 sending APDU (class 0xa0, ins 0xb0)
Then nothing happens.
Also, when using the command "off", everything shuts down with the first
SIM,
but I have to use ctrl-c for the second one after mobile hangs here:
<000f> sim.c:1234 exit SIM client
I have the last versions of libosmocore and osmocom-bb in the master
branch,
and I enabled TX support. I also tried to set my IMEI in the mobile.cfg
file
but this does not change anything. The config file is joined as well.
Did I forget something? Do you have an idea?
Thank you!
Hi
I have compiled mobile app with tx support .
i.e i have checked-out the testing branch .
Layer 1 seems to be uploaded to the mobile phone successfully.
But the program crashes every-time there is a successful connection with
the network service provider.
I am attaching my mobile.log and layer1.log file along for debugging.
Hoping some one replies.
" mmsgb(0x8955b0): Not enough headroom msgb_push (4285966792 < 7)
errors
Dropping frame with 66 bit errors
Dropping frame with 65 bit errors
Dropping frame with 58 bit errors
Dropping frame with 56 bit errors
LOSS counter for CCCH 57
Dropping frame with 66 bit errors
Dropping frame with 66 bit errors
Dropping frame with 65 bit errors
Dropping frame with 65 bit errors
Dropping frame with 70 bit errors
Dropping frame with 65 bit errors
Dropping frame with 80 bit errors
LOSS counter for CCCH 53
Dropping frame with 61 bit errors
Dropping frame with 76 bit errors
Dropping frame with 57 bit errors
Dropping frame with 67 bit errors
Dropping frame with 58 bit errors
Dropping frame with 72 bit errors
Dropping frame with 63 bit errors
Dropping frame with 70 bit errors
LOSS counter for CCCH 49
Dropping frame with 57 bit errors
Dropping frame with 61 bit errors
Dropping frame with 52 bit errors
Dropping frame with 77 bit errors
Dropping frame with 60 bit errors
Dropping frame with 57 bit errors
Dropping frame with 76 bit errors
LOSS counter for CCCH 45
Dropping frame with 70 bit errors
Dropping frame with 57 bit errors
Dropping frame with 65 bit errors
Dropping frame with 46 bit errors
Dropping frame with 65 bit errors
Dropping frame with 46 bit errors
Dropping frame with 70 bit errors
Dropping frame with 77 bit errors
LOSS counter for CCCH 46
Dropping frame with 51 bit errors
Dropping frame with 56 bit errors
Dropping frame with 65 bit errors
Dropping frame with 59 bit errors
Dropping frame with 65 bit errors
Dropping frame with 60 bit errors
Dropping frame with 72 bit errors
Dropping frame with 79 bit errors
Dropping frame with 75 bit errors
Dropping frame with 59 bit errors
Dropping frame with 72 bit errors
Dropping frame with 66 bit errors
Dropping frame with 69 bit errors
Dropping frame with 70 bit errors
Dropping frame with 65 bit errors
Dropping frame with 69 bit errors
Dropping frame with 66 bit errors
Dropping frame with 82 bit errors
Dropping frame with 80 bit errors
LOSS counter for CCCH 86
Dropping frame with 67 bit errors
Dropping frame with 63 bit errors
Dropping frame with 69 bit errors
Dropping frame with 69 bit errors
Dropping frame with 66 bit errors
Dropping frame with 76 bit errors
Dropping frame with 63 bit errors
LOSS counter for CCCH 87
Dropping frame with 53 bit errors
Dropping frame with 54 bit errors
LOSS counter for CCCH 88
LOSS counter for CCCH 89
Dropping frame with 46 bit errors
Dropping frame with 50 bit errors
Dropping frame with 45 bit errors
backtrace() returned 10 addresses
/usr/local/lib/libosmocore.so.6(osmo_panic+0xbe) [0x7f3ccd0745ce]
/usr/local/lib/libosmogsm.so.5(lapdm_phsap_up+0x18e) [0x7f3cccc3cc5e]
./mobile() [0x438c29]
./mobile() [0x4394cc]
/usr/local/lib/libosmocore.so.6(osmo_wqueue_bfd_cb+0x73) [0x7f3ccd071b63]
/usr/local/lib/libosmocore.so.6(osmo_select_main+0x18f) [0x7f3ccd070b9f]
./mobile() [0x4048bf]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f3ccc679ec5]
./mobile() [0x404a46]
"
there is core dumped after this error.
Hello
This patch
1. can handle LTE RRC messages and call respective dissectors
2. can handle LTE MAC frames, fill in the struct mac_lte_info and then call
the mac-lte dissector. Following the GSMTAP header, there is a 15 byte
mac_info which is needed to fill the struct mac_lte_info.
The size mac_info need not necessarily be 15 byte. But these 15 bytes are
necessary for the lte-mac dissector to understand the frame. 15 byte header
is used by the LTE_FDD_EnodeB application from the openLTE project.
There is also a patch for gsmtap.h.
Please let me know your comments.
Cheers
Altaf
Hey folks.
In a light of latest collapse of mailing list I have a proposal for backup
communication channel. It have rather limited capacity and reachability but it's
extremely reliable in case of electronic malfunctions. It's called "real-life
meeting" ;-)
I suggest bi-weekly format, time and place is up to discussion but I'm ok with what
it used to be before. We can also have 2-way proposals - some folks can suggest
topics they would like to present while others could suggest topics they would like
to ask questions on. When enough of those match together - we have a meeting.
As a starter - I'd like to ask questions on 1) call forwarding support in OpenBSC 2)
BTS emulator.
Thought/comments/suggestions?
--
best regards,
Max, http://fairwaves.co
Dear OsmocomBB-list,
I just realized that I've been unsubscribed since November 2014 from the
baseband-devel list and now I resubscribed today. The Mail-archive seems
to start from scratch since these days, too. So I guess, that this is not
an individual problem of my email address.
What happened (HDD-crash)? Why is that not mentioned on the website? Maybe
I am not the last one realizing that?
Best
Tim
Hi,all: I have got a C118 to test mobile function 1) To get the master branch code and to compile it. 2) To insert simcard(13681******) into the phone and to modify the mobile.cfg to use real simcard. 3) To connect the phone with PC(core i5/ubuntu 12.04). 4) After downloading the firmware, to start the mobile App(#sudo ./mobile 2>&1 | tee > log.txt). 5) I can see that the location update process is ok and an TMSI is allocated to the phone. 6) To telnet into the osmocon, I can start a call to another phone (#Call 1 13564******). 7) I can send a sms to another phone. So far, all(MOC) is ok.
But If using the osmocommbb phone(13681******) as the target phone(MOT), (for example, Iuse a normal phone to call the osmocombb phone), it is very rare that the osmocombb phone have a respose to the paging. 1) I have check the paging messages in the log.txt file and find that there only one paging respone messages such as "TMSI MATCH" as I have call the osmocombb phone about 20 times. In the success case: ..............gsm322.c:1966 Cell ARFCN 13 selected.gsm322.c:2423 Tune to frequency 13.gsm322.c:468 Sync to ARFCN=13 rxlev=-68 (Sysinfo, ccch mode NON-COMB)gsm322.c:2450 Cell available.gsm322.c:4049 (ms 1) Event 'EVENT_CELL_FOUND' for Cell selection in state 'C5 choose cell'gsm322.c:3383 Camping normally on cell (ARFCN=13 mcc=460 mnc=00 China, China Mobile)gsm322.c:829 new state 'C5 choose cell' -> 'C3 camped normally'gsm48_mm.c:4325 (ms 1) Received 'MM_EVENT_CELL_SELECTED' event in state wait for network commandgsm48_mm.c:1130 We are in registered LAI as returning to MM IDLEgsm48_mm.c:919 new state wait for network command -> MM IDLE, normal servicegsm48_mm.c:426 starting T3212 (periodic loc. upd. delay) with 7200 secondsgsm322.c:2947 Channel synched. (ARFCN=13, snr=16, BSIC=29).............. gsm48_rr.c:2116 TMSI a0b186e9 matchesgsm48_rr.c:1307 Establish radio link due to paging requestgsm322.c:4049 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally'gsm322.c:829 new state 'C3 camped normally' -> 'connected mode 1'gsm322.c:3665 Going to camping (normal) ARFCN 13.gsm322.c:468 Sync to ARFCN=13 rxlev=-68 (Sysinfo, ccch mode NON-COMB)gsm48_rr.c:355 new state idle -> connection pendinggsm48_rr.c:1422 CHANNEL REQUEST: 20 (PAGING TCH/F)gsm322.c:2947 Channel synched. (ARFCN=13, snr=16, BSIC=29) .......... From the log info I can see that: a) the phone is camped in ARFCN 13 and receive paging in this cell. b) the signal of cell is strong enough 2) I have no an OpenBTS device to send some paging messages to check where is the problem further. Maybe I miss something. Any suggestion is appreciated! Thank you very much!
Best Regards
Shang
Hello,
I am playing with osmocomBB on Arch Linux, branched off from
jolly/handover. I am running the osmocomBB firmware by chainloading the
layer1 onto Motorola C115(and layer23 on host PC, obviously). Everything
works fine (location update, normal cell selection and re-selection) while
in Idle mode. As soon as the phone enters the dedicated mode (ex: the
moment I make a call or receive an indication about an incoming call), I
notice that the layer1 starts complaining about erroneous detection of
Synchronization Burst (SB) from the neighboring-cells, making the mobile
stick to a single ARFCN throughout the call. As soon as the mobile leaves
dedicated mode, the layer1 stops complaining about SB detect error and
resumes with cell-selection and re-selection normally.
I dug up the layer1/prim_fbsb.c code off the same branch and came to two
conclusions (though I am unable to find out what the actual cause to this
problem is):
- Either the TPU is programmed to detect information from different
timeslot using l1s_rx_win_ctrl(). I make this assumption because, while
the layer1 complains about SB detect error, layer23 complains about bad
frame with >= 70 bit errors in the frame.
- Or, l1s_neigh_sb_resp() is receiving the correct frame and ending up
in a bad CRC check with the received SCH burst header (all 11 times !).
I have tested the osmocomBB firmware with both openBTS network setup and
public, licensed networks and have come to these conclusions, as the errors
were occurring in both the cases. You can find the error logs in here
<https://gist.github.com/NinjaComics/1bce7b581de4f1976753> and here
<https://gist.github.com/NinjaComics/a07699fd283c525de3fa> (these logs are
based of public networks). Thanks in advance, any help is appreciated.
--
Ravi Sharan B A G.