baseband-devel

baseband-devel@lists.osmocom.org

1 participants
2024 discussions

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

Developer Meeting in Berlin / 2010-04-10
by Harald Welte 05 Apr '10

05 Apr '10

Hi all! Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin. This is mainly for me to get an idea where we are (compared to before my holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog. I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system. I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join! 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

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 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel