baseband-devel

baseband-devel@lists.osmocom.org

1 participants
2024 discussions

GSMTAP / layer23 / wireshark updates
by Harald Welte 04 Mar '10

04 Mar '10

Hi! I've improved the layer23 gsmtap support to add support for * uplink frames, sent by layer23 to L1 * properly support dedicated channels with LAPDm * allow the user to specify the GSMTAP destination IP address In order to use the new features, you need to 1) use the new gsmtap.patch for wireshark 2) use the '-i dstip' option of layer23, as the default is now to NOT generate GSMTAP UDP Packets I'm attaching a screen-shot showing the wireshark decode of the LOC UPD REQ generated by layer23. As you can see from the packet list, the BTS responds with the UA packet containing the same LOC UPD REQ as part of the contention resolution in LAPDm, just as expected. 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)

2 3

BTS
by Maxim 04 Mar '10

04 Mar '10

Hi, There is at least a theoretic way to turn Motorola C123 into a small BTS? Thanks

2 1

RFC: updated Wireshark patch
by Jason 04 Mar '10

04 Mar '10

All, I found some low-hanging fruit. :-) Attached is an updated patch against the latest wireshark trunk svn. It incorporates all of the requested changes in the bug comments [1]. Hopefully I'll be able to pitch in more once my C123 arrives... hth, Jason. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4508

2 2

Re: hello_world.bin on C118
by Dieter Spaar 03 Mar '10

03 Mar '10

Hello Chekov, On Mon, 01 Mar 2010 15:32:53 +0100, "chekov" <chekov(a)riseup.net> wrote: > > still, this info differs from the wiki: > the last section is missing and the second last section is printed twice What you receive as output is OK, the current version of "hello_world" prints the same clock configuration twice and doesn't start the DSP. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 3

Status update / layer23
by Harald Welte 03 Mar '10

03 Mar '10

Hi! I'm pleased to report that the current master branch in osmocom-bb.git has initial support for bi-directional communication, and handles messages all the way up from L1 to L3 and back. The architecture is as follows: L1 events (such as received 23byte mac blocks) are encapsulated in L1CTL messages, which are sent over HDLC/rs232 to the PC. 'osmocon' then demultiplexes the L1CTL from the console messages and sends it via unix domain socket to the layer23 program. Inside layer23, L1CTL is decapsulated and passed into the LAPDm code, from where the data is encapsulated in RSLms (RSL for mobil station, my invention) and handed off to L3. Messages from L3 take the opposite way L3->RSLms->LAPDm->L1CTL->HDLC->L1 So far, we still only support IMMEDIATE ASSIGNments to SDCCH/4 on a combined CCCH. But if you are on a BTS with that channel configuration, layer23 will now happily send a LOCATION UPDATE REQUEST to the BTS :) Dieter has indicated he will be looking into supporting TCH/F as well as frequency hopping during the next week(s). I myself desperately need to get some real work done at this point, so don't expect any major developments for some time. 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

Strange Problem / Cheap Cables
by Lubomir Schmidt 03 Mar '10

03 Mar '10

Hello. First of all: You can get here extremely cheap the defenetly correct cable(i buy it with hope it could be the right one and had luck. Now everybothy can get a cheap one): http://www.dealextreme.com/details.dx/sku.14664 You could add/change that in the wiki. How it is connected: GND: next to the cable and COM-Port-Pin nr 5 Rx: in the middle and COM-Port-Pin nr 2 Tx: at the smal end and COM-Port-Pin nr 3 And now my problem: I use ARM binary from here: http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_X Everything compiled fine so far. I doesnt use any converter. Just use a real com Port from a older Notebook. I run: ./osmocon -m c123 -p /dev/ttyS0 ../where_the_firmware_is/hello_world.bin And get the result you see in the attachment. Phone: It is an C118 with Firmware 1.0.75 and it is locked to Vodafone DE. I tried today nearly 5 hours all tools for windows i could find to unlock the phone. There was no tool that worked(some also worked with pressing on-button shortly in off-modus). Maybe the problem is in the computer i used (also older one with real com-port.notebook is linux-only). Maybe the phone. Did i understand right, that when i get the output like here: http://bb.osmocom.org/trac/wiki/osmocon I also could get somehow the unlock key? Can you tell me then how? The Unlock Code is always 8 Numbers. After 5 hours i also know that it could be in A:0x7FC300 or A:0x7FC600 Thanks so far

2 2

Re: Strange Problem / Cheap Cables
by nicolho 03 Mar '10

03 Mar '10

hi everyone, could the strange problem be related to the cheap cable...? still waiting for usb data cable from akku-king (supply issue... related to osmocomBB project ?), i'm also experiencing unstable serial communications with this cable : http://www.multi-unlock.com/images/mot-t191.jpg some related questions : does someone here use this cable ? : http://gsmserver.com/newshop/images/large/COM_cable_for_Motorola_T191.jpg can we use direct connection to PC serial port (UART or usb serial adapter) safely ? i mean without any ttl level conversion (like max-232) ? which exact FTDI usb to serial chipset (ie FT232R) is most recommended, with : - good linux driver support - support for a possible future use of higher non-standard baud rates ? is there any serial port configuration trick or driver tweak to get better serial communications with osmocon ? thanks nico

2 1

uplink branch merged / CONFIG_TX_ENABLE
by Harald Welte 02 Mar '10

02 Mar '10

Hi! I have decided to merge the uplink branch as master didn't even build and wasn't receiving any attention from my side. In order to avoid any accidents, the default builds of the master branch will not include any Tx functionality. If you want to enable it, you have to use "CONFIG_TX_ENABLE" while compiling (by enabling it in Makefile.inc). 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

l1test hangs
by Hessel 02 Mar '10

02 Mar '10

Hi all, This weekend I had my first try with a C123, and everything seemed to work great from the start. But suddenly when uploading l1test.bin to the phone, it seems to hang after the first three ARFCN's found, like so: Hello World from apps/l1test/main.c program code ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Dropping sample '~' ============= Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Download Status: 0x0001 DSP API Version: 0x975b 0xadac Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 Performing power measurement over GSM900 LOST!ARFCN Top 10 Rx Level ARFCN 7: -102 dBm ARFCN 10: -103 dBm ARFCN 14: -103 dBm When I press any button of the phone it continues by showing the remaining ARFCNs, but nothing else: ARFCN 43: -103 dBm ARFCN 85: -103 dBm ARFCN 87: -103 dBm ARFCN 105: -103 dBm ARFCN 115: -103 dBm ARFCN 123: -103 dBm ARFCN 96: -104 dBm Starting FCCH Recognition key=12 pressed key=12 released I also noticed the dBm values, all channels are barely above the noise floor, right? Does anybody have tips on how to get running again? Thanks, Hessel

2 2

Re: Getting Started..
by Dieter Spaar 02 Mar '10

02 Mar '10

Hello Thomas, On Mon, 01 Mar 2010 23:45:43 +0100, "Thomas Kindler" <mail+gsm(a)t-kindler.de> wrote: > What do I do wrong? There is probably something wrong with your cable or configuration. I have marked the lines below in your log, the marked bytes are the "download command" sent by osmocon. Those bytes are never echoed back by the bootloader and you should not see them. So you should first check why you see those bytes. > got 2 bytes from modem, data looks like: 04 81 > got 5 bytes from modem, data looks like: 1b f6 02 00 41 > got 1 bytes from modem, data looks like: 01 > got 1 bytes from modem, data looks like: 40 > Received PROMPT1 from phone, responding with CMD > read_file(../../target/firmware/hello_world.bin): file_size=16676, > hdr_len=4, dnload_len=16683 > got 1 bytes from modem, data looks like: 1b <<- should not be there > got 1 bytes from modem, data looks like: f6 <<- should not be there > got 1 bytes from modem, data looks like: 02 <<- should not be there > got 1 bytes from modem, data looks like: 00 <<- should not be there > got 1 bytes from modem, data looks like: 52 <<- should not be there > got 1 bytes from modem, data looks like: 01 <<- should not be there > got 1 bytes from modem, data looks like: 53 <<- should not be there > got 1 bytes from modem, data looks like: 66 > got 1 bytes from modem, data looks like: 74 > got 1 bytes from modem, data looks like: 6d > ... Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel