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
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
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)
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
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
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)
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
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
Hi!
After quite a bit of hacking on libosmocore as well as the various
parts of Osmocom-BB, I've now committed the latest state to the 'uplink'
branch of osmocom-bb.git.
I have decided to introduce RSL/RLL as the interface between Layer2(LAPDm)
and Layer3(04.08), as it is a clean protocol that we already understand
from the OpenBSC side.
You can see in src/host/layer2/src/osmocom_rslms.c how we receive
e.g. the 04.08 PAGING REQUEST and 04.08 IMMEDIATE ASSIGNMENT on the
PCH/AGCH inside RSL UNIT DATA INDICATION messages.
Please note the layer2/src/lapdm.c implementation is extremely incomplete,
particularly when it comes to ABM (asynchronous balanced mode) and I-frames.
It's full of FIXME's that I'll be working on as soon as possible.
However, the infrastructure now seems to be coming together and we basically
have everything in place for bi-directional transmission of data for SAPI0 and
SAPI3 for both DCCH and ACCH (limited to SDCCH/4 on combined CCCH on C0T0)
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)
