Hi list,
It's my first time posting here, and I've just subscribed - so apologies
for totally wrecking archive threading.
I've just received a copy of the e-mail regarding the OT-290, thanks to
Andrew Back; and I'm wondering it's possible to discuss the feasibility of
implementing this functionality with Harald - since it doesn't seem to have
generated much interest from others, and I'm "fortunate" enough to live in
a small British town without EDGE coverage (which should make it easier to
test GPRS-related tracing functionality).
Although I'm unfamiliar with how things work in Osmocom, I've previously
worked on Wireshark dissectors for USB-encapsulated AT commands, and
various NFC/smartcard-related protocols (PN532, FeliCa and MiFare); and am
also familiar with Nokia's proprietary ISI baseband protocol, and parts of
ETSI's GSM/UMTS specifications - so this sort of stuff isn't totally alien
to me.
I'm also currently studying Computer Science as an undergraduate (at the
University of Bradford) - but I should be able to make time to work on this.
Thanks,
Tyson.
--
Fight Internet Censorship!
http://www.eff.orghttp://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
Hi all,
as we were running openbsc with a nanobts in a nitb configuration at our institute we observed two bugs in the authentification part of openbsc.
First:
In file openbsc/openbsc/src/libmsc/db.c on line 372 there is
"ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki_len);"
which takes the sizeof of the length value. This always results in a wrong keylength and hence no authentification will ever be executed. This should rather be changed to:
ainfo->a3a8_ki_len = sizeof(ainfo->a3a8_ki);
Secondly:
I haven't found the piece of code which is responsible for this bug particulary but:
Whenever the key for the a3a8_comp128 is being read from the database a shift of one bit occurs.
i.e. when you set the a3a8_key in the hlr.sqlite3 to 01010101010101010101010101010101 the value being processed as key in the a3a8_comp128 algorithm is 02020202020202020202020202020202.
Best Regards,
Robert Ingr
As reported in ticket #55 SGSN can crash due to double free-ing. You
can replace 'can' by 'will' in that last phrase. I had a sift through
the code and tried to solve this by removing the free in gprs_ns.c.
Whenever the calling function created the msgb-struct, I have made the
function free it after its use. If the function got the msgb from a
calling function, there will not be a free (hoping that will be done
on the higher level).
HTH/F
Hi all!
Thanks to a generous donor, we have received a couple of OT-290 trace
phones. These are commercial products intended for taking L2/L3 air
interface traces. If you've read any of the fabulous GSM papers by
Prof. Dr.-Ing. Joachim Goeller: The OT-phones is what he used to
generate all his traces.
The majority of what those phones can do is now also possible with
OsmocomBB.
However, OT-290 support GPRS tracing/testing - for CS-1 throguh CS-4.
I would be willing to give away one of the two remaining OT-290 (for
free) to anyone who would in return commit to developing a GSMTAP
interface for it.
The message format on the serial UART between phone and PC is documented
(PDF documentation by Sagem included with the phones). So based on this
documentation and an OT-290 phone, it should be possible to write a
small command-line program that receives the GSM/GPRS messages from the
OT-290 and sends them via GSMTAP into wireshark.
The result would then be similar to what
http://cgit.osmocom.org/cgit/dct3-gsmtap/ is for DCT-3 phones.
If you're interested, please respond to this message. Please don't
apply for the phone if you are not able to find the required time and
interest for actually doing the GSMTAP integration.
Thanks!
--
- 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,
I use OpenBSC/GPRS (sw version only few weeks old) with nanoBTS and this works well mith many mobile devices.
With Nokia devices, however, I do not get a PDP context. Here is an osmo-sgsn trace of Nokia E65:
<0012> gprs_bssgp.c:347 BSSGP TLLI=0x795b37eb Rx UPLINK-UNITDATA
<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0xc2ab0aCMD=UI DATA
<0013> gprs_llc.c:742 LLC RX: unknown TLLI 0x795b37eb, creating LLME on the fly
<0002> gprs_gmm.c:636 -> GMM ATTACH REQUEST MI(001011474110317) type="GPRS attach"
<0002> gprs_gmm.c:351 <- GPRS ATTACH ACCEPT (new P-TMSI=0x78bb36bb)
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
<0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA
<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0xc2ab0aCMD=UI DATA //remark: is a repetition of GMM ATTACH REQUEST
<0013> gprs_llc.c:525 TLLI=f8bb36bb dropping UI, N(U=0) not in window V(URV(UR:1).
<0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA
<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x478a8dCMD=UI DATA
<0002> gprs_gmm.c:1047 -> ATTACH COMPLETE
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
<0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA
<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x478a8dCMD=UI DATA //remark: is a repetition of ATTACH COMPLETE
<0013> gprs_llc.c:525 TLLI=f8bb36bb dropping UI, N(U=1) not in window V(URV(UR:2).
<0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA
<0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x29e399CMD=UI DATA
<0002> gprs_gmm.c:782 -> GMM DETACH REQUEST TLLI=0xf8bb36bb type=GPRS detach
<0002> gprs_gmm.c:425 <- GPRS DETACH ACCEPT
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
<0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
We see some dropped frames here which are in fact retransmissions sent by the Nokia device. After the successful GPRS Attach, the Nokia device refuses to send an ACTIVATE PDP Context REQ. Most Nokia devices get asked for IMSI and IMEI during the GPRS ATTACH, which her does not happen. However, these retransmissions are characteristical for all Nokia devices I've tested so far (6021, C5, C7, E65, 3109c).
Is there a timing problem between osmo-sgsn and Nokia devices? Can I tune osmo-sgsn's parameters to make the connection work?
Any help would be appreciated.
cheers
Olaf
----------------------------------------
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Hello,
Does anyone have recommendations for obtaining SIM cards? I'm trying
to get at least 500, unprinted and unprogrammed. Ideally, I'd be able
to buy 1,000 (or more) cards for around USD$1,000 total, but I'd be
willing to go up to 5,000 cards if the price drops to something like
USD$0.50 per card.
Thanks!
--
Duncan Smith
http://xrtc.net/f/
Hi all!
This is the announcement for the 3rd incarnation of our bi-weekly
Osmocom Berlin meeting.
May 09, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin
The schedule is as follows:
19:00 Introduction / Workshop on Osmocom SIMtrace (Kevin Redon)
Kevin will introduce SIM/USIM/UICC cards, present what SIMtrace
is and how it works, as well as how to use it to trace
communication between SIM card and phone.
20:00 Informal discussions
If you are interested to show up, feel free to do so. There is no
registration required. If the initial part is not interesting to you,
feel free to join us later at 20:00. The meeting is free as in "free
beer", despite no actual free beer being around ;)
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)
Holger wrote:
> wanted to avoid this issue is that whoever transmits needs to select the
> llme/lle. I think my code set old_tlli to the foreign or such but I dropped it
> (and can't remember why it wasn't needed anymore).
Been there, tried that. It wasn't so much that is wasn't needed, but elsewhere
in the code old_tlli (and especially the fact if it is 0xffffffff or
not) is used to (re)set
some stuff.
> This will not be the last issue you will experience with GPRS. Both the
> nanoBTSs implementation and our SGSN are not very stable.
Well... only 7 hours of Qday to go ;-)
> Some of the known GPRS issues include:
>
> - http://openbsc.osmocom.org/trac/ticket/55 (crash)
I solved that one
> - http://openbsc.osmocom.org/trac/ticket/44 (correctness)
> - http://openbsc.osmocom.org/trac/ticket/43 (leak)
Will check these.
> There is also the 'santos' branch of someone that forked our code and has
> done a bit of bugfixing.
Ah ok. I'll look into that. Might be of use during the last couple of hours
HTH/F
I might be horribly wrong, but there is something I did not grasp in
gprs_llc.c. So I altered it, but since I am not sure I share it here...
Function 'gprs_llc_tx_ui' uses function 'lle_by_tlli_sapi' to retrieve an
lle based on a tlli/sapi combination. To do the lookup, the supplied tlli
is 'localized' (tlli_foreign2local). If this does not result in a succesful
find, function 'llme_alloc' is used to "create an LLME on the fly". However
'llme_alloc' does not localize the tlli. So every next search for the lle
fails.
For this I created this patch:
--- openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30 15:42:58.958823325 +0200
+++ ../openbsc/openbsc/openbsc/src/gprs/gprs_llc.c 2012-04-30
10:54:11.291836887 +0200
@@ -157,7 +160,8 @@
if (!llme)
return NULL;
- llme->tlli = tlli;
+ llme->tlli = tlli_foreign2local(tlli);
llme->old_tlli = 0xffffffff;
llme->state = GPRS_LLMS_UNASSIGNED;
This seems to have solved the problem (unable to get an IP link
operational), but I am not sure if this was the correct way to handle this,
so please feel free to comment.
HTH/F
Goodafternoon,
This is just a quick email to let you know that we are currently (as in:
today) using OpenBSC to offer a GPRS service to some equipment during
Queensday. For those of you that do not know this: Queensday is a Dutch
festivity where the birthday of the Queen is celebrated. It attracts a mass
of people and under that condition no (normal) mobile network will stay
operational. Since we have some equipment running, we decided to try out
creating our own mobile network. For this we installed several ip.access
nanoBTSes and use OpenBSC as central software.
Unfortunately this is not a complete success. Although we tested it and
those tests gave us confidence, we now experience a lot of connection
losses. Several nanoBTS'es bootstrap quite regularly, and almost all
connected devices are unreachable after several minutes (some later than
others). Only restarting OmniBSC quite often seems to bring back some life.
Up until now I have been unable to find out why things are wrong.
While preparing for this use of OpenBSC I came accross some things that
might be worthwhile to share with you. I'll do that in separate messages,
so contents does not get clobbered. Please allow me to thank you all for
the great work you have done in this set of software. I hope some of my
experiences will help you pushing this forward.
Kind regards,
Frank
