== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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 all,
A discussion was started during the review of
https://gerrit.osmocom.org/10116/.
The main idea of this change is to fix the behaviour of 'logging level all
LEVEL',
but I think it was also mixed with some additional feature, which I would
like
to discuss here, publicly.
First of all, the change introduces a new special logging level 'unset',
which allows one to reset a given category (i.e. unset its custom value):
!! Initial logging configuration:
logging level all error
logging level mncc debug
logging level pag notice
logging level meas debug
!! Resetting DMNCC:
# logging level mncc unset
!! So, now DMNCC has no custom log level, it will use
!! the default level (in this example it is 'error'):
logging level all error
logging level pag notice
logging level meas debug
This feature looks fine and extremely useful for me.
But (among fixing) this change additionally changes the behaviour
of a command for setting the default logging category (i.e. 'logging
level all LEVEL'):
!! Initial logging configuration:
logging level all error
logging level mncc debug
logging level pag notice
logging level meas debug
!! Changing the default logging level:
# logging level all debug
!! Ahhh, I've lost my custom levels :(
logging level all debug
!! What I expected to get:
logging level all debug
logging level mncc debug
logging level pag notice
logging level meas debug
So, together with changing the default logging category,
this command now would also reset all custom settings...
I am not sure this is exactly what one need/expect, so
I would like to share the following ideas:
1) The category 'all' looks/sounds confusing when it's used
in such cases like this:
# logging level all debug
because one can interpret it like:
"set all categories to debug".
despite actually (according to the implementation) this
is related to the default logging policy.
Maybe, we should rename it to 'default'?
So, 'logging level all LEVEL' would *set all categories*
to a given logging LEVEL, while 'logging level default LEVEL'
would only affect the default logging level...
2) Introducing the new command:
# logging level unset LEVEL
which is intended to assign a given LEVEL to all categories,
which have no custom logging level (i.e. have 'unset'), would
make the idea of having default logging policy meaningless.
Setting logging level(s) for all possible categories (using this
command), looks like writing iptables rules for all possible
and impossible cases instead of using the DEFAULT policy...
3) The introduced behaviour of resetting all categories to 'unset'
could be implemented in a separate function, and can be
represented by a separate command:
# logging level unset-all
The name of this command clearly defines the expected behaviour.
Moreover, it doesn't affect the default logging level, which can be
still changed by a separate command.
As we (me and Pau) have different opinions, or we simply don't
understand each other, let's make this discussion public, and
let's see what others think about this...
With best regards,
Vadim Yanitskiy.
Hi all, idle curiosity here more than anything.....
I noticed that if I bring up a pppd link with a GSM modem to an osmo
stack GPRS network, I get assigned an IP address from the pool as
configured on osmo-ggsn;
ip prefix dynamic 10.20.0.0/16
ip dns 0 192.168.11.2
ip dns 1 192.168.11.2
ip ifconfig 10.20.20.253/16
but the p-t-p address is 192.168.100.101;
Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: local IP address
10.20.0.8
Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: remote IP address
192.168.100.101
Here's the resulting ifconfig:
3g-gwan Link encap:Point-to-Point Protocol
inet addr:10.20.0.8 P-t-P:192.168.100.101 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:54 (54.0 B) TX bytes:76 (76.0 B)
This is not really a problem but I thought it was weird so I looked for
this IP (192.168.100.101) in the source code but it was nowhere to be
found. I'm a bit rusty on ppp, but should it not be the address
configured in the ggsn's ip config?
I thought maybe it was coming from the local pppd stack, so I booted an
old windows 7 machine and connnected the GSM modem, and it got the same
p-t-p address of 192.168.100.101
thnx/
K.
Dear all,
I have a running and working osmocom network stack (2g only, no
GPRS/DATA) with osmo-trx-lms using a LimeSDR mini (osmo-trx-lms,
osmo-bts-trx, osmo-bsc, osmo-hlr, osmo-stp, osmo-msc, a and single
osmo-mgw process) , and I would like to have osmo-bts-trx, osmo-trx-lms
and osmo-bsc moved to another computer. I would like to have an AoIP
connection between the pc1 and pc2. As far as i understand, osmo-bsc and
osmo-mgw communicate over AoIP (as per the manual here
http://ftp.osmocom.org/docs/latest/osmomgw-usermanual.pdf).
My knowledge about the interconnection of all the osmocom core
components is rather limited, and what at first seemed like a trivial
task (to move osmo-bsc to the other computer and changing the msc mgw
remote ip) has turned into a 2 day ordeal with me trying to wrap my head
around the functionality of all the core components without any success.
I have modified my stack to work with a single osmo-mgw process (but the
moving of osmo-bsc does not work with osmo-mgw-for-bsc and
osmo-mgw-for-msc either). Attached are all the configuration files used.
The IP of the osmo-bts-trx, osmo-trx-lms and osmo-bsc running pc (PC1)
is 192.168.1.249, the ip of the pc (PC2) that is running the core
network components is 192.168.1.219. All my osmocom components are built
from source (latest tags).
Running the osmoBSC on the PC1 connects to osmo-bts successfully and
does result in a network being shown on the phone, but osmo-bsc
constantly throws errors:
<0007> a_reset.c:106 A-RESET(msc-0)[0x1ee0530]{DISC}:
(re)sending BSSMAP RESET message...
<0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC:
RI=SSN_PC,PC=0.23.1,SSN=BSSAP
<001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1edfd30]{AS_DOWN}:
Event AS-TRANSFER.req not permitted
Any pointers would be very appreciated.
Sincerely,
Norbertas
Dear Osmocom community,
the first schedule of the 2018 incarnation of OsmoCon 2018 has been announced,
see http://osmocom.org/news/99 for the announcment and
https://pretalx.sysmocom.de/osmocon2018/schedule/ for the actual schedule.
At OsmoCon, we are not targetting developers, but more the wider community
and Osmocom users. It would be great to meet many of you and hear more
about your relation to Osmocom.
Tickets are available from https://pretix.sysmocom.de/sysmocom/osmocon2018/,
and until August 31st the early bird discount still applies.
For those with a community / "just for fun" background and no employer
that would cover the ticket, we have a number of subsidized community discount
vouchers available. See the OsmoCon 2018 wiki page at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
for more information.
Looking forward to meeting as many of you as possible in roughly two
months from now,
Harald Welte
--
- 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, Harald,
I am reusing the libosmovty in my program. And hence my program must
have the same license (AGPL-3.0), mustn't it?
Also, the question regarding the copyright message in the terminal:
Should I leave the "Copyright (C) 201* by Harald Welte..." string or
should I add my name and company there alongside yours. Or can I just
leave my name there?
With best wishes,
Mykola