Hello,
I tried to use a Huawei E1823 UMTS-Stick on a debian8-laptop with wvdial and pppd to connect to a nano3G for getting an IP/Internet-connection via UMTS/HSDPA.
The setup is mainly as described on http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_wi….
When using an android-Smartphone with the same configuration of the ggsn and the other components the IP/Internet-connection is working.
After pppd is started from wvdial it receives his local IP-address from the "net 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but no remote-IP, so 10.64.64.64 is used by pppd as a default value:
...
--> local IP address 192.168.99.5
--> pppd: �[7f]
--> remote IP address 10.64.64.64
--> pppd: �[7f]
--> primary DNS address 8.8.8.8
--> pppd: �[7f]
..which results in an unusable ppp0-device:
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.99.5 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
Has anybody successfully used an UMTS-Stick with ggsn?
How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote IP address"?
Are there special options for pppd which I have to use?
thanks and greetings,
Andreas
Hello,
I have set all the traffic channels to TCH/H and started the BTS but I was not able to perform a call. Is there something else that should be done ?
Best regards,
Dear all,
I have just submitted some patches which allow test cases to use the
Control Interface internally, without binding to a TCP port. See
https://gerrit.osmocom.org/#/c/2375/ and
https://gerrit.osmocom.org/#/c/2376/
Using this, one can now write unit tests for control commands, without
having to go for a multi-process setup with an external control client
connected to the control TCP port (which is not easily possible in CI as
the port might be used by another test case, ...)
--
- 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,
We just finished installing the following osmo elements using Ubuntu 14.04 and the procedures from this link:
https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_f…https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source
* libosmocore
* libosmo-abis
* libosmo-netif
* openggsn
* libosmo-sccp
* openbsc
* osmo-pcu
* osmo-trx
* osmo-bts
We are now trying to run each applications to test osmo. All applications were run smoothly except for osmo-trx and osmo-bts-trx.
We also installed the UHD driver of Ettus B2xx series using both “apt-get install” process and binary process as well using this link:
https://files.ettus.com/manual/page_install.htmlhttps://files.ettus.com/manual/page_build_guide.html
But still, the same errors were received.
Errors received:
# osmo-trx
[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-128-g379f922d
opening configuration table from path :memory:
Config Settings
Log Level............... NOTICE
Device args.............
TRX Base Port........... 5700
TRX Address............. 127.0.0.1
Channels................ 1
Tx Samples-per-Symbol... 4
Rx Samples-per-Symbol... 1
EDGE support............ Disabled
Reference............... Internal
C0 Filler Table......... Disabled
Multi-Carrier........... Disabled
Diversity............... Disabled
Tuning offset........... 0
RSSI to dBm offset...... 0
Swap channels........... 0
osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE
# osmo-bts-trx -c /etc/osmo-bts.cfg
((*))
|
/ \ OsmoBTS
There is no such command.
Error occurred during reading below line:
fn-advance 20
Failed to parse the config file: '/etc/osmo-bts.cfg’
What seems to cause this errors?
What logs do we need to check?
Best Regards,
Ron Rylan B. Menez
Operations Manager
+63 998 989 7973
+63 2 893 1781
[cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC]
Singapore * Philippines
Products:
Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development
This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you.
Hi,
this is the BTS test report for week14 2017.
BTS models which have been tested with OsmoNITB are:
- sysmoBTS1002
- octasic OCTBTS3500
- ettus USRP B200
- nanoBTS model:165G
Most test cases have passed:
sysmobts and nanobts worked without issue.
the only one failing were with the octbts:
the issues there were reliability of establishing a voicecall and or
gprs. only every 2nd or 3rd attempt works.
on the 3 TCH/H, 3 PDCH config gprs was not working at all
with the ettus B200 everything worked but gprs seemed extremely slow or
lossy. i could only view small testpages, big graphics do not load.
For additional information related to test cases, timeslots
configuration and voice codecs used, please visit:
https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests
following are some git hashes/version strings of tested components:
libosmo-abis: bf7976c0b0076410ad1bd67061dd18d0f33a7f43
libosmocore: ff20641d9e3bb4373f9577c3382df1480ace4e91
libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437
libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23
libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857
openbsc: 2d92162a6b6720d72129bee1bcbef353b0fd0aa6
openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da
osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d
osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d
osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e
osmo-trx: 6031734f448c6308d67b1ee464a13d60b33cd843
sysmobts: OsmoBTS version 0.4.0.414-e16b5
sysmobts: Osmo-PCU version 0.2.900-e6d2
octbts: (name='octsdr_gsm', desc='Software Define Radio',
ver='02.07.00-B1039', ver_hdr='02.07.00-B1039')
octbts: (platform='Opus2',
version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;')
nanobts: Equipment_Version='165g029_79'
nanobts: Software_Version='168d462_v200b202d0'
if you are interested in the details, drop me a mail and i'll forward
the whole report.
kind regards
--
- Joachim Steiger <jsteiger(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Harald Welte
Dear all,
[Despite today being April 1st, this is not an april fool's joke]
ever since the start of the Osmocom project, we have adopted pretty much
1:1 the Linux Kernel coding style.
Having a uniform coding style all over the project is important for
readability, and from my point of view it doesn't really matter too much
which style it is, as long as it is uniform accross the projects.
I'm still fine with the Linux kernel coding style for most parts, but I
think we could consider allowing longer lines. 80 characters is still
nice here and there, but maybe something like 100, 120 or even 130 might
actually make the code more readable and permit us to use slightly
longer identifiers without having to wrap every second statement in the
code.
What do people generally think here?
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)
Hi Pau (and maybe others),
here is a test script that showcases how I'd like to use DBus in the
osmo-gsm-tester: use pydbus and keep the glib main loop in a thread (to handle
DBus signals only). It sounds ambitious but the test program actually works.
Would be great to hear your opinion on it:
http://git.osmocom.org/osmo-gsm-tester/tree/selftest/dbus_test/ofono_client…
The same thing cosmetically rearranged as module stub:
http://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/dbus_client…
Thanks!
~N
Related: OS#1980 https://osmocom.org/issues/1980
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi All,
Requesting your help regarding the case that we had encountered during the installation of osmo-bts using UBUNTU 14.04 as OS.
Without using the 201509-fairwaves-rebase, the installation go past through. Unfortunately, there is no “osmo-bts-trx” executable. Below are the steps we followed for the installation of osmo-bts.
cd /opt/osmo/src/
git clone git://git.osmocom.org/osmo-bts
cd osmo-bts
autoreconf -fi
./configure
make -j5
make check
make install
We tried using the 201509-fairwaves-rebase, but unfortunately the installation stops and an error was encountered during the “make” process. Below are the installation steps and error encountered:
cd /opt/osmo/src/
git clone git://git.osmocom.org/osmo-bts
cd osmo-bts
git checkout 201509-fairwaves-rebase
autoreconf -fi
./configure --enable-trx
make
Error encountered:
make[2]: Entering directory `/opt/osmo/src/osmo-bts/src'
Making all in common
make[3]: Entering directory `/opt/osmo/src/osmo-bts/src/common'
CC gsm_data_shared.o
CC sysinfo.o
CC logging.o
CC abis.o
abis.c: In function ‘abis_open’:
abis.c:233:25: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
bts_dev_info.unit_name = model_name;
^
abis.c:236:25: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
bts_dev_info.location2 = model_name;
^
CC oml.o
oml.c:46:30: error: conflicting type qualifiers for ‘abis_nm_att_tlvdef_ipa’
static struct tlv_definition abis_nm_att_tlvdef_ipa = {
^
In file included from oml.c:33:0:
/usr/local/include/osmocom/gsm/abis_nm.h:37:36: note: previous declaration of ‘abis_nm_att_tlvdef_ipa’ was here
extern const struct tlv_definition abis_nm_att_tlvdef_ipa;
^
oml.c:373:6: error: nested redefinition of ‘enum abis_nm_t200_idx’
enum abis_nm_t200_idx {
^
oml.c:373:6: error: redeclaration of ‘enum abis_nm_t200_idx’
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:647:6: note: originally defined here
enum abis_nm_t200_idx {
^
oml.c:374:2: error: redeclaration of enumerator ‘T200_SDCCH’
T200_SDCCH = 0,
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:648:2: note: previous definition of ‘T200_SDCCH’ was here
T200_SDCCH = 0,
^
oml.c:375:2: error: redeclaration of enumerator ‘T200_FACCH_F’
T200_FACCH_F = 1,
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:649:2: note: previous definition of ‘T200_FACCH_F’ was here
T200_FACCH_F = 1,
^
oml.c:376:2: error: redeclaration of enumerator ‘T200_FACCH_H’
T200_FACCH_H = 2,
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:650:2: note: previous definition of ‘T200_FACCH_H’ was here
T200_FACCH_H = 2,
^
oml.c:377:2: error: redeclaration of enumerator ‘T200_SACCH_TCH_SAPI0’
T200_SACCH_TCH_SAPI0 = 3,
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:651:2: note: previous definition of ‘T200_SACCH_TCH_SAPI0’ was here
T200_SACCH_TCH_SAPI0 = 3,
^
oml.c:378:2: error: redeclaration of enumerator ‘T200_SACCH_SDCCH’
T200_SACCH_SDCCH = 4,
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:652:2: note: previous definition of ‘T200_SACCH_SDCCH’ was here
T200_SACCH_SDCCH = 4,
^
oml.c:379:2: error: redeclaration of enumerator ‘T200_SDCCH_SAPI3’
T200_SDCCH_SAPI3 = 5,
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:653:2: note: previous definition of ‘T200_SDCCH_SAPI3’ was here
T200_SDCCH_SAPI3 = 5,
^
oml.c:380:2: error: redeclaration of enumerator ‘T200_SACCH_TCH_SAPI3’
T200_SACCH_TCH_SAPI3 = 6
^
In file included from oml.c:32:0:
/usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:654:2: note: previous definition of ‘T200_SACCH_TCH_SAPI3’ was here
T200_SACCH_TCH_SAPI3 = 6
^
make[3]: *** [oml.o] Error 1
make[3]: Leaving directory `/opt/osmo/src/osmo-bts/src/common'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/osmo/src/osmo-bts/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/osmo/src/osmo-bts'
make: *** [all] Error 2
We followed the installation process from the URLs below:
https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_f…https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source
Best Regards,
Ron Rylan B. Menez
Operations Manager
+63 998 989 7973
+63 2 893 1781
[cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC]
Singapore * Philippines
Products:
Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development
This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you.
