Hi, I am reading the OpenBSC_GPRS wiki page and trying to get GPRS up and running. On the wiki it says:
!
! Osmocom SGSN configuration
!
!
line vty
no login
!
sgsn
gtp local-ip 192.168.1.128
ggsn 0 remote-ip 192.168.1.129
ggsn 0 gtp-version 1
!
ns
timer tns-block 3
timer tns-block-retries 3
timer tns-reset 3
timer tns-reset-retries 3
timer tns-test 30
timer tns-alive 3
timer tns-alive-retries 10
encapsulation udp local-ip 192.168.0.128
encapsulation udp local-port 23000
encapsulation framerelay-gre enabled 0
!
bssgp
!
Shouldn't encapsulation udp local-ip and gtp local-ip be the same if everything is on the same subnet?
Also I have all 3 processes running openggsn, osmo-sgsn and bsc_hack but GPRS does not attach on any of my handsets. What could be the problem?
Hi all,
after months of work on the BSC API and on/off on the osmo-bsc it seems to be
close to a working state. It has a lot of code from bsc_msc_ip of the
on-waves/bsc-master branch but in a better structure thanks to the BSC API.
Right now it is on the zecke/osmo-bsc branch and has about 58 commits to build
the BSC. It can be found in the src/bsc directory and has the main files:
osmo_bsc_main.c - The main method
osmo_bsc_sccp.c - To handle the SCCP connections, connection release,
connection timeouts, IT timer..
osmo_bsc_msc.c - To handle the connection(s) to the MSC, authentication,
ping/pong to test the link and connection failure via a signal
osmo_bsc_bssap.c - This is parsing the GSM0808 messages and maps that to the
BSC API functions
osmo_bsc_api.c - Callbacks for the BSC API, creating GSM0808 messages and
sending them to the MSC
osmo_bsc_sound.c - Handle the CRCX_ACK and send a MDCX...
osmo_bsc_filter.c - To inspect incoming and outgoing packets and provide extra
functionality.
osmo_bsc_vty.c - VTY options for the MSC connection(s). This is a msc subgroup
of the VTY.
I will have to heavily test the new code for leaks, crashes, failure and such
and will do this with call testing overnight, but I think it should not be
less stable than bsc_msc_ip.
There are two things that should be done next. Work on paging and decouple the
BSC part of scheduling the messages, not scheduling too many to not crash the
nanoBTS and the MSC part that triggers the callback. Be able to 'switch' from
Osmo-BSC functionality and bsc_hack functionality on the fly. This could be
very interesting for fuzzing that only after a certain message someone wants
to start fuzzing with an external app. Use the MSC functionality from a new
application and have a true MSC...
Hi guys, how do we calibrate the internal ocilator of the nanoBTS? I have a 139 unit which has synced up fine and has a olid green light but the network no longer appears on the handsets selection menu (the handset is dual band and the BTS is on an AFRCN within the handsets range). It was working before but the unit has been powered down for several months and I remember someone from ip.access advising that the internal oscillator needs to be re-calibrated to fix this issue.
On 11/14/2010 09:13 PM, Stuart Baggs wrote:
> All compiled and installed. I'm running OpenBSC 0.3.99.20onwaves. Is this compatible with GPRS? I have compiled OpenGGSN and recompiled openbsc but I dont seem to be getting an osmo-sgsn binary created.
osmo-sgsn is only in master. You will need to get osmo-sgsn from the master
branch, bsc_msc_ip is only in the branch and will stay there.
Hi, I am trying to get a working GPRS branch up and running. I have done a fresh git clone of both libosmocore and openbsc master branches. Both compile without issue. When I try and run bsc_hack from /opt/openbsc/ I get this error:
./bsc_hack: error while loading shared libraries: libosmovty.so.0: cannot open shared object file: No such file or directory
Any ideas what has gone wrong with this install? Obviously openbsc cannot find libosmocore libraries, but I have compiled them cas per usual. Any ideas?
Thanks
Hi all,
recently I've been mentioning A5/4 in a couple of meetings. I've found
the (already approved) change requests that introduce A5/4 by coincidence
today:
http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_45/docs/SP-090635.ziphttp://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_46/docs/SP-090821.zip
So basically A5/4 (and GEA4) use a 128bit Kc, and this mandates the use
of an USIM in USIM application mode. Old GSM SIM cards are not sufficient.
So A5/4 will be the first algorithm that uses a different Kc and will thus
not suffer from semi-active downgrading attacks (like you can do with old
phones and A5/2 to break A5/1 or A5/3, or you can do today with A5/3 if you
later use the same RAND on an A5/1 encrypted session).
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,
I'm exicted to see the OpenBSC contribution and wanted to try out and test the OpenBSC. I tried hard to get the nano-bts so that I can deploy OpenBSC but could not find any place / dealer / online auction to get one (new / used).
I will appreciate if someone can help me pointing to the right people / firms from where I can buy the nano BTS.
Thanks,
Milind
