Hi all!
Since Kevin and I are trying to re-vitalize the simtrace project, I have
decided to create a new simtrace(a)lists.osmocom.org mailing list
dedicated to this project.
Yesterday at a meeting we have discussed
* to use a digitally-controlled analog switch to select sniffing /
emulation mode (i.e. to do a software-controlled 'cut' the electrical
connection between the SIM card and the phone)
* to add a header next to the USB socket so we can attach a battery pack
for autonomous operation
* to add a SPI NOR flash (for storage of data in autonomous operation)
* to not care about 1.8V-only SIM cards and make it a 3.3V-only device
We expect to do a bit more schematics review and component placement +
routing as well as a prototype PCB in the next couple of weeks.
Kevin is in charge of the hardware prototype, while I will look at the
firmware side as well as provide funding for the PCB manufacturing and
prototype components.
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)
Thanks Alex,
I actually played a bit with the code and found out that exactly half of the
times the write() call in the function
gsmtap_fd_cb() (gsmtap_util.c) fails because of EAGAIN or EWOULDBLOCK.
I implemented a retransmission in this case and this solve the problem: all
the gsmtap are successfully sent and received.
Though, I suspect is impacting negatively on the rest of the mobile program.
Anyway I do not have a real evidence of this only the fact that after the
modification I have never had a successful location update.
Do you think this is plausible? am I degrading the overall performances when
trying to get all the gsmtap? Can i solve this problem?
Thanks Alex and list,
Loretta
>----Messaggio originale----
>Da: vamposdecampos(a)gmail.com
>Data: 6-mag-2011 8.35
>A: "screaming-pain(a)libero.it"<screaming-pain(a)libero.it>
>Cc: <baseband-devel(a)lists.osmocom.org>
>Ogg: Re: lost dump ?!?!?
>
>On Thu, May 5, 2011 at 5:28 PM, screaming-pain(a)libero.it
><screaming-pain(a)libero.it> wrote:
>> Hi list,
>>
>> I know I am very slow in understanding osmocom-bb, anyway this is just a
quick
>> question.
>> Is it possible that some of the gsmtap messages are getting lost?
>> For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the
>> 'mobile' application log but there aren't the corresponding messages in the
>> wireshark capture,
>> though this does not always happen, I mean I had captures of location
updates
>> other times, this is why I am wondering if they are getting lost and what
it
>> does depend on.
>> for what I understood the gsmtap functions utilities are in gsmtap_util.c
and
>> the one to send the messages on the socket is called by l1ctl.c am I right?
>> Can you help me understanding why I cannot see all the messages?
>>
>> thank you in advance
>> Loretta
>
>Hi,
>
>I've had this happen to me when I wasn't receiving the gsmtap packets.
>
>Specifically, I had the gsmtap packets sent over the network (i.e.,
>non-localhost). There was no UDP listener on the receiving end, such
>that ICMP port-unreachable replies were being sent back. It would
>appear that this causes the sender's kernel to snub some of the
>outgoing packets. I don't know if the same happens on localhost.
>
>If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j
>DROP", or something like "nc -l -u 4729 > /dev/null".
>
>Cheers,
>Alex
>
>
Hi list,
I know I am very slow in understanding osmocom-bb, anyway this is just a quick
question.
Is it possible that some of the gsmtap messages are getting lost?
For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the
'mobile' application log but there aren't the corresponding messages in the
wireshark capture,
though this does not always happen, I mean I had captures of location updates
other times, this is why I am wondering if they are getting lost and what it
does depend on.
for what I understood the gsmtap functions utilities are in gsmtap_util.c and
the one to send the messages on the socket is called by l1ctl.c am I right?
Can you help me understanding why I cannot see all the messages?
thank you in advance
Loretta
Some questions about Sylvain testing branch:
why is not merged SIMreader into master branch?
is planned for mobile aplication to support SMS (sending/receiving)?
Thank you,
ArMaND VanHell
I'm looking for somebody in India who has a deep GSM interest and who
is preferrably a student. If you're quick, I have a free giveaway for
you.
Please simply e-mail me, details will follow.
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)
Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network) while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :)
GOOD CASE:
[0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE
[0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated
[0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5)
[0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005)
[0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20)
[0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
[0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
[0;m[0;35m<000e> sim.c:949 command successfull
[0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15)
[0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
[0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
[0;m[0;35m<000e> sim.c:949 command successfull
[0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9)
[0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6)
[0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00)
[0;m[0;35m<000e> sim.c:949 command successfull
[0;m[0;35m<000e> sim.c:151 sending result to callback function (type=0)
[0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0)
BAD CASE:
[0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE
[0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated
[0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5)
[0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005)
[0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20)
[0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
[0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f)
[0;m[0;35m<000e> sim.c:949 command successfull
[0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15)
[0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0)
[0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00)
[0;m[0;35m<000e> sim.c:949 command successfull
[0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9)
[0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6)
[0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated
--- On Wed, 5/4/11, Harald Welte <laforge(a)gnumonks.org> wrote:
From: Harald Welte <laforge(a)gnumonks.org>
Subject: Re: mobile - making a call
To: "eisencah eisenach" <wbg_1000(a)yahoo.com>
Date: Wednesday, May 4, 2011, 11:59 AM
On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote:
> So is as if the message for the sim job doesn't get pulled from the
> queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears. Must say
> the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz
> celeron with ubuntu 6.10) , and It gets slowed down when running the
> hole thing. Can that be the cause? Mihai.
The L1CTL protocol goes through a unix domain socket, and you can trace
it in either osmocon or in the mobile program itself. It should be
relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile,
or if it is lost, where it is lost.
--
- 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)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Some months ago, Richard Stallman (rms) has contacted me regarding
my work with OsmocomBB. As it is not a big surprise to us, he is
really interested in the project. After all, it would be the first
mobile phone that he himself would be able to use, given that there
is no proprietary software on the baseband anymore. And of course
it would enable loads of other freedom-loving users to finally have
an alternative to the proprietary telephony world.
Here in Morocco, I've had some further discussion on the topic face to
face with him, and he is sort of unhappy with the fact that nobody is
working on making an actual self-contained phone (no matter how simple
or limited in features) that can be used by a regular user as 'just a
phone'.
I explained to him that our motivation is mostly a different one
(research, security, GSM-attached PBX, etc.) and thus there is no
intrinsic motivation to work towards a more user-friendly version.
Furthermore, we are system level hackers with an interest in
communications, not particularly people who like to work on a UI
or usability.
So we agreed to make a public call for volunteers to wokr on that aspect
of the phone. I understand this will likely cause some effort on our
side (fencing off poeple who don't have the neccessary skills,
integrating such code, finally deciding on a RTOS to use, etc.).
However, I more or less see it as my (and our?) duty to realize the
potential of our protocol stack and baseband firmware. Next to all
our own self-motivated personal interestes, there is a bigger cause
that we can help along: Free Software based telephony. So the least
we can do is to try to find somebody who can work on that part, and
help developer[s] to interact with our code.
It's the question of whether we are just hacking away on our personal
little pet, or if we try to achieve something bigger.
I've already drafted a version of the 'job description' and with some
luck the FSF will soon publish it, reaching out beyond our existing
small Osmocom community.
e will try to draft a similar job description related to MS-side GPRS
support (L1, RLC/MAC, ..). That would be yet another area where we
would appreciate some contribution, and which eventually be important
beyond our existing voice telephony capabilities.
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iD8DBQFNvs0JXaXGVTD0i/8RArkDAKCONleE9HJ2i1jp7L/XnMY0YweIjACbB8Lz
puH7X4lkqY8AqzU0SAlOAxM=
=Cmo8
-----END PGP SIGNATURE-----
