From shangtao_1990 at hotmail.com Sun Jan 4 06:12:03 2015 From: shangtao_1990 at hotmail.com (tao shang) Date: Sun, 4 Jan 2015 06:12:03 +0000 Subject: MOT call/sms problem Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmocom at ehlers.info Wed Jan 7 21:48:38 2015 From: osmocom at ehlers.info (Tim Ehlers) Date: Wed, 7 Jan 2015 22:48:38 +0100 (CET) Subject: everyone got unsubcribed in November 2014? Message-ID: 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 From holger at freyther.de Thu Jan 8 13:19:19 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 8 Jan 2015 14:19:19 +0100 Subject: everyone got unsubcribed in November 2014? In-Reply-To: References: Message-ID: <20150108131919.GC4354@xiaoyu.lan> On Wed, Jan 07, 2015 at 10:48:38PM +0100, Tim Ehlers wrote: > What happened (HDD-crash)? Why is that not mentioned on the website? Maybe I > am not the last one realizing that? LUKS corruption or such on both the server and the backup. The mails were setup on a new place but we didn't have more copies of the subscriber database. From altaf329 at gmail.com Tue Jan 13 08:15:05 2015 From: altaf329 at gmail.com (altaf sk) Date: Tue, 13 Jan 2015 09:15:05 +0100 Subject: Fwd: [PATCH] GSMTAP: handling LTE RRC and MAC messages In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LTE_RRC_and_MAC_handle.patch Type: text/x-patch Size: 7423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LTE_RRC_MAC_libosmocore_gsmtap.patch Type: text/x-patch Size: 1351 bytes Desc: not available URL: From 246tnt at gmail.com Tue Jan 13 09:23:55 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 13 Jan 2015 10:23:55 +0100 Subject: [PATCH] GSMTAP: handling LTE RRC and MAC messages In-Reply-To: References: Message-ID: Hi, The libosmocore patch looks good and from what I see adding those make sense. If no one has raised an issue with it in the next day, I'll merge it. There is a couple of formatting issues for the gsmap one (space vs tab in one place, missing blank line), but it looks OK to me. I'm not really familiar with LTE though. But in anycase it will have to go through wireshark's submission process to be merged once the libosmocore changes have been applied. Cheers, Sylvain From Max.Suraev at fairwaves.co Wed Jan 14 09:03:08 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Wed, 14 Jan 2015 10:03:08 +0100 Subject: ML backup idea Message-ID: <54B630CC.6090908@fairwaves.co> 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 From altaf329 at gmail.com Mon Jan 12 22:31:45 2015 From: altaf329 at gmail.com (altaf sk) Date: Mon, 12 Jan 2015 23:31:45 +0100 Subject: [PATCH] GSMTAP: handling LTE RRC and MAC messages Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LTE_RRC_and_MAC_handle.patch Type: text/x-patch Size: 7423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LTE_RRC_MAC_libosmocore_gsmtap.patch Type: text/x-patch Size: 1351 bytes Desc: not available URL: From 246tnt at gmail.com Sun Jan 18 22:16:56 2015 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 18 Jan 2015 23:16:56 +0100 Subject: [PATCH] GSMTAP: handling LTE RRC and MAC messages In-Reply-To: References: Message-ID: The libosmocore patch was pushed. You should know submit the other patch to wireshark (and point them to the upstream libosmocore to approve the gsmtap changes). On Tue, Jan 13, 2015 at 10:23 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > The libosmocore patch looks good and from what I see adding those make sense. > If no one has raised an issue with it in the next day, I'll merge it. > > There is a couple of formatting issues for the gsmap one (space vs tab > in one place, missing blank line), but it looks OK to me. I'm not > really familiar with LTE though. But in anycase it will have to go > through wireshark's submission process to be merged once the > libosmocore changes have been applied. > > > Cheers, > > Sylvain From sanchit.k.agarwal at gmail.com Tue Jan 20 20:08:27 2015 From: sanchit.k.agarwal at gmail.com (Sanchit Agarwal) Date: Wed, 21 Jan 2015 01:38:27 +0530 Subject: Regarding Mobile Application of Osmocombb . Core Dumped. Ubuntu 14.04 Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mobile.log Type: text/x-log Size: 194520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: layer1.log Type: text/x-log Size: 1830962 bytes Desc: not available URL: