baseband-devel March 2010

baseband-devel@lists.osmocom.org

37 participants
76 discussions

large collection of gsm related datasheets
by willem 19 Apr '10

19 Apr '10

i found this, searching google/codesearch for 'ftm_cmd' svn co http://hwplatform.googlecode.com/svn/trunk/ about 1.5G of datasheets, sourcecode, and tools for various phones. willem

5 4

noisy cable?
by willem 05 Apr '10

05 Apr '10

i managed to get hello_world working on my c121, connected through a pl2303 usb/serial cable to my macbookpro. 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? for the serial device i can use /dev/cu.PL2303-0000201A or /dev/tty.PL2303-0000201A but when using the '/dev/tty...' variant, i have to add this to osmocon.c 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 @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) /* hardware flow control off */ options.c_cflag &= ~CRTSCTS; + /* ignore modem status lines */ + options.c_cflag |= CLOCAL; + /* software flow control off */ options.c_iflag &= ~(IXON | IXOFF | IXANY); ============================= willem

4 3

Yet Another Way of Communication
by Samuel Omlin 31 Mar '10

31 Mar '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 29 Mar '10

29 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 29 Mar '10

29 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 29 Mar '10

29 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel March 2010