baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

message handling
by Andreas.Eversberg 01 Apr '10

01 Apr '10

hi, today i will finally (begin to) structure the message handling in my current work on layer 3: the message handling functions consist of: - message cration - message sending - message en-queueing - message de-queueing i deal with interfaces (SAP): - between application and call control (MNCC-SAP) - between call controll and mobility management (MMCC-SAP) - between supplementary services protocol and mobility management (MMSS-SAP) - between sms protocol and mobility management (MMSMS-SAP) - between mobility management and radio ressource (RR-SAP) - between radio ressource and layer 2 / layer 1 (let's call it RSLms-SAP) additionally there are interfaces: - between application and mobility management - between application and PLMN search - to the sim card - to the application - ... here is what i think the messages should look like. please correct me if i am wrong or if you have suggestions: MNCC-SAP: <gsm48_mncc structure> MMCC-SAP, MMSS-SAP, MMSMS-SAP: <gsm48_mmxx structure>[<L3 message*>] RR-SAP: <gsm48_rr structure>[<L3 message*>] RSL-SAP: <abis_rsl_rll_hdr structure>[<L3 message*>] * the layer 3 message consists of the gsm48_hdr structure + additional information elements. if a layer 3 message moves from call control down to RSL and even lower, the inter-layer headers are pulled and pushed. additionally there are pointers to the beginning of the headers inside the message: - l1h - l2h - l3h - layer 4 headers - layer 5 header the inter-layer messages (MMxx-SAP and RR-SAP) will have no pointer to the message structures. i think they also should not have them, since they have fixed length and are pushed at the time they are sent, and pulled at the time they are received. any suggestions? andreas

1 0

Yet Another Way of Communication
by Samuel Omlin 01 Apr '10

01 Apr '10

Hi, First off, thank the community--OsmocomBB for launching and then sharing the development of mobile protocol stack first. As we can understand, the current mailing list has been acting as the primary way of communicating between one another on the project basis. For these quick questions as well as immediate discussions, however, most likely there should be yet another way to complement, like irc on the freenode. Or, for the above issue you guys out there have other ways to solve, eh? If so, please take me into the circle as well, just because I have too many questions to ask. :) Thanks. Best Regards, Samuel

2 1

AW: noisy cable?
by Andreas.Eversberg 30 Mar '10

30 Mar '10

> but found that the connection is extremely noisy. > often the movement of me putting down the phone on the table is enough > to break the upload. i had a similar problem with an unconnected input pin which caused a reset of a microcontroller, just by moving some centimeters in a distance of one meter. check if you have left unconnected input pins on your USB converter. what about hardware flow control input? (RTS/CTR) andreas

1 0

fixing socket name
by willem 30 Mar '10

30 Mar '10

the /tmp/osmoncon* sockets created by osmocon are created one character too short. willem fix: diff --git a/src/host/layer23/src/main.c b/src/host/layer23/src/main.c index 8e76e8b..9e37fbf 100644 --- a/src/host/layer23/src/main.c +++ b/src/host/layer23/src/main.c @@ -244,7 +244,7 @@ int main(int argc, char **argv) local.sun_path[sizeof(local.sun_path) - 1] = '\0'; rc = connect(ms->wq.bfd.fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local.sun_family) + strlen(local.sun_path) + 1); if (rc < 0) { fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); exit(1); diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index f934dd7..b361eb1 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -629,7 +632,7 @@ static int register_tool_server(struct tool_server *ts, local.sun_path[sizeof(local.sun_path) - 1] = '\0'; unlink(local.sun_path); rc = bind(bfd->fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local.sun_family) + strlen(local.sun_path) + 1); if (rc != 0) { fprintf(stderr, "Failed to bind the unix domain socket. '%s'\n", local.sun_path); diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index ecee8b3..fdf417a 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -128,7 +128,7 @@ loader_connect(const char *socket_path) { } rc = connect(conn->fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local.sun_family) + strlen(local.sun_path) + 1); if (rc < 0) { fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); exit(1);

3 4

AW: layer3 work / issues
by Andreas.Eversberg 30 Mar '10

30 Mar '10

hi harald, >> must random value in chan_request change on every resend or only on >> every RR establishment? (currently it changes on every RR >> establishment only.) > >as far as I know, it has to change on every retransmission. Dieter is >probably the person who knows all RACH aspects in detail, maybe he can >comment on this. from the specs it is quite clear that every access burst has different random number when resending. but how does the network know if the burst is from the same phone but retransmitted? in case of poor uplink many bursts may be resent. will the network allocate a channel for every burst received and waits for timeout? (if this is the case, emergency calls could quickly 'evacuate' the cell.) >> OpenBSC: if tx-msg fails during process, the msg must be freed to >> avoid memory leak. > >I don't understand, can you please explain this further? it is something to remind me that there are memory leak problems. in some functions of gsm_04_08.c there are messages allocated at the beginning and sent at the end. sometimes during processing, the function returns due to error conditions, but the message is not freed before return. i will check that later together with my new code. as far as i can see right now, it just happens in gsm48_cc_tx_setup(). regards, andreas

2 1

Re: AW: layer3 work / issues
by Dieter Spaar 30 Mar '10

30 Mar '10

Hello Andreas, On Mon, 29 Mar 2010 13:39:21 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > from the specs it is quite clear that every access burst has different > random number when resending. but how does the network know if the burst > is from the same phone but retransmitted? in case of poor uplink many > bursts may be resent. will the network allocate a channel for every > burst received and waits for timeout? (if this is the case, emergency > calls could quickly 'evacuate' the cell.) It does not even need a poor uplink. I experience this behaviour for example with OpenBSC and the nanoBTS. If the "Immediate Assignment" is not sent fast enough, a retransmitted RACH burst will allocate another channel (the timeout for releasing an unused channel is around 2 to 5 seconds in "real" GSM networks). The maximum number of the retransmitted RACH burst is controlled by a parameter in the SYSTEM INFORMATION messages (there are several parameters which control the RACH transmission behaviour). Of course a "bad phone" can ignore those parameters and a DoS attack with continuous RACH bursts works quite well because the BTS or network does not know from which phone the burst come from. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: noisy cable?
by Dieter Spaar 30 Mar '10

30 Mar '10

Hello Christian, On Mon, 29 Mar 2010 13:27:31 +0200, "Christian Vogel" <vogelchr(a)vogel.cx> wrote: > > I'm using a self-made cable consisting of a known good FT232R > converter @ 3.3V and a cut off headset cable (that also worked > flawlessly without any noise on another mobile phone before). My C123 > also looks pristine. I manage to upload and run hello world > successfully in maybe one out of ten attempts, often have to remove > the battery because the phone just gets stuck. So I have ordered a new > cable from Akku-King as suggested on the Wiki. My experience: I work under Windows with Cygwin so the OS internals how the serial port is handled are (totally) different than Linux. With the non-blocking variant of "osmocon" it was nearly impossible to download the code to the phone in a reliable way. So I had to apply an ugly hack to my version which basically switches the serial connection to "blocking mode" during the download phase. This way it works rather reliable here (regardless of using a "real" RS232 port or an USB to serial converter). So you might experience the same problem instead of a bad cable. You can try the attached patch to "osmocom.c". The patch is not for the latest GIT version, however it should be quite easy to apply it to the current on. Again, its an ugly hack, but it works for me. Best regards, Dieter Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: noisy cable?
by Dieter Spaar 30 Mar '10

30 Mar '10

Hello Willem, On Mon, 29 Mar 2010 12:39:35 +0200, "willem" <itsme(a)xs4all.nl> wrote: > > but found that the connection is extremely noisy. > often the movement of me putting down the phone on the table is enough > to break the upload. > is that a common problem with these headphone/serial cable plugs?

1 0

Re: layer3 work / issues
by Dieter Spaar 28 Mar '10

28 Mar '10

Hello Harald, On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > as far as I know, it has to change on every retransmission. Dieter is > probably the person who knows all RACH aspects in detail, maybe he can > comment on this. According to the specification the random value has to change on every transmission: a random reference which is drawn randomly from a uniform probability distribution for every new transmission. In the TSM30 firmware this is done by having a table with random values and an index into the table which is initialised to a random value when the Immediate Assignment Procedure is started and incremented with every random number taken for a retransmission. The table has 32 values because the random reference is not larger than 5 bits. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

layer3 work / issues
by Harald Welte 28 Mar '10

28 Mar '10

Hi Andreas, some comments regarding your issues.txt: > must random value in chan_request change on every resend or only on > every RR establishment? (currently it changes on every RR > establishment only.) as far as I know, it has to change on every retransmission. Dieter is probably the person who knows all RACH aspects in detail, maybe he can comment on this. > must be expanded: struct osmocom_ms: no problem here, expand it how you see fit. I just generally prefer caller-allocated structures to callee-allocated ones, and I'd like to use static allocation whenever possible. So if there's only one 'struct rrlayer' per ms, then we should simply include 'struct rrlayer' as sub-structure of 'struct osmocom_ms', rather than having two structures and pointers between them. > OpenBSC: if tx-msg fails during process, the msg must be freed to > avoid memory leak. I don't understand, can you please explain this further? > random acces via RSL? I think we simply add some new / non-standard primitives, as it does not have any notion of RACH bursts. It might also be possible to encode it as UNIT DATA REQUEST for channel (chan_nr) RACH (CCCH uplink), but then we still cannot specify details like at which frame number, etc. From what I can see, your RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom RSLms message and nothing specified in the original RSLms spec. Cheers, 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel