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)
