baseband-devel August 2010

baseband-devel@lists.osmocom.org

18 participants
21 discussions

using BTSAP from layer23
by Andreas.Eversberg 23 Aug '10

23 Aug '10

hi, i am current writing the sim client for layer23. this client transforms the read and update requests from layer 3 (imsi read, location update) into several APDUs to be transferred via BTSAP interface. (interface to layer 1) here are two questions: how do i interface to this BTSAP? i see that there is another unix socket for that. do i need to expand main.c of layer23? i think that i cannot just start sending APDUs after starting layer23. there might be something like an initialization sequence before: - power on - reset - get atr - ... - send APDU - receive APDU - ... is there a defined sequence or flow chart for that? regards, andreas

2 1

AW: sim client
by Andreas.Eversberg 19 Aug '10

19 Aug '10

hi sebastien, thanx for you advice. i will have job names like SIM_JOB_READ, SIM_JOB_UPDATE, SIM_JOB_GSMALGO,... i am a bit unsure about the path array. i always thought that each EF has a unique ID. the DF where it is located, can be determined by the first byte of the EF ID. but if it is possible to have a sim with multiple DFgsm, then a path is required of course. for PIN handling, i will use result codes that gives cause of an error. if a PIN is required (to read the IMSI for example), the error code would show that. then the sim reading process prompts for PIN. the SIM can be unlocked ("enabled") by a message like SIM_JOB_ENABLE_CHV1. outgoing data (UPDATE) is located behind the header. incomming data is also located behind the header when the job returns (callback fn is called). but the READ job must be triggered. when my code must deal with record types, i will expand the header. i will create the API step by step. regards andreas

3 3

sim client
by Andreas.Eversberg 17 Aug '10

17 Aug '10

hi, i like to write the sim client protocol. i do not mean the code of the "sim reader" which is part of layer1 inside the phone. before i start, i would like to know what you think about my api idea. the api is not the low-level api between layer1 and the mobile application (APDU layer). it describes a higher layer for application or protocol processes which need to request IMSI, do key generation, or store location area information. one important thing is that different processes must be able request "read", "write", or other operations like key generation simultaniously. in order to handle multiple requests after each other, a queue inside sim client must exist. afterwar processing each request, the result must be sent only to the requesting process (if it still exists). a state machine watches over the current DF (current selected file area of the sim) and changes current "DF" if required, before processing read or write job. also it triggers the next job in the queue, if finished with the current one. int handle = sim_open(void (*cb)(...)) will add a new user instance. cb is the function to be called for response, handle is a unique id of the process (not a memory pointer, unique at all times after starting phone). void sim_job(struct msgb *msg) struct sim_job_hdr { int handle; uint8_t job_type; uint16_t file; }; will add a new job. the type defines the job type. examples are "READ" "WRITE" or "GSMKEY" requests. the handle is used to assign the read/write job to an instance. the file is used to select the correct data file of the sim. the data and len represent the data to be written. void cb(struct msgb *msg) is called back by the sim client when job is done. the handle is given, so multiple user instances may use the same callback. void sim_close(int handle) will remove user instance. outstanding jobs will finish, but no result is given, because cb is now unregistered. the coding and decoding of SIM files must be done by the application or protocol layer that use the sim client. andreas

2 1

layer1: crash after receiving TX data
by Andreas.Eversberg 16 Aug '10

16 Aug '10

hi, me and maybe some of you experiences sudden freeze of the layer1 firmware. it happens sometimes when sending L1CTL_DATA_REQ from layer2 to layer1. i found a way to reproduce it. see http://home.eversberg.eu/data.patch for testing it. just apply this patch and uncomment the "´#define" line. this patch will transmit idle frames, if there is no frame in the tx-queue of lapdm. (DCCH) even if there is a frame to be sent, the lapdm process will wait until the data is confirmed by layer1 until sendig the next frame. this confirm is sent when the data has been transmitted by layer1 (i think). this is why the queue inside layer1 cannot overflow. this patch does not work correctly somehow. when sending the idle frame, the location update seems not to work. the lapdm fails. but this doesn't matter for the crash-test. until then, more than 20 frames are transmitted. if the mobile application is restarted, more frames will be transmitted. between 45 and 60 frames later the layer1 freezes. the display gets a little darker also. andreas

1 0

Status of Traffic channel
by Dieter Spaar 13 Aug '10

13 Aug '10

Hello, here is some information about the current status of traffic channel support in Layer-1: - first of all its not yet complete and considered "alpha" because there are some stability problems which have to be solved and some further enhancments for a more general approach are needed. - What works: Signalling (FACCH/SACCH) for a Full Rate Traffic channel and voice (Full Rate or Enhanced Full Rate Codec). - TODO: The Layer-1 API has to be extended to allow switching the channel mode (e.g. Signalling only) or the Voice Codec. Also turning the audio path on and off is needed. - TODO: The Rx/Tx TPU Window has been modified to support Rx and Tx operation in the same frame. This always happens for a Traffic Channel but can sometimes also happen for other channels. For those cases its necessary that the Tx TPU Window is set differently. Some sort of state information that Rx is happening in the same frame has to be implemented, this currently only works for traffic channels. If you want to try it out you have to use the "dieter/tch_f" branch for Layer-1 and the Master branch for Layer-23 from Andreas (really great work, Andreas). With this combination you can use it with OpenBSC. Some minor adjustment is needed: The Layer-1 code currently sets the voice Codec to "Full Rate", however OpenBSC expects "Enhanced Full Rate" You either have to modify OpenBSC to set "Full Rate" or change "TCH_FS_MODE" to "TCH_EFR_MODE" in "layer1/prim_rx_nb.c", there is only one line which has to be changed. What you can do now is a MOC/MTC between OsmocomBB and another phone. Sometimes it can happen that the firmware hangs, you have to restart the phone in this case. However if you have a connected call, its working pretty good (one of the test calls was over 20 minutes). Maybe Andreas can give a short introduction how to use Layer-23 for this, I am not sure if there is some information in the Wiki yet. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Who would attend a developer room / meeting at FrOSCon ?
by Harald Welte 04 Aug '10

04 Aug '10

Hi! I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/) which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin from August 21/22 this year. Before sending a response, I would like to inquire whom of you would actually have any intention of visiting this conference and spending time in the developer room to work on OpenBSC or OsmocomBB ? I think the idea is great to meet some of you guys [again], not only at the annual CCC congress in winter. But there is little point for me to go there if there is no interest from the wider project community. Please provide your feedback ASAP. -- - 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)

3 4

Re: Wanted: Osmocom logo
by Steve Markgraf 03 Aug '10

03 Aug '10

Hi, On 02.08.2010 14:36, Sylvain Munaut wrote: > A nice typo with just 'osmocom' and a free space to put the suffix > ('bb' 'sgsn' ...) either in another typo or just using the bold face > and then just some _discrete_ graphical element added to the typo ... > > But IMHO certainly not some complex graphical only element. Ack, that's what I'd suggest as well, something clean and simple. So here's my RFC: I've taken the wireless symbol Kevin posted, and added a lettering. The font used is "Yanone Kaffeesatz" [1], which is licensed under the Open Font License. I attached osmocom_inkscape.svg, for which you need to have the font installed, and can then play around and edit the text, and a "object-to-path" converted osmocom_paths.svg, which is just a plain vector graphic. If anyone has an idea how to decently make the difference between osmocomBB and BSC more clear, or even has a completely different idea, let us hear/see them :) Regards, Steve [1] http://www.yanone.de/typedesign/kaffeesatz/

13 19

Re: OsmocomBB, Problem , prospects discussed
by Dev Purohit 02 Aug '10

02 Aug '10

Hello Peter, >Please reconsider this position. "once finished" is way too late to be useful, unless you plan on creating a product that you will sell. If you want cooperation and feedback from the community then I rather strongly suggest sharing source code immediately when you start the >work. Thanks you for your concerns, But as i have clearly mentioned that i have implemented Frequency Hoping, on DATA communication device ( telemetry on ISM Band) and Hardware Platform ,communication schemes , protocols and modulation technique were very different, so source can't be integrated with OsmocomBB at this stage , even patching also not that easy i estimated, and most difficult thing is i have very limited knowledge of G.S.M , my mostly time is consuming to study specifications .. Ohh, very lengthy subject.. anyways , I'm trying to deploy for cyclic FH first , choosing right algorithm. i have no problem or commercial value for sharing my work with great people , but it at least relevant and use full to this project. I'm neither developing any equipment not planning to sell it.. MatLab is simulation platform and codes cant be implemented in real-time or live environment, also it support TI DSP's long range. so we can debug change to C header after wards. Kind regards, Dev --- On Sun, 8/1/10, baseband-devel-request(a)lists.osmocom.org <baseband-devel-request(a)lists.osmocom.org> wrote: From: baseband-devel-request(a)lists.osmocom.org <baseband-devel-request(a)lists.osmocom.org> Subject: baseband-devel Digest, Vol 7, Issue 1 To: baseband-devel(a)lists.osmocom.org Date: Sunday, August 1, 2010, 10:00 AM Send baseband-devel mailing list submissions to baseband-devel(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/baseband-devel or, via email, send a message with subject or body 'help' to baseband-devel-request(a)lists.osmocom.org You can reach the person managing the list at baseband-devel-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of baseband-devel digest..." Today's Topics: 1. OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Dev Purohit) 2. Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Dieter Spaar) 3. Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Peter Stuge) _______________________________________________ baseband-devel mailing list baseband-devel(a)lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/baseband-devel

1 0

sorry, my e-mail got hacked...
by Lubomir Schmidt 02 Aug '10

02 Aug '10

sorry for the spam mails. My e-mail got hacked...

1 0

[ANNOUNCE] planet.osmocom.org
by Harald Welte 01 Aug '10

01 Aug '10

Hi! We now have a planet (RSS feed aggregator) for the Osmcoom project, it's running at http://planet.osmocom.org/ Please let me know if you think I should add any feeds to it. There is no strict requirement for contributions to the Osmocom project, but it should be technical and related to protocols / hacking / development of mobile telephony systems. Regards, Harald -- - 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)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel August 2010